OCaml Forge

Detail: [#1090] PKCS1.5 and OAEP Padding + miscellaneous thoughts

Feature Requests: Browse | Download .csv | Monitor

[#1090] PKCS1.5 and OAEP Padding + miscellaneous thoughts

2012-01-30 16:19
Submitted by:
Romain Bardou (doomeer)
Assigned to:
Nobody (None)
Operating System:
PKCS1.5 and OAEP Padding + miscellaneous thoughts

Detailed description
This library seems very well designed, but I have some thoughts.

- Maybe a smart constructor for RSA keys could be provided, of type:

val custom_key: ?size: int -> ?p: string -> ?q: string -> ?dp: string -> ?dq: string -> ?qinv: string -> ~n: string -> ~e: string -> ~d: string -> key

(The size field can be computed from n.) This would also make it more clear that the CRT fields are not mandatory. In fact, d and e could also be optional if one only wants to decrypt or encrypt, respectively.

- The RSA.new_gen documentation states that e=3 is faster. It is also weaker. Indeed, for small values of m and if e=3, m^e is less than n, and so m^e mod n = m^e, thus one does not need the private key to decrypt; one just needs to compute the cubic root.

- There is no padding scheme provided for RSA. I would suggest PKCS1.5 and OAEP. The former is weak (Bleichenbacher attack) but is still widely used, the latter is less weak (there is sometimes the Manger attack) but is less easy to implement.

- The Padding module assumes that the padded text will stay at the beginning of the block. This may be true for most block cipher mechanisms, but it is not for RSA paddings such as PKCS1.5 and OAEP. The former, for instance, is:

00 02 (8 positive random bytes) (some other positive random bytes) 00 (plain text)

Thus the plain text is actually at the end. In fact, I would assume that most RSA paddings require the strong endian byte to be 00 to ensure the plain text is strictly less than n.

I'd like to hear your thoughts about this. These are just wishes; PKCS1.5 is easy to implement anyway, and OAEP is easier to implement once the hash functions are available. Your library already provides great functionality.


Date: 2016-12-28 10:01
Sender: Xavier Leroy

The cryptokit project now resides on Github, http://github.com/xavierleroy/cryptokit. This feature wish, or even better a pull request with a prototype implementation of the feature, can be resubmitted on Github.

Attached Files:


Field Old Value Date By
status_idOpen2016-12-28 10:01xleroy
close_dateNone2016-12-28 10:01xleroy