Should we use have a EIP191 like arbitrary bytes signatures

[hugomrdias]

This is a follow up to this issue on the filecoin ledger repo.

The embedded Filecoin Ledger app has this signRawBytes method but its not really just raw signature like lotus wallet sign it's more like EIP191:

sign(blake2b256(CID(blake2b256("Filecoin Sign Bytes:\n" + len(message) + message)))))
Please ignore the extra CID in there for the purpose of this discussion 😄🙏🏼

This situation started the conversation about eips.ethereum.org/EIPS/eip-191 and if we should expose the raw signature method or just a safer EIP191 like signature.

EIP191 looks like:
\x19Ethereum Signed Message:\n "0x19 <0x45 (E)> <thereum Signed Message:\n" + len(message)> "

For Filecoin it may look like:
\x19Filecoin Signed Message:\n "0x19 <0x46 (F)> <ilecoin Signed Message:\n" + len(message)> "
Although theses prefix are Ethereum focused and specific to RLP and may not have the same effect to CBOR messages.

The last point is about FEVM which should probably follow strict EIP191 and not a "Filecoin EIP-191"

So to be discussed:

• Should we deprecate raw unsafe bytes signatures not only in Lotus but filsnap, ledger and others?
• Should we have a "Filecoin EIP-191" with a more filecoin specific scheme? or just the simpler swap "Ethereum" with "Filecoin" above?
• Should we follow strict EIP-191 in FEVM contexts ?

Changing the filecoin ledger app is a complex process and we need at least some buy in from people on this to move on with changes.

/cc @eshon @ribasushi @Stebalien @raulk @rvagg @magik6k

[eshon]

Also consider EIP-712 which prevents replay attacks and is widely supported in the Eth community.

[rvagg]

Can we talk about who the user and consumer is of this data? What's it intended to be used for in a Filecoin context? Who/what are we catering for if we aim for EIP-191 compatibility? Would that smooth anyone's tooling||developer journey when transitioning between Ethereum and Filecoin, or is it just alignment for the sake of alignment? I'm unclear on all of these questions.

[snissn]

I’d love to understand your motivations here, @hugomrdias. This specific aspect of the protocol is interesting, but the details are less familiar to me. From your comment, it sounds like Filecoin currently has an implementation that follows EIP-191 — preventing replay attacks and ensuring signatures are context-specific — but uses its own prefix for the signed message. Is that difference what you’re suggesting is problematic or in need of change?

I also want to echo @rvagg's questions regarding the user journey and who this change benefits.

It would be helpful to hear more so we can determine if any adjustments might be beneficial. Thanks!

[hugomrdias]

Can we talk about who the user and consumer is of this data? What's it intended to be used for in a Filecoin context?

This is all about generic arbitrary bytes signatures, its for proof of ownership in any kind of flow or protocol.

Who/what are we catering for if we aim for EIP-191 compatibility?

In ledger there's no raw bytes arbitrary signature like there is in lotus, filsnap or any burner wallet with iso-filecoin. This is what we want to align.
When we looked into ledger and found the signature scheme above which is not EIP-191 nor any thing we do in the other wallets this conversation started.
Should we actually adopt EIP-191 instead of allowing unsafe raw signatures? Especially in more end user wallets like filsnap and more user friendly integrations with the ledger app?

The point of EIP-191 is to make it impossible to trick the user into signing a tx message using the raw signatures methods which normally are impossible or harder to properly provide clear signing.

Would that smooth anyone's tooling||developer journey when transitioning between Ethereum and Filecoin, or is it just alignment for the sake of alignment?

This is not about alignment with Ethereum EIPs just about 191 is a good idea and a safer way to do these raw signatures maybe we should do the same or similar.
Although it may help to have similar concepts for ppl coming from the EVM world.

---

In iso-filecoin i'm trying to abstract all kinds of wallet/account apis and these differences make it hard, because the verify side needs to be specific for each signature scheme.

With this discussion we want to check with the greater community and see what is the best path forward.

Should we just support raw signatures like lotus in ledger, filsnap and iso-filecoin? Or raw and "EIP-191 like"? Or only "EIP-191 like" (because its safer for users)

Does this answer your questions ?

[eshon]

• Should Hugo file an FIP to propose EIP-191 adoption across the Filecoin ecosystem? This would include:

  • in Filecoin developer libraries like iso-filecoin
  • in Lotus
  • in IPC L2s
  • in ledger-filecoin
  • as a FEVM dapp builder best-practice
    • examples: (sign in with [EIP-191], signing arbitrary msgs for governance, claims, etc.)

• Should we also consider EIP-712?

• This is a good quick explainer of EIP-191 and EIP-712 - https://www.cyfrin.io/blog/understanding-ethereum-signature-standards-eip-191-eip-712

• As for whether the FIP should propose "Ethereum Signed Message" or "Filecoin Signed Message", I asked the Chain Agnostic Standards Alliance and they recommend "Ethereum Signed Message" for full EVM compatibility. It has wider existing adoption by EVM wallets (see below).

• Supporting EIP-191 and EIP-712 would get us to clear signing on Ledger HW eventually which would provide much better security and UX for users when signing arbitrary messages, and which Ledger also wants to move towards.

  • (Ledger needs 712 because 191 involves unstructured data and 712 can point to an on-chain schema that structures it for clear signing.)

• Consider how widely adopted EIP-191 is in the EVM community. This chart below is from 2022, note that standards like "Sign In With Ethereum" use it and EIP-191 forms the basis for other standards involving object-capabilities and may impact UCANs as well.

[rvagg]

Standardisation is good, but this is not consensus-critical (as far as I understand! please correct me if I'm wrong), it's just something we want to say that tooling through the ecosystem should adopt.

But the way to do that is an FRC and I can help push that along; what we want from it is eyes from all of the tool authors that are implicated so at least we don't have disagreement and then moving forward to change what exists currently has some rough consensus.

I don't have an opinion on EIP-712, it seems like it might be a helpful additional-extra but not as important? It'd be particularly hard for CLI signing I imagine but maybe nice for a signing library like iso-filecoin? I don't really know how it would get used but it might be nice to get smart contract authors to weigh in on that part of it.

So, an FRC is a lower-bar than a FIP, it's just an announcement that there is a standard and it would be good if you conform to it if you have anything to do with it. It should be a good way to discover disagreement.

• FRC: Retrieval Checking Requirements FIPs#1089 is the newest FRC in progress you can learn from
• Common Node API FIPs#1027 is another one in progress that's a bit simpler
• https://github.com/filecoin-project/FIPs/tree/master/FRCs is where they live
• IMO a lot of the examples in the FRCs directory are pretty heavy but we don't need something quite so much. https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0097.md is FIP that was merged today that references an EIP so it gets to be a bit lighter, even for a FIP, so it might be helpful to learn from.

So an FRC might just give a basic outline of the EIPs being referenced, why we in the Filecoin ecosystem should care, how our tooling should adapt to it, and considerations about backward compatibility or potential for breakage of what exists now (I'd like to know this myself!). Who are the users, how are they going to use this, why should we care about standardisation?

[snissn]

Thank you for facilitating this discussion, @hugomrdias! I’ve gained valuable insights from this thread.

My Current Understanding and Questions:

1. Lotus Context:
   There exists a potentially risky raw unsafe bytes signatures feature that can be used to sign transactions. Should we consider removing this feature to mitigate security risks?

2. EIP-191 and Prefix Usage:

   • EIP-191 establishes a standard for signing messages, which includes the 0x19 prefix byte. In Ethereum, this prefix ensures that signed messages cannot be mistakenly used for consensus purposes, as the RLP standard forbids it.
   • I am not familiar with how this mechanism applies in the Filecoin context. Ideally, we would want a similar safeguard to prevent message signatures from being misinterpreted as transactions.
   • Questions:
     • Would achieving this require changes to Filecoin’s consensus rules, or is it inherently infeasible within the current design?
     • Is the use of sign(blake2b256(CID(blake2b256("Filecoin Sign Bytes:\n" + len(message) + message)))) sufficient to prevent signed messages from being interpreted as transactions?
     • Does adding the 0x19 prefix before "Filecoin Sign Bytes:" offer any tangible security benefits in the Filecoin ecosystem?

3. signDataCap and signRawBytes:

   • In the Ledger-related discussion, there is a proposal to remove an additional blake2b256(CID) operation in these functions.
   • I raised concerns there about potential impacts on current live operations. Removing this operation may affect existing processes, and we should proceed carefully.

Proposal for a Filecoin Request for Comments (FRC)

I believe an FRC on best practices for message signing in the Filecoin ecosystem would be highly beneficial. Documenting the current practices used by different applications and coordinating these into a standardized approach would provide clarity and improve security, even if no immediate changes are made.