Public key ciphers in Mozilla

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Public key ciphers in Mozilla

Helge Bragstad-3
Hello,

 

Could anybody provide, or point to some info regarding the support for ECDSA
in TLS client authentication in Firefox as well as for S/MIME in
Thunderbird? (Curves and hash functions being used etc. )

 

Likewise, is there similar  support for the RSA padding schemas OAEP and PSS
- and if so - is there a definition of which parameters are *actually* being
used? (Salt length, MGF's, etc.)

 

Thanks,

- Helge

 

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Public key ciphers in Mozilla

Hanno Böck-4
Am Mon, 11 Apr 2011 17:30:29 +0200
schrieb "Helge Bragstad" <[hidden email]>:

> Likewise, is there similar  support for the RSA padding schemas OAEP
> and PSS
> - and if so - is there a definition of which parameters are
> *actually* being used? (Salt length, MGF's, etc.)

I don't know details about EC, but I can answer this:

OAEP: Nothing at all at the moment.

PSS: Experimental code for X.509 exists in bugzilla (Summer of Code
project by me last year), but not merged into CVS.
TLS doesn't support PSS. S/MIME is not yet done, but it's not that
much work based on the X.509 code, I'll probably do it some time in the
future.

--
Hanno Böck mail/jabber: [hidden email]
GPG: BBB51E42 http://www.hboeck.de/

JETZT zu Ökostrom wechseln: http://atomausstieg-selber-machen.de

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Public key ciphers in Mozilla

Helge Bragstad-3
Thank you for your feedback on this, and Konstantin for the feedback on EC.

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. As
far as I can see, these are for JavaCard 2.2.2:

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

PSS:
 * MGF using MGF1 with same hash function as the one used to hash the data
 * Use salt length corresponding to the length of the hash function.

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?

The most troublesome is perhaps to be constrained to SHA-1 for OAEP.

Regards,
- Helge


-----Original Message-----
From: dev-tech-crypto-bounces+helge=[hidden email]
[mailto:dev-tech-crypto-bounces+helge=[hidden email]] On
Behalf Of Hanno Böck
Sent: 11. april 2011 19:09
To: mozilla's crypto code discussion list
Cc: Helge Bragstad
Subject: Re: Public key ciphers in Mozilla

Am Mon, 11 Apr 2011 17:30:29 +0200
schrieb "Helge Bragstad":

> Likewise, is there similar  support for the RSA padding schemas OAEP
> and PSS
> - and if so - is there a definition of which parameters are
> *actually* being used? (Salt length, MGF's, etc.)

I don't know details about EC, but I can answer this:

OAEP: Nothing at all at the moment.

PSS: Experimental code for X.509 exists in bugzilla (Summer of Code project
by me last year), but not merged into CVS.
TLS doesn't support PSS. S/MIME is not yet done, but it's not that much work
based on the X.509 code, I'll probably do it some time in the future.

--
Hanno Böck mail/jabber: [hidden email]
GPG: BBB51E42 http://www.hboeck.de/

JETZT zu Ökostrom wechseln: http://atomausstieg-selber-machen.de

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Public key ciphers in Mozilla

Hanno Böck-4
Am Fri, 15 Apr 2011 17:04:53 +0200
schrieb "Helge Bragstad" <[hidden email]>:

> 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: [hidden email]
GPG: BBB51E42 http://www.hboeck.de/

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re[5]: Public key ciphers in Mozilla

Konstantin Andreev-2
In reply to this post by Hanno Böck-4
Hello, Helge.

Any default should be cautiously placed at the appropriate abstraction level.

In this particular case, the defaults are the responsibility of the layer, which knows it is working with JavaCard 2.2.2/3.0.1. Looks like NSS is not that one.

Let assume NSS applies the defaults below. Let some NSS client mistakenly calls it w/o parameters and crypto-token is not JavaCard. The call must fail, but instead NSS will hide error and silently fool the client by applying unintended defaults.

And, as Hanno suggested, different application may have different opinions about what is a reasonable default.

Keep well,
Konstantin.

On 15.04.11 19:04, Helge Bragstad wrote:

> Thank you for your feedback on this, and Konstantin for the feedback on EC.
>
> 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. As far as I can see, these are for JavaCard 2.2.2:
>
> 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
>
> PSS:
>   * MGF using MGF1 with same hash function as the one used to hash the data
>   * Use salt length corresponding to the length of the hash function.
>
> 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?
>
> The most troublesome is perhaps to be constrained to SHA-1 for OAEP.
>
> Regards,
> - Helge
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

RE: Public key ciphers in Mozilla

Helge Bragstad-3
In reply to this post by Hanno Böck-4
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=[hidden email]
[mailto:dev-tech-crypto-bounces+helge=[hidden email]] On
Behalf Of Hanno Böck
Sent: 16. april 2011 16:08
To: mozilla's crypto code discussion list
Cc: [hidden email]
Subject: Re: Public key ciphers in Mozilla

Am Fri, 15 Apr 2011 17:04:53 +0200
schrieb "Helge Bragstad" <[hidden email]>:

> 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: [hidden email]
GPG: BBB51E42 http://www.hboeck.de/

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

RE: Re[5]: Public key ciphers in Mozilla

Helge Bragstad-3
In reply to this post by Konstantin Andreev-2
Hello Konstantin,

With "default" I meant values that can be chosen by an application, given it
is in a position to make a choice. The choice is made by the application and
not in the library. A PKCS #11 library for a smart card that only supports a
limited set of parameters must for sure fail if a parameter being passed in
from the application is unsupported.

Regards,
- Helge

-----Original Message-----
From: dev-tech-crypto-bounces+helge=[hidden email]
[mailto:dev-tech-crypto-bounces+helge=[hidden email]] On
Behalf Of Konstantin Andreev
Sent: 18. april 2011 11:24
To: [hidden email]
Subject: Re[5]: Public key ciphers in Mozilla

Hello, Helge.

Any default should be cautiously placed at the appropriate abstraction
level.

In this particular case, the defaults are the responsibility of the layer,
which knows it is working with JavaCard 2.2.2/3.0.1. Looks like NSS is not
that one.

Let assume NSS applies the defaults below. Let some NSS client mistakenly
calls it w/o parameters and crypto-token is not JavaCard. The call must
fail, but instead NSS will hide error and silently fool the client by
applying unintended defaults.

And, as Hanno suggested, different application may have different opinions
about what is a reasonable default.

Keep well,
Konstantin.

On 15.04.11 19:04, Helge Bragstad wrote:
> Thank you for your feedback on this, and Konstantin for the feedback on
EC.
>
> 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. As
far as I can see, these are for JavaCard 2.2.2:
>
> 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
>
> PSS:
>   * MGF using MGF1 with same hash function as the one used to hash the
data
>   * Use salt length corresponding to the length of the hash function.
>
> 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?
>
> The most troublesome is perhaps to be constrained to SHA-1 for OAEP.
>
> Regards,
> - Helge
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto