[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RSA Key spec question
At 10:33 AM 4/3/98 -0500, tzeruch - at - ceddec - dot - com wrote:
>E is 17 in pgp, but often 3 or 65567 elsewhere. I know why 2**N+1, but is
>there anything that should be said about this in the spec?
>(Testing 2.6.2 v.s. SSLeay from long ago proved that any value of E worked
>in either; But only some could be generated, or would be by default).
The spec says that PKCS1 padding is required for the encrypted
session key packet, but it doesn't explicitly say that
in a message with multiple recipients, EVERY encrypted session
key packet needs to use a different random padding, as opposed to
making one copy of m and encrypting it separately with each key.
This needs to be fixed.
The issue is preventing the low-exponent attack on RSA,
which is a particular risk for e=3, but occasionally messages
will have more than e=17 RSA-using recipients.
Mentioning that 17, 3, and 65537 are popular values of e
seems worthwhile; it's probably not important to say that
implementations MUST or SHOULD support encrypting with other
values of e, since there's no realy reason to assume they wouldn't.
A more interestng problem is whether implementations SHOULD or MAY
refuse to encrypt to RSA keys with e=1, at least for multiple-
recipient messages. Are there other categories of keys
that are easily detected as weak, e.g. composites, or
do you really need to know p and q to detect weak keys?
Are there similar problems for ElGamal / Diffie Hellman?
Section 5.1 of the spec currently says:
> The encrypted value "m" in the above formulas is derived from the
> session key as follows. First the session key is prepended with a
> one-octet algorithm identifier that specifies the conventional
> encryption algorithm used to encrypt the following Symmetrically
> Encrypted Data Packet. Then a two-octet checksum is appended which is
> equal to the sum of the preceding octets, including the algorithm
> identifier and session key, modulo 65536. This value is then padded as
> described in PKCS-1 block type 02 [PKCS1] to form the "m" value used in
> the formulas above.
Bill Stewart, bill.stewart@xxxxxxxxx
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639