vt-crypt: Add some additional support for keys

[GoogleCodeExporter]

- Support elliptic curve keys
- Have a method that allows one to get the length of a key given a Key object
- Have a method that derives the public key from a private key
- Have a method that takes a KeySpec and algorithm ID and builds a key from it, 
taking care of the exception that might be thrown
- Have a method that generates a secret key given an algo, key length, and 
provider
- Have a method that generates a key pair given an algo, key length, and 
provider
- Have a method that verifies that a given public key is the proper public key 
for a given private key

You can see our implementations of these methods here:
http://svn.shibboleth.net/view/java-opensaml/trunk/opensaml-security-api/src/mai
n/java/org/opensaml/xml/security/SecurityHelper.java?revision=2890&view=markup

Original issue reported on code.google.com by claj...@gmail.com on 6 Dec 2011 at 3:35

[GoogleCodeExporter]

This is an enhancement request.

Original comment by marvin.addison@gmail.com on 20 Dec 2011 at 3:16

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by marvin.addison@gmail.com on 5 Mar 2012 at 6:47

[GoogleCodeExporter]

Original comment by marvin.addison@gmail.com on 7 May 2012 at 4:51

• Changed state: Started

[GoogleCodeExporter]

Added support for the following new features in r2382:
 - Key length determination
 - Keypair validation

Refactored key generation to make it more apparent.  Added some support for EC 
keys, including ECDSA signature algorithm.

Original comment by marvin.addison@gmail.com on 8 May 2012 at 8:17

[GoogleCodeExporter]

I would like to note that I considered the request for allowing key generation 
to take a provider argument, but the feature is contrary to the present design. 
 Provider configuration is a global consideration handled by the CryptProvider 
component, which is consistent with the JCE provider initialization system.

Original comment by marvin.addison@gmail.com on 9 May 2012 at 1:21

[GoogleCodeExporter]

The problem with a "global" configuration model is that it assumes that you 
only ever have on config and that's not always the case and will be less true 
going forward.  It's not true today for applications that run in a container 
(e.g., EE and OSGi apps) and with Java 8/9's push toward multi-tenancy support 
it's only a matter of time before "standalone" desktop apps join the list.

So, in summary, I think that JCE decisions made in the 90s aren't very good 
decisions to make in the 10s.

Original comment by claj...@gmail.com on 9 May 2012 at 2:47

[GoogleCodeExporter]

I appreciate your feedback, but making changes to the provider initialization 
mechanism would be a big undertaking and therefore out of scope for this task.  
I'd be happy to consider it for a future enhancement, though.

Original comment by marvin.addison@gmail.com on 9 May 2012 at 2:54

[GoogleCodeExporter]

Let's get the EC stuff done and then revisit the provider implementation.

Original comment by dfis...@gmail.com on 9 May 2012 at 3:04

[GoogleCodeExporter]

I have added support for reading elliptic curve keys in r2391.  There is one 
additional format that is not yet supported, which is that generated by OpenSSL 
by default:

$ openssl ecparam -name prime256v1 -genkey
-----BEGIN EC PARAMETERS-----
BggqhkjOPQMBBw==
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIP2o6LO+vrQnIF27u+Lf0pz6sTjzlGNOmwkjLJstqUemoAoGCCqGSM49
AwEHoUQDQgAEl6mF3H84Tz/vs6M7bXRn6pB0wy16vKiIKFpROq20y9ymQJtiIYYZ
6rc9jcc0u9QCwOPwYKxxRyaHI/0nHd389g==
-----END EC PRIVATE KEY-----

I will add support for this format in a subsequent commit if it proves 
straightforward.

Original comment by marvin.addison@gmail.com on 16 May 2012 at 3:41

[GoogleCodeExporter]

Added support for reading EC private keys in default OpenSSL format in r2394.

Original comment by marvin.addison@gmail.com on 21 May 2012 at 4:03

[GoogleCodeExporter]

I've completed all the feature requests (in light of present provider 
configuration mechanism) except the following:

- Have a method that derives the public key from a private key

Can you please clarify this feature request with a use case?  As written you're 
asking for the impossible: public keys are not derivable from private keys by 
design.

Original comment by marvin.addison@gmail.com on 21 May 2012 at 4:11

[GoogleCodeExporter]

I'll have to look through the code for the use case we had for that.  That 
said, you have our statement backwards.  Public keys *are* derivable from the 
private key (at least for things like RSA, not sure about EC), the reverse is 
what you can't (hopefully) do.

Original comment by claj...@gmail.com on 21 May 2012 at 6:13

[GoogleCodeExporter]

I did some additional research and as you mentioned it's trivial for RSA simply 
because the most common PKCS#1 format for a private key [1] includes both 
public and private exponent. That convenience is not available generally; the 
other asymmetric ciphers we support, DSA and EC, do not define both public and 
private data in the private key.  While some references discuss that based on 
common conventions it should possible to compute the public component from 
private data, without a well-defined use case I would be reluctant to provide 
that sort of implementation.

[1] http://tools.ietf.org/html/rfc3447#page-7, format #2

Original comment by marvin.addison@gmail.com on 30 May 2012 at 2:18

[GoogleCodeExporter]

Thats fine, I don't think that's a show stopper for us.

Original comment by claj...@gmail.com on 30 May 2012 at 4:37

[GoogleCodeExporter]

Original comment by marvin.addison@gmail.com on 30 May 2012 at 7:00

• Changed state: Fixed