+1 to what @bmastenbrook said. @BRIAN_____, people usually convert public keys from X25519 to Ed25519, to use a single key pair for both encryption and signature (I never am comfortable with this idea)
-
-
I see. Do you know of any higher-level protocols/systems that rely on this property?
-
You can take a look at our paper, https://eprint.iacr.org/2017/1014.pdf , Section 7. There we analyze different protocols and their usage of EdDSA. tl;dr: Most of the protocols generate fresh random values which are signed along with the message, so you cannot enforce signature "re-computation"
-
If you can flip buts with Rowhammer then depending on PRNG implementation you might be able to reset PRNG state to replay the same output twice in a row, e.g. many ChaCah20-based PRNGs are used. This would create problems both for randomized EdDSA and for apps w/ nonces in msgs.
-
Further, if you can flip a bit with Rowhammer then you could flip the "TLS handshake is complete" flag and cause the app to accept unauthenticated/unencrypted input and/or write unencrypted output. https://bugzilla.mozilla.org/show_bug.cgi?id=919877 … shows such a magic bit exists/existed in real life.
-
In general, I am skeptical that we need crypto-specific mitigations for Rowhammer and similar bugs, because it seems likely there are always other magic bits that could be flipped to cause the same or worse damage.
-
This is true, you could e.g. flip a specific bit to get admin rights. The small motivation for our rowhammer eddsa attacks was that in certain scenarios you could flip ANY bit in a large message to be signed and obtain the key
- 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.