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.

[hugomrdias]

Would achieving this require changes to Filecoin’s consensus rules, or is it inherently infeasible within the current design?

no

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?

yes, the payload can never be properly decoded as CBOR and so never be parsed as a proper transaction.

Does adding the 0x19 prefix before "Filecoin Sign Bytes:" offer any tangible security benefits in the Filecoin ecosystem?

no, the rest of the prefix already achieves the security benefits. We can keep it there so its easier for any clients to support Filecoin 191 (swap ethereum with filecoin)

Regarding legder we will probably never remove the current signRawBytes method so we dont break anyone, instead we will properly document the methods in the ledger filecoin app docs and in the clients.

[bumblefudge]

I can't speak to many of the open questions here about breakage risk and alignment, but I would chip in to make a few comments:

@hugomrdias Should we follow strict EIP-191 in FEVM contexts ?

Yes, I think the whole point of an EVM-compatible chain complete with long-lived, ethereum-lists-registered chainId is that standard EVM tooling should work as smoothly as possible there, including EIP-191 support in all the wallets listed above in the feature Matrix @eshon shared. Among other reasons¹, I would encourage proper EIP-191 signatures (i.e. keep the "Ethereum" in the message) so that all these wallets can just connect to FEVM the way they would any other L2 and sign an EIP-191 through a standardized EVM flow familiar to the user of Eth dapps. Among other benefits, this includes "Sign-In With Ethereum" support for any FEVM dapp², helps reuse more of web3.storage's UCAN tooling for EVM dapps, etc, as @eshon mentioned.

@snissn Does adding the 0x19 prefix before "Filecoin Sign Bytes:" offer any tangible security benefits in the Filecoin ecosystem?

I don't know enough about Filecoin to say whether there is an analogue here, but I believe that in the EVM context, this prefix was not a security measure (the rest of the prefix ALREADY makes any EIP-191 digest invalid as an input to an on-chain transaction) so much as a multiformats-like sigil to make the signature object self-describing and sniffable/sortable from the first few bytes. Perhaps different prefixes/magic bytes/CBOR enveloping makes more sense if the idea is to create a safe envelope for arbitrary digests? If, conversely, there is no particular benefit to reinventing this wheel, simply swapping "Filecoin" for "Ethereum" has the [theoretical, minor] added benefit of "rhyming with" the EIP-191 envelope and being human-readable [to humans expecting eth dapp data exhaust, anyways].

@snissn Lotus Context: There exists a potentially risky raw unsafe bytes signatures feature that can be used to sign transactions

If I'm understanding Hugo's original proposal, yes, a "blank-check" signing method seems worth deprecating and removing from some future version of Lotus/CLI, once all the consumers of today's blank-check signatures have upgraded to safer, enveloped signatures. How long that takes is... up to all of y'all, I think!

@hugomrdias Should we deprecate raw unsafe bytes signatures not only in Lotus but [also in] Ledger[...]?

If it takes a lot of effort/time/money to get Ledger to replace unsafe arbitrary sigs with something safer and enveloped, a second option would be to just use the 712 option in Ledger, which I believe is already supported? Getting consumers to accept 712 signatures seems a much bigger ask, tho.

@snissn I believe an FRC on best practices for message signing in the Filecoin ecosystem would be highly beneficial.

Should I start a draft PR with an outline of such an "Informational FRC"? Would it help gather input and align before making any more normative requests of Ledger and/or Filecoin core devs?

Footnotes

1. Unimportant side note: swapping Filecoin for Ethereum doesn't make much sense semantically either, because the only thing Filecoin about that signature (or the wallet and private key signing it) is the chainId-- otherwise it is an Ethereum signature. Submittable transactions and Sign-In With Ethereum messages alike have the chainId as a mandatory field, so the Ethereum refers not to the governance of the chain involved, so much as to the signing standard, which in this case is the Ethereum one, EIP-191! ↩

2. https://eips.ethereum.org/EIPS/eip-4361 ↩

[hugomrdias]

@bumblefudge just to be clear do you agree with:

\x19Ethereum Signed Message:\n for FEVM wallets and \x19Filecoin Signed Message:\n for Filecoin native wallets?

Or \x19Ethereum Signed Message:\n for both ?

[eshon]

Should I start a draft PR with an outline of such an "Informational FRC"?

Yes please!
Thanks for all this input @bumblefudge

[snissn]

Should I start a draft PR with an outline for an "Informational FRC"?

I agree with @eshon's response. There seems to be enough common ground and objectively helpful next steps to justify creating a working draft. That would be a great way to move forward.

Thank you for your thorough analysis in your previous comment, @bumblefudge. Your insights are clear and make sense to me.

@hugomrdias, I’m looking forward to hearing your thoughts when you're available. It seems like there are clear next steps for drafting the FRC and opening a ticket to deprecate arbitrary signing in Lotus. I’d also appreciate your input on whether further actions are needed regarding the ledger implementation.

Thanks, everyone!

[hugomrdias]

IMO we should focus on EIP 191 only and leave 712 for late if needed.

The ledger implementation shouldn't be to big of a change, we just need to settle on FEVM and Filecoin signature prefix. They may already support 191 on FEVM (need to check if that is already redirected to the eth app).