3 ms·
Prehashing doesn't just solve the storage issue. Imagine you want to sign a 1MB or even 1GB file with a typical hardware token. Without prehashing you'd have to
by wahern 7y ago
Prehashing doesn't just solve the storage issue. Imagine you want to sign a 1MB or even 1GB file with a typical hardware token. Without prehashing you'd have to send that entire 1MB or 1GB to the token, which has a throughput on the order of KB/s or maybe MB/s, and process all that data with a CPU clocked at MHz, not GHz. Breaking up the file into chunks doesn't help, and might even make things slower, not to mention the added complexity introduced to your file signature format.
The obvious solution is to hash the data and sign the hash, just as is done for every other signature scheme. The downside is that now your signature scheme is only as strong as the hash. But if it turns out that SHA-512 isn't collision resistant, you have much bigger problems.
PureEdDSA has its elegance, and, sure, use it if you can. But supporting off-chip private keys (e.g. hardware tokens) is sometimes far more important to security. If you're creating an API, keep that in mind.
- dependenttypes 7y ago> But if it turns out that SHA-512 isn't collision resistant, you have much bigger problems. Does it though? Most protocols are moving towards preimage resistance nowadays. That being said, ed25519ph is easier to protect against fault attacks, see https://github.com/jedisct1/libsodium/issues/170 https://github.com/jedisct1/libsodium/issues/170
- nullc 7y ago> if it turns out that SHA-512 isn't collision resistant, you have much bigger problems Ehhh.. collision resistance is a much harder property than second-preimage resistance, and many protocols don't have strong dependencies on collision resistance. Narrow-ish pipe MD style hash functions are particularly brittle against collisions, since finding one collision immediately gives you an infinite family of collisions. You could preserve most of the protection against collision resistance with the two layer hashing by having a signer specified nonce at the interior hash. The token couldn't validate that the nonce matched the one it specified, but an attack would require the host be compromised as well. If the nonce was a hash of the EdDSA R value and checked by verifiers too then the fact that the token can't check wouldn't be a problem. Alternatively, if the inner hash were a tree-structured hash, the token could validate the inner-hash nonce directly. (though depending on the tree, doing it that way might weaken the collision protection). Regardless, it's not strictly necessary to lose that protection just to enable blind-signing-tokens.
- dchest 7y agoPlease stop saying "you have much bigger problems", this cliché is dangerous and unproductive.
- beart 7y agoI don't see why that's dangerous. it's just a rephrasing of "this assumes x holds true" and if it doesn't none of this matters.
- krick 7y agoI don't know what's the parent's problem, but "this assumes x holds true" is actually much more clear and straight-forward, which really helps to stay on track with the discussion. At the very least it allows the opponent to ask if there's something available w/o this assumption, which "you have bigger problems" barely does.