On 5/9/2018 6:06 AM, Weijun Wang wrote:
Hi Mike
Your comments make sense. However,
1. I don't think it's easy in JDK to break a PBE algorithm into PBKDF + Cipher. For example, I cannot create
a SecretKey from SecretKeyFactory.getInstance("PBEWithSHA1AndDESede") and use it to init a
Cipher.getInstance("DESede"). I still have to use
Cipher.getInstance("PBEWithSHA1AndDESede").
No - you'd instantiate a KDF using PBE, derive the secret key from the
password, and use it with DESede. Right now, you're hiding a KDF under
the cover of turning a secret key spec into a secret key.
And right now, all of this is actually hidden under the KeyStore
covers. If you're going to use compound algorithm names, what I'd
rather do is
KeyStore ks = KeyStore.getInstance("PKCS12/PBKDF2/HMAC-SHA256/AES-KW");
Or <keystoretype>/<kdfalg>/<kdfprf and mac alg>/<dataencryption alg>
And have the generic KeyStore.getInstance("PKCS12") return what you
specify in the preferences, or a general parser for things you're
reading in.
2. If I read correctly, MacData in pkcs12 (https://tools.ietf.org/html/rfc7292#page-11)
always uses the old style KDF (https://tools.ietf.org/html/rfc7292#appendix-B). If we
have a "pbkdf" setting, it might mislead a user to believe it's also used by
MacData generation.
You are - unfortunately - correct that Appendix B is still used for the
KDF for macdata keys. That appears to be a bug as you shouldn't be
using the same key (password) for different algorithms and also appears
to be a backwards compatibility item from the previous versions of
PKCS12. I'll ask the CFRG what they think about it.
But I disagree with the "mislead a user". As you note, Appendix B is
specific that it's the only source for macdata KDFs, and you could
include a note in the spec that this only applies to deriving data
encryption keys rather than the macdata key.
I looked at openssl and it also has independent -certpbe and -keypbe.
Also, setting multiple algorithms with a preference order might not be what we
wish for. The choice of algorithms is first about security and second about
interoperability. By assigning *only* one algorithm for each usage, we are
clear what the default algorithms are. For example, Oracle's JDK release will
set them to match our crypto roadmap. Or, an application vendor or system
administrator can choose their algorithms if it can be guaranteed that all
parties using the application or inside a certain enterprise support the
algorithms.
You've got a fair point - but I'd disagree that assigning default
algorithms is about security, it really is about interoperability -
making sure that the most number of people can handle the PKCS12 object
without installing additional providers. But seriously,
|keystore.pkcs12.certProtectionAlgorithm = PBEWithSHA1AndRC2_40|
is not a security choice!
But, after thinking about it a bit more, the preference list isn't
useful without additional providers - and at that point you're probably
generating stuff by specifying algorithms and such so I agree with no
preference list. Could you please, please, please not use weak
algorithms as the default here though?
Thanks
Max
On May 5, 2018, at 10:50 PM, Michael StJohns <mstjo...@comcast.net> wrote:
On 5/5/2018 3:38 AM, Weijun Wang wrote:
Please take a review of
https://bugs.openjdk.java.net/browse/JDK-8202590
This enhancement has two major purposes:
1. Provide a way to change encryption and Mac algorithms used in PKCS 12.
2. The ability to create a password-less PKCS 12 keystore containing
unencrypted certificates and no Mac.
Especially, the long paragraph in the spec on behavior of an existing keystore
makes sure that once a password-less keystore is generated (with
-Dkeystore.pkcs12.certProtectionAlgorithm=NONE and
-Dkeystore.pkcs12.macAlgorithm=NONE), one can add new certificates to it
without any special setting and keep it password-less.
Thanks
Max
I think you want to break this into two parts - the first part specifies the
algorithm used to convert a password into key material. The second defines the
algorithms used for protection for the various parts.
# password to key material scheme
.pbkdf=PBKDF2withHMAC-SHA256 (Form is base function with the PRF)
# PKCS12 macData
.macAlgorithm=HMAC-SHA256 # this is the algorithm for the PKCS12 macData
component, if NONE, this component is not present
# protection scheme for PKCS8ShroudedKeyBagn if NONE, then a PKCS8KeyBag is
produced instead.
.keyProtectionAlgorithm=AES-KWA
#protection scheme for certificates - produces an encryptedData object encrypted under
the scheme, or a certBag object if "NONE" is specified
.certProtectionAlgorithm=NONE
Second, you probably want to do this as multi-choice entries in the
java.security file ala providers:
.pbkdf.0=PBKDF2withSHA256
.pbkdf.9=PBKDF1withSHA1 # the current default aka pbe
So that you can specify a somewhat secure default, but still allow for
providers that don't implement the stronger versions.
This requires a bit more work in figuring out what the embedded OIDs should be,
and there is always the chance of mismatch, but it turns out there is the
chance of mismatch even in the proposed version if you have protection
algorithms coming from two different PBE schemes.
Specifying it this way is closer to the PKCS5 2.0 model rather than PKCS12 and
matches the recommendations in the IETF's version of PKCS12. You also *really*
don't want to use two different KDFs with the same password.
Mike
