Digital Signatures

「 Overview 」




Recommended 「 In Order 」

Ed25519

Ed448




Avoid 「 Unordered | All Unsuitable 」


RSA ( Plain | PSS | PKCS#1 v1.5 )

Moreover, RSA has implementation traps.

ElGamal

Allows for existential forgery if the message is used directly
rather than the hash, as specified in the original paper.

DSA

DSA is not deterministic, which has led to serious vulnerabilities.
↳ Please see below

ECDSA

This issue can be prevented by properly generating a random nonce,
which requires having a good CSPRNG, or by deriving the nonce
deterministically using something like HMAC.

However, there’s been a shift to Ed25519 because it prevents this
issue from happening as well as being better in other respects.

Furthermore, there’s also the concern mentioned in Hybrid Encryption
that the NIST curves use unexplained seeds, which is not a good look
considering that Dual_EC_DRBG was a NIST standard despite containing
an NSA backdoor.

Post Quantum Algorithms

However, eventually it will make sense to switch to one in the future.




Notes


「 1 」

Please read points 1 - 2 and 9 - 10 of the Hybrid Encryption notes because all
these points about key pairs / private keys apply for signature algorithms as well.

「 2 」

Use authenticated hybrid encryption instead of encryption with signatures.
(Authenticated key exchange with authenticated encryption)

This is easier to get right and more efficient.

「 3 」

If you must use signatures with encryption:
Use Sign ➜ Encrypt to provide sender authentication

Encrypt ➜ Sign can allow an attacker to strip off
the original signature and replace it with their own.

For symmetric encryption, Sign ➜ Encrypt ➜ MAC, which involves
signing the message, appending the signature to the message, and
using either Encrypt ➜ MAC or an AEAD, prevents this problem.

Similarly, if you’re forced to use asymmetric encryption, then you can still use Sign ➜ Encrypt
but should include the recipient’s name or the sender and recipient’s names in the message
because the recipient needs proof that the same person signed and encrypted the message.

Once the signature and encryption layers are bound together, an attacker can’t remove
and replace the outer layer because the reference in the inner layer will reveal the tampering.

Alternatively, you can Encrypt ➜ Sign ➜ Encrypt
or Sign ➜ Encrypt ➜ Sign, which are both slower.

「 4 」

Don’t use the same key pair for signatures (Ed25519) and key exchange (X25519)

It’s recommended to never use the same key for more than one thing in cryptography.

The security of using the same key pair for these two algorithms
has not been sufficiently studied, signing key pairs and encryption
key pairs often have different life cycles, and using different key pairs
limits the damage done if one key pair is compromised.

Since the keys are so small, using different key
pairs produces barely any overhead as well.

The only time you should really convert an Ed25519 key pair
to an X25519 key pair is if you’re heavily resource constrained
or when you’re forced to use Ed25519 keys.

(SSH public keys of GitHub could be used for hybrid encryption)

「 5 」

Prehash large messages

Signing a message normally requires loading the entire message into
memory, but this can be problematic for very large (1+ GiB) messages.

To solve this problem, you can use Ed25519ph or Ed448ph (which probably isn’t available)
to perform the prehashing for you with some additional domain separation, or you can
prehash the message yourself using a strong, modern hash function, like BLAKE2b or SHA3,
with a 512-bit output length and sign the hash instead of the message.

However, note that not prehashing means that
Ed25519 is resistant to collisions in the hash function.

Therefore, when possible, ordinary signing should arguably be preferred for additional
protection, although this isn’t realistically a problem if you use a secure hash function.

「 6 」

Be aware of fault attacks against deterministic signatures

Techniques like causing voltage glitches on a chip (Arduino)
can be used to recover either the entire secret key or part of
the secret key, depending on the signature algorithm, and
create valid signatures with algorithms like Ed25519, Ed448
and deterministic ECDSA.

However, this is primarily a concern on embedded devices
and requires physical or remote access to a device.

Four countermeasures include signing the same data twice and comparing the outputs,
which is obviously slower than signing once, verifying the signature after signing,
which is slower than signing twice for small messages but faster for large messages,
calculating a checksum over input values before and after signature generation,
or using a cryptographic library that implements the algorithm with some random
data in the calculation of the nonce, which is the technique used by Signal.

However, these countermeasures are not guaranteed to be effective
and there can be other side-channel attacks as well.



「 Overview 」