* hal(_at_)finney(_dot_)org wrote:
The RSA attack is the one Lutz called a "Bellcore" attack, based on the
Eurocrypt 97 paper by Boneh et al at
http://theory.stanford.edu/~dabo/papers/faults.ps.gz.
Yep. Thanks for the link. 'Bellcore attack' is the name in the German
smartcard hacking scene.
one side of the signature is done wrong. Specifically they change the
last value in the secret key, "u", which is the inverse of p mod q.
Posted this yesterday: Yep possible, even to change the checksum.
The DSA attack is quite different. In this case they change the
public parameters of the DSA key to weaken it but leave the private
part alone. They change p and g to be a group where discrete logs are
easy, one where (p-1) has only small factors. Then when the signature
is calculated, they can find the secret k value by taking the discrete
log of r, and from this they can calculate the user's secret key.
Great idea.
whenever it decrypts RSA private key data, it does the following checks:
n = p*q
d*e mod p = 1
d*e mod q = 1
p*u mod q = 1
This validates all of the private key data and makes sure it is consistent
with the public key values. In particular the last check prevents the
It makes sure, that is consistent in itself, but it does not say anything
about a prevented attack: Assume an attack able to modifiy the parameter q
to be equal 1. If have to sleep about this.
Note that these checks are quite fast, just a few multiplies and
divides, so they do not slow down the signature calculation by much,
since it involves exponentiations.
They do not address probability attacks to errors in the MPI calculus. (Wait
for a bellcore scenario ... most customer PCs run far from there
specifications, so we have a real smartcard analogon). Thats why PGP263(i)n
does check against any miscalculations.
- Use CBC mode rather than CFB to encrypt private key components
- Use an HMAC to protect public and private key data
- Use PSS padding from PKCS-1 v 2.1 rather than the v 1.5 padding
I'd like to add: Throw away the bit gambling. Redesign from scratch.
bit pattern into it. They use this to attack RSA V4 keys. However,
CBC mode allows similar perturbations, but to the first block rather
than the last block. So this fix does not go to the heart of the problem
and could still leave vulnerabilities.
Yep. This would be a HMAC.
The last idea, to use PSS padding, also does not seem to fundamentally
help. It would still be possible to disrupt the CRC calculation.
We could prevent algebraic attacks by applying the P.1363 recommendation.
Broadly speaking, because the attack requires write access to users'
private keys, I don't think making changes is an urgent matter.
Ack. We should stress that private key files should not reside on shared
media and that OpenPGP ist a transport message format, not a local storage
recommendation. Implementations are free to choose anything else.
Do we need to define a new packet format, V5 for keys? Or could we keep
the old format number and use the length difference of a 20-byte HMAC
vs a 2-byte checksum to recognize which one is being used?
No more bit gamblings! Use v5 for secret keys. A public part to index and a
whole encrypted and hashed private part including the whole pulic key data
again.
If we do add an HMAC, software could then work in a mode where old-format
keys get the extra checks applied to carefully validate them, then
get rewritten using the HMAC. From then on the extra checks are not
necessary and the HMAC alone will detect changes. So we will retain
fast performance, plus have security against tampered private key files.
I'm feeling bad.