- From: Mike Jones <Michael.Jones@microsoft.com>
- Date: Wed, 9 May 2012 22:12:28 +0000
- To: Nadim <nadim@nadim.cc>, Jarred Nicholls <jarred@webkit.org>
- CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-ID: <4E1F6AAD24975D4BA5B1680429673943664CE282@TK5EX14MBXC283.redmond.corp.microsoft.>
As a data point, the IETF JSON Object Signing and Encryption (JOSE) specs define the use of these algorithms (see http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms):
For signing/MAC:
+--------------------+----------------------------------------------+
| Alg Parameter | Algorithm |
| Value | |
+--------------------+----------------------------------------------+
| HS256 | HMAC using SHA-256 hash algorithm |
| HS384 | HMAC using SHA-384 hash algorithm |
| HS512 | HMAC using SHA-512 hash algorithm |
| RS256 | RSA using SHA-256 hash algorithm |
| RS384 | RSA using SHA-384 hash algorithm |
| RS512 | RSA using SHA-512 hash algorithm |
| ES256 | ECDSA using P-256 curve and SHA-256 hash |
| | algorithm |
| ES384 | ECDSA using P-384 curve and SHA-384 hash |
| | algorithm |
| ES512 | ECDSA using P-521 curve and SHA-512 hash |
| | algorithm |
| none | No digital signature or HMAC value included |
+--------------------+----------------------------------------------+
For key encryption:
+-----------+-------------------------------------------------------+
| alg | Encryption Algorithm |
| Parameter | |
| Value | |
+-----------+-------------------------------------------------------+
| RSA1_5 | RSA using RSA-PKCS1-1.5 padding, as defined in RFC |
| | 3447 [RFC3447<http://tools.ietf.org/html/rfc3447>] |
| RSA-OAEP | RSA using Optimal Asymmetric Encryption Padding |
| | (OAEP), as defined in RFC 3447<http://tools.ietf.org/html/rfc3447> [RFC3447<http://tools.ietf.org/html/rfc3447>] |
| ECDH-ES | Elliptic Curve Diffie-Hellman Ephemeral Static, as |
| | defined in RFC 6090<http://tools.ietf.org/html/rfc6090> [RFC6090<http://tools.ietf.org/html/rfc6090>], and using the Concat |
| | KDF, as defined in [NIST-800-56A<http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-01#ref-NIST-800-56A>], where the Digest |
| | Method is SHA-256 and all OtherInfo parameters are |
| | the empty bit string |
| A128KW | Advanced Encryption Standard (AES) Key Wrap Algorithm |
| | using 128 bit keys, as defined in RFC 3394<http://tools.ietf.org/html/rfc3394> [RFC3394<http://tools.ietf.org/html/rfc3394>] |
| A256KW | Advanced Encryption Standard (AES) Key Wrap Algorithm |
| | using 256 bit keys, as defined in RFC 3394<http://tools.ietf.org/html/rfc3394> [RFC3394<http://tools.ietf.org/html/rfc3394>] |
+-----------+-------------------------------------------------------+
For block encryption:
+-----------+-------------------------------------------------------+
| enc | Symmetric Encryption Algorithm |
| Parameter | |
| Value | |
+-----------+-------------------------------------------------------+
| A128CBC | Advanced Encryption Standard (AES) using 128 bit keys |
| | in Cipher Block Chaining mode using PKCS #5 padding, |
| | as defined in [FIPS-197<http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-01#ref-FIPS-197>] and [NIST-800-38A<http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-01#ref-NIST-800-38A>] |
| A256CBC | Advanced Encryption Standard (AES) using 256 bit keys |
| | in Cipher Block Chaining mode using PKCS #5 padding, |
| | as defined in [FIPS-197<http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-01#ref-FIPS-197>] and [NIST-800-38A<http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-01#ref-NIST-800-38A>] |
| A128GCM | Advanced Encryption Standard (AES) using 128 bit keys |
| | in Galois/Counter Mode, as defined in [FIPS-197<http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-01#ref-FIPS-197>] and |
| | [NIST-800-38D<http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-01#ref-NIST-800-38D>] |
| A256GCM | Advanced Encryption Standard (AES) using 256 bit keys |
| | in Galois/Counter Mode, as defined in [FIPS-197<http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-01#ref-FIPS-197>] and |
| | [NIST-800-38D<http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-01#ref-NIST-800-38D>] |
+-----------+-------------------------------------------------------+
See the spec for those that are REQUIRED, RECOMMENDED, and OPTIONAL. If we’re going to be able to implement the JOSE specs using the Web Crypto primitives, the algorithms above will need to be supported.
-- Mike
From: Nadim [mailto:nadim@nadim.cc]
Sent: Wednesday, May 09, 2012 2:56 PM
To: Jarred Nicholls
Cc: public-webcrypto@w3.org
Subject: Re: ECC vs RSA, and Similar Conflicts
Here's an interesting question, then:
Let's assume, for the sake of argument, that SHA2 is widely recognized as being a better alternative to SHA1. However, SHA1 is not only far from broken, but is also as widely used as SHA2, if not more.
What happens in such a scenario? Do we implement only SHA2 (knowing it to be more secure) or do we still include SHA1, even if it's the less secure alternative?
NK
On Wednesday, 9 May, 2012 at 5:52 PM, Jarred Nicholls wrote:
On Wed, May 9, 2012 at 1:33 PM, Nadim <nadim@nadim.cc<mailto:nadim@nadim.cc>> wrote:
Hi everyone,
I think we need to have a discussion regarding whether the API will exclusively implement (and rely on) newer, faster standards (such as ECDH, ECDSA) or whether there will be a larger dependence on RSA, either for fallback or stronger compatibility reasons.
If it is eventually decided that not only the best available per-task algorithm is implemented, but rather, all possible algorithms, where do we draw the line? Do we implement SHA1 in addition to SHA2? Does that also warrant an MD5 implementation?
Personally, I believe that focusing only on the newer, more efficient standards (such as ECC) is a better idea, but I stand very humbly by my opinion and a much more interested in listening to the group's opinions.
Thank you,
NK
It might be difficult for the API spec to attempt to enforce certain algorithms as normative, where a vendor must implement support for that algorithm or be declared non-compliant; versus suggesting/recommending particular support. I'll admit I am naive in this area, but I see this somewhat analogous to HTML5 <video> and codecs that browser vendors choose to support. This is of course why the API should be as agnostic as possible, which is difficult to do and quite a different situation than HTML5 <video> & codec support.
So it is of my opinion that the browser vendor could choose to support the new standards, or RSA, or both. The API ought to allow for this.
Cheers,
Jarred
Received on Thursday, 10 May 2012 15:48:18 UTC