[Cryptography] More efficient and just as secure to sign message hash using Ed25519?

Allen allenpmd at gmail.com
Thu Aug 6 07:55:06 EDT 2015


Hi Peter,

I understand what you are saying.  Regardless of how the two hashes are used
internally, at the end of the day, the algorithm is hashing the entire
message twice (with the same hash algorithm and two different IV's), and the
potential advantage over hashing just once is that you gain resistance to
collisions in the hash function.

Hashing an entire message twice with two different IV's is a simple way to
gain collision resistance in any context, but I also think it is relatively
expensive compared to other potential approaches.

This is the approach we're considering for our application, and I would
suggest it might also be suitable for other applications with long messages:

1. Hash the entire message once using a hash function that outputs at least
512 bits.  If you want fast, Skein-512-512, Blake-512 or Blake2b might be
good choices.  If you want more security and/or collision resistance,
Keccak-512 or Keccak-576 might be good choices.

2. Form a short string by concatenating the hash computed in Step 1 with the
original message length and other key message metadata, such as the message
id, timestamp, sender id, reply-to id, etc.

3. Sign the short string from Step 2 using the Ed25519 algorithm as
published, pairing the elliptic curve with a strong 512 bit hash function
such as Keccak-512, or possibly even two strong hash functions such as the
Skein-512(Keccak-576(x)).

Depending on the application and the nature of the messages being signed, I
think that sufficiently strengthens the algorithm against potential
collisions in the hash function without requiring the entire (long) message
to be hashed twice.  It also opens up the possibility of using a faster
and/or wider hash function in Step 1, with a more computationally complex
hash function in Step 3, which I think puts the CPU cycles to work where
they can provide the greatest benefit.

Just my 2 cents.  Other people might have different security/cost tradeoffs,
which is fine by me.




More information about the cryptography mailing list