On 9/4/2018 3:19 PM, Adam Petcher wrote:
I think what you are suggesting is that the implementation should
convert between BigInteger and the internal representation when
necessary. The problem with this approach is that it is too easy to
inadvertently supply a BigInteger to the implementation, and this
would result in a branch. I understand that this branch may be
acceptable in some circumstances, but we would need something in the
API to tell the implementation whether it is okay to branch or not. I
think the simplest way to do that is to have a provider that never
branches. If branching is okay, then SunEC can be used.
Basically yes.
But I don't understand what you mean by "inadvertently supply a
BigInteger"? AFAICT, you "supply" a BigInteger in an ECPrivateKeySpec
and you retrieve one when you call getEncoded() or getS(). Your
implementation would convert between the BigInteger and internal
representation during the use of the engineGeneratePrivate() method of
the KeyFactorySpi and would convert from your internal representation
when exporting S, or encoding something as PKCS8.
Again - you're wrongly conflating interface requirements with
implementation requirements.
And how do you expect to move key material between SunEC and this
implementation? See below for my commentary on that.
That's essentially the plan. Calling PrivateKey::getEncoded will
return null, which is a convention for non-extractable keys. Trying to
convert from/to an ECPrivateKeySpec using the KeyFactory in the new
provider will result in an exception---so you won't have an object to
call getS() on.
That's not what PKCS11 does - it just gives you a "PrivateKey" object
with an internal type of sun.security.pkcs11.P11Key. While that object
is not type safe exactly, it is provider safe.
You're still wanting to use the various EC classes of java.security,
java.security.spec, and java.security.interfaces, but you're unwilling
to actually meet their contracts for some really suspect reasons.
To create the key from stored information, the best way is to
construct a PKCS8EncodedKeySpec using the encoded key. If you are
starting with a BigInteger, and if branching is acceptable, you can
use the KeyFactory from SunEC to convert an ECPrivateKeySpec to
PrivateKey to get the encoded value.
Umm... what?
If you were doing NewEC -> SunEC manually (getEncoded() -> KeySpec) -
you'll need to end up emitting a PKCS8 blob using RFC5915, which -
unsurprisingly has BigEndian INTEGERs (yes, its an octet string, but
the encoding is specified by RFC3447 as pretty much the big endian
encoding of an integer). E.g. it may look opaque from Java's point of
view, but it's not really opaque. (See below)
Or have you got a different way of encoding the PKCS8 blob for the new
provider? E.g. point me at a specification please.
My head hurt when I tried to work through the various cases of
translating a private key from your provider to SunEC or to BouncyCastle
and vice versa. Basically, if you don't support the getS() call, then
KeyFactory.translateKey() will fail. (Below from
sun.security.ec.ECKeyFactory.java - the SunEC provider's implementation).
private PrivateKey implTranslatePrivateKey(PrivateKey key)
throws InvalidKeyException {
if (key instanceof ECPrivateKey) {
if (key instanceof ECPrivateKeyImpl) {
return key;
}
ECPrivateKey ecKey = (ECPrivateKey)key;
return new ECPrivateKeyImpl(
ecKey.getS(),
ecKey.getParams()
);
} else if ("PKCS#8".equals(key.getFormat())) {
return new ECPrivateKeyImpl(key.getEncoded());
} else {
throw new InvalidKeyException("Private keys must be instance "
+ "of ECPrivateKey or have PKCS#8 encoding");
}
4.1 <https://tools.ietf.org/html/rfc3447#section-4.1> I2OSP
I2OSP converts a nonnegative integer to an octet string of a
specified length.
I2OSP (x, xLen)
Input:
x nonnegative integer to be converted
xLen intended length of the resulting octet string
Output:
X corresponding octet string of length xLen
Error: "integer too large"
Steps:
1. If x >= 256^xLen, output "integer too large" and stop.
2. Write the integer x in its unique xLen-digit representation in
base 256:
x = x_(xLen-1) 256^(xLen-1) + x_(xLen-2) 256^(xLen-2) + ...
+ x_1 256 + x_0,
where 0 <= x_i < 256 (note that one or more leading digits will be
zero if x is less than 256^(xLen-1)).
3. Let the octet X_i have the integer value x_(xLen-i) for 1 <= i <=
xLen. Output the octet string
X = X_1 X_2 ... X_xLen.
