Is this the normal way it's done? I thought it was normal to try to implement x25519 and then implement Ed25519 as a hack on top of it. If the hacky way isn't normal then it's probably less of a concern.
-
-
Replying to @BRIAN_____ @hdevalence and
How would one do that? AFAIK for signing you can't use x-only Montgomery arithmetic because encoded Ed25519 points specify a single point, not a pair of points; and for verification, you can't use a differential addition formula with Shamir's trick.
1 reply 0 retweets 1 like -
Replying to @bmastenbrook @BRIAN_____ and
+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)2 replies 0 retweets 5 likes -
Replying to @XorNinja @bmastenbrook and
OK, let's jump ahead to the thing I want to verify: For these kinds of fault attacks, what is the value of checking that the result is on the curve? If the bit flipping is actually modifying the private key scalar itself then it doesn't help AFAICT, but how about otherwise?
1 reply 0 retweets 0 likes -
Replying to @BRIAN_____ @bmastenbrook and
EdDSA signing requires two scalar mults, one to compute the public key (which can be cached) and another to compute R. If adversary can cause any faults in these computations, and also learn the correct value of the public key or R, they can compute the private key
1 reply 0 retweets 3 likes -
Replying to @XorNinja @BRIAN_____ and
Point-on-curve check can detect certain faults, but it doesn't help if the adversary can actually flip a single bit of any scalar
1 reply 0 retweets 1 like -
Replying to @XorNinja @BRIAN_____ and
Something to think about: suppose there's a deterministic carry mispropagation bug that can be triggered with 1% of the scalar values. Is it possible to extract the private key?
1 reply 0 retweets 1 like -
Replying to @XorNinja @BRIAN_____ and
Point-on-curve check can detect mispropagation bugs, but I'm not sure whether these bugs leak the Ed25519 private key. Since the bugs are deterministic, the adversary cannot obtain two different R values for the same nonce and message.
@jurajsomorovsky thoughts?3 replies 0 retweets 0 likes -
Replying to @XorNinja @BRIAN_____ and
I think you are true, you cannot exploit deterministic bugs. You always need two signatures, one has to be computed correctly and one with a fault injection in one of the parameters.
1 reply 0 retweets 0 likes -
Replying to @jurajsomorovsky @XorNinja and
The only attack scenario that I could think of is if you would have a set of servers sharing the same key. One of the servers would have this deterministic computation problem. Then you could obtain valid and invalid signatures by querying both servers.
1 reply 0 retweets 0 likes
Imagine socket-based application. It generates a signature sig of length n and calls send(&sig[0..n])s; send() returns s < n. When the socket is writable again, it generates the same signature and does send(&sig[s..n]). Only works if signature generation is deterministic.
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.