David,
I'll go into my vision of what I aspire to ("The Truly Universal PKI") in
another message. Why I focus on what I do may become clearer then.
tl;dr:
1. CMS is the primary motivator for BER indefinite reading, if not
writing/digesting.
2. To prevent ECB and non-KDF key agreement, enumerate values for { algorithm,
mode } and { keyAgreement, derivationFunction } tuples. This will prevent
naive implementations of ECB and non-KDF key agreement in JavaScript or other
clients.
3. Never allow non-Mozilla-implemented digest objects to provide any digest
value for a signature, without a preference.
4. I wish for a truly expansive and comprehensive API.
5. Instead of defaults, perhaps allow the author to ask for a specific type of
algorithm and a minimum strength, using lower-case type codes and bit-strength
numbers.
-Kyle H
On Fri, Apr 20, 2012 at 8:40 PM, David Dahl <dd...@mozilla.com> wrote:
----- Original Message -----
From: "Kyle Hamilton" <aerow...@gmail.com>
CMS does not require DER. It requires BER, specifically to handle
indefinite-length streams. It may be the case that there are
multiple sections of code writing to the same stream, as a valid
(though spaghetti-codish) implementation technique.
Streaming signature should be a function of streaming digest.
PKCS#11 submits the digest to the module for signature, and returns
the signature blob. This is the case even for DSA and ECDSA
modules.
Good to know.
I see standards which suggest that it should be permitted, and no
actual reason not to.
Ok, can you point to some standards docs for me to read about?
Aside from CMS (RFC5652), https://en.wikipedia.org/wiki/CAdES_%28computing%29 ,
a set of extensions to CMS (which permits BER, not mandating definite-length
encoding)
Basically, nearly every CMS-derived protocol requires the capacity to read, if
not create, indefinite-length streams. (Time Stamp is notable exception)
(Speaking of ECDSA, I'd like that enumerated in the IDL. I'd like to
enable DHKE, but I'd also like to enable ECDHKE.
I will add ECDSA for signatures for sure. Again, I am not sure if ECDHKE would
be permissible for us to use.
Elliptical Curve Diffie-Hellman Key Exchange has at least one unpatented,
public domain implementation, in Daniel J Bernstein's Curve25519.
http://cr.yp.to/ecdh.html for more information and source code. It is NOT a
signature algorithm. It does not use the y coordinate, so there are no patent
issues with key compression. Any 256-bit string is a valid private key. Any
256-bit string can be a valid public key. And it uses far fewer processor
operations in key agreement on AMD64, and probably on other 64-bit platforms,
than any other elliptical curve function of the same magnitude.
Dan Bernstein's
Curve25519 function is exemplary for this, with a derived key length
of 256 bits. The downside is that any ECDH implementation requires
a key derivation function, like a digest -- one must not use
ECDH-agreed values directly. Personally, I'd like to see this
requirement inflicted on DHKE secrets too.)
Interesting. Are you interested in helping with a design for the symmetric
encryption API? :)
Sure! My motive is to ensure that the maximum number of applications can be
securely supported without having to revisit this API.
Most specifically, I want to ensure that systems which greedily consume every
cryptographic primitive and service (identity, timestamp, revocation), then turn around
and ask "please sir, can I have some more?" can be implemented completely and
securely in JavaScript addons. (Why? Because TTUPKI does so.) To this end, here is my
wish list:
Security principles:
- Never allow a non-Mozilla-implemented object to calculate a digest which can
possibly be provided to NSS for signing, without a preference:true.
- Never create any means to create a new block symmetric cipher object which
implements ECB mode.
- Enumerate { algorithm, mode } tuples, not algorithms and modes, to avoid
JavaScript ECB
- Never create any means for a key agreement to be specified without a
derivation function.
- Enumerate { agreementAlgorithm, derivationFunction } tuples, not
agreementAlgorithms and derivationFunctions, to avoid JavaScript
non-key-derived implementation.
Wish List:
- Creation and management of new verification universes with only
explicitly-added trust anchors, specified either by certificate reference or
bare { algorithm, subjectPublicKeyInfo } tuple
- ASN.1 generation/consumption, both BER and DER. (XER too, but less so)
- CMS, for Time Stamp Protocol, both creation of requests and verification of
tokens
- OCSP, CRL generation/consumption
- Generation, reference and use of multiple keypairs of varying types in crypto
containers
- Creation of new containers, setting their attributes, generating new keypairs
of varying types within them, addition of arbitrary certificates associated
with those keypairs, addition of multiple certificates associated with a given
keypair, associating containers with the sites which requested their policy
implementation, association of those sites' security policies with those
containers (new NSS record type?)
- Selection and use of both { userstring, derivationFunction } and {
randomstring, derivationFunction } enumerated tuples. In the latter case, the
randomstring tuple object should have a call to obtain the random string from
which the return value was derived.
- Selection and use of multiple asymmetric signature objects
- Selection and use of multiple key exchange objects
- Selection of atomic { symmetric algorithm, mode } tuple and its key length
(no enumerated tuples which contain ECB)
- Selection of and instantiation of multiple digest algorithm objects (only
Mozilla-implemented for submission for signing, unless pref:true)
- Selection and use of a key derivation function as part of the key agreement
object (never permit key agreement objects to use null derivation functions)
- Instantiation of multiple MACs over the same input stream
- Signature over user blob, given the key, signature algorithm, and buffer of user blob
(not "buffer of arbitrary digest over user blob")
Make of it what you will. I expect that it's going to need to be revisited
regardless of how much we put into it right now. :)
If the digest algorithm has no default, please don't specify a
default in the symmetric or asymmetric algorithms either. I'd
prefer a conceptually tidy API, with as few differences between the
algorithm types as possible.
Yes. Makes sense. In our Identity work there is the notion of a alg/keybits argument/property for
these kinds of things: "DS160" or "RS256".
Would those numbers be algorithm key lengths or cryptographic strengths?
(log(2) magnitude number of operations which must be performed on average to
either: recover the plaintext of a symmetrically-encrypted blob, recover the
key of a symmetrically-encrypted blob, recover the private key of a public key,
forge a signature, find a digest collision, or find a digest preimage)
a) Algorithm key lengths require the site owner/addon author to keep updated
when e.g. Mozilla deprecates algorithms which are shown to be broken.
b) Cryptographic strengths would permit the client to select an appropriate
algorithm given the input of the bits of security required for that policy. It
would also permit the client to be updated with its own ideas as to what
constitutes a given strength. However, it would also run the risk that
non-client systems requiring interoperability will not be updated to get rid of
broken algorithms.
According to NIST (2011), 224-bit ECC is considered approximately as strong as
2048-bit RSA, and 256-bit ECC is approximately as strong as 3072-bit RSA. NIST
also says that SHA1 shouldn't be implemented in new systems, because it
provides less than 80 bits of strength in signatures and ~69 bits of strength
against collisions.
Asymmetric algorithm strength is best-case half of the algorithm key length
(with EC), and much less (with others).
Instead of defaults, perhaps the design might benefit from a set of tags
(case-sensitive?) like:
"sym256" minimum { symmetric algorithm, mode } tuple strength
"asy128" minimum asymmetric strength
"dgc128" minimum digest strength against collision
"dgs128" minimum digest strength for signatures
"mac128" minimum MAC strength
This would permit addon developers to put their trust in Mozilla's
professionalism and judgment, in staying abreast of current developments.
-Kyle H--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
