On 11/7/2018 8:53 PM, Weijun Wang wrote:
Oh, I didn't know that.
To make sure -keyalg matches KeyPairGenerator.getInstance(), I'd like to
support it. If I read the impl correctly, you don't need to initialize it
anymore and if you really want to initialize it the params must be the same.
Currently keytool always calls initialize(). In this case, there will be no
default -keysize, and initializa() will be not be called if user has not
specified one. If user provides -groupname or -keysize just use it and keytool
fails if API call fails.
This is correct. If you are using the "X25519" and "X448" algorithm
name, then there is no need to initialize with parameters, because they
are decided by the algorithm name. You can still initialize, and
different providers may be more permissive than others if you try to use
different parameters than what is specified by the algorithm name. For
example: KeyPairGenerator.getInstance("X448").initialize(255). SunEC is
very strict, and will not allow this sort of thing.
X25519/X448 keys can only be used for KeyAgreement, so they aren't
supported in keytool anyway, right? If this is the case, then you don't
need to worry about adding any code to keytool for them. Though I expect
EdDSA to work in a similar way (algorithm names "Ed25519" and "Ed448").
Still, I don't know if it is worthwhile to add special code for it. For
all algorithms, if no -keysize or -groupname is specified, then keytool
could skip the initialize on the KPG, and the implementation defaults
(if available) will be used. The hard part is deciding whether to emit a
warning in this case, and that will probably be algorithm-specific.
On Nov 8, 2018, at 8:01 AM, Xuelei Fan <xuelei....@oracle.com> wrote:
On 11/7/2018 3:38 PM, Weijun Wang wrote:
This sounds a little misleading to me. Alg name and alg params are 2 different things.
This is like asking user to call KeyPairGenerator.getInstance("secp256r1").
Well, KeyPairGenerator.getInstance("x25519") is a case that JDK 11 has
supported now.
Otherwise, there is a need to check the conflict of alg name and group name.
This only works because "X25519" (and "X448") is both an algorithm name
and a parameter spec name. This makes sense for X25519/X448, but not for
all algorithms.
I don't think there is any need to check for algorithm/group conflicts
in keytool, because it is checked in the crypto provider already. All
keytool needs to do is pass down the algorithm name and group name (as a
NamedParameterSpec/ECGenParameterSpec) and see if it works. If we want
to support "secp256r1" in -keyalg, then we can accomplish that by adding
it as an algorithm name for KeyPairGenerator. Though I'm not sure this
is a good idea.
