Thanks Hanno, for your comments. I understand well your objection against being restricted to use only SHA-1 for OAEP, this was simply a quote of what (presumably) is default for JavaCard. I don't suggest to restrict Mozilla's native PKCS #11 implementation. In many cases, parameters are known from other sources, like when doing decryption and verification. A signature may contain SMIMECapabilities that specifies parameters for OAEP etc. In this case, Mozilla needs to use those that are given of course. Default parameters settings would make sense if Mozilla has to *decide*.
For encryption, RFC 4055 states: "For MGF1, it is strongly RECOMMENDED that the underlying hash function be the same as the one identified by hashFunc." So if Mozilla needs to *decide* upon the OAEP parameters, more appropriate rules could be: * Hash function being the choice of the sender (e.g. Thunderbird). * MGF using MGF1 with same hash function as above! * Not assign any shared label For signing, RFC 4055 states: "For a given hashAlgorithm, the recommended value of saltLength is the number of octets in the hash value.", consistent with what already discussed. Regards, - Helge -----Original Message----- From: dev-tech-crypto-bounces+helge=bragstad....@lists.mozilla.org [mailto:dev-tech-crypto-bounces+helge=bragstad....@lists.mozilla.org] On Behalf Of Hanno Böck Sent: 16. april 2011 16:08 To: mozilla's crypto code discussion list Cc: he...@bragstad.com Subject: Re: Public key ciphers in Mozilla Am Fri, 15 Apr 2011 17:04:53 +0200 schrieb "Helge Bragstad" <he...@bragstad.com>: > When it comes to implementing support for OAEP and PSS in smart cards, > a major part of implementations will be based on JavaCard. In this > case, the additional parameters can not all be assigned, and so some > default values apply. It could save many some trouble if Mozilla, when > taking these padding schemas into use would restrict itself to the > same sub-set of parameters. I think it doesn't make much sense to restrict our implementation. It should support what the standard supports. Do you think about restricting signature verification/decryption or signature generation/encryption? The first doesn't make much sense at all, the latter may make sense in certain applications, but definitely not in the library (aka nss). > OAEP not mentioning parameters, so these defaults should apply: > * Hash function being SHA-1 > * MGF using MGF1 with SHA-1 > * Not assign any shared label That sounds like a really stupid idea. It's like securing your windows with armoured glass, but leaving the door open. OAEP/PSS provide probably better security against yet unknown threats. The threat from using SHA-1 is well known and will likely become practical within the next years. It's definitely better use old PKCS #1 1.5 padding with a secure hash than PSS/OAEP with an insecure hash. > JavaCard 3.0.1 does allow setting salt length, but if not set, the > value above is the default. Any particular reason not to use this > value? I think there's no reason against this value. The standard sets the default to a salt length of 32 byte. Problematic are only very short salt values (like zero, which is also possible according to the standard). -- Hanno Böck mail/jabber: ha...@hboeck.de GPG: BBB51E42 http://www.hboeck.de/ -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
