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/
signature.asc
Description: PGP signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
