search

kaikramer / keystore-explorer

KeyStore Explorer is a free GUI replacement for the Java command-line utilities keytool and jarsigner.
https://keystore-explorer.org/
GNU General Public License v3.0
1.7k stars 275 forks source link

Incorrect display name `HMAC SHA-256` for OID 1.2.840.113549.2.9 on secret key generation (depending of keystore) #344

Closed The-Lum closed 1 year ago

The-Lum commented 2 years ago

Describe the bug The name HMAC SHA-256 for OID 1.2.840.113549.2.9 on Secret Key generation (depending of keystore) is not always display, some time only the OID.

To Reproduce Steps to reproduce the behavior:

  1. Generate HMAC SHA-256 Secret Key
  2. View Key, depending keystore format...
  3. See error

Expected behavior See the name HMAC SHA-256 instead of the OID.

Screenshots Here are some examples of HMAC key generation, depending of the keystore type:

UBER or BKS

PKCS#12

BCFKS

Error:

java.security.UnrecoverableKeyException: BCFKS KeyStore unable to recover secret key (key_bcfks): no such algorithm: 1.2.840.113549.2.9 for provider BC
    at org.bouncycastle.jcajce.provider.keystore.bcfks.BcFKSKeyStoreSpi.engineGetKey(Unknown Source)
    at org.bouncycastle.jcajce.provider.keystore.bcfks.BcFKSKeyStoreSpi$Std.engineGetKey(Unknown Source)
    at java.base/java.security.KeyStore.getKey(KeyStore.java:1057)
    at org.kse.gui.KeyStoreTableModel.getKeyInfo(KeyStoreTableModel.java:405)
    at org.kse.gui.KeyStoreTableModel.load(KeyStoreTableModel.java:208)
    at org.kse.gui.KseFrame.updateControls(KseFrame.java:2730)
    at org.kse.gui.actions.GenerateSecretKeyAction.generateSecret(GenerateSecretKeyAction.java:166)
    at org.kse.gui.actions.GenerateSecretKeyAction.doAction(GenerateSecretKeyAction.java:84)
    at org.kse.gui.actions.KeyStoreExplorerAction.actionPerformed(KeyStoreExplorerAction.java:93)

Environment

Contrary to #340, I have no idea to indicate the code to change... Regards.

kaikramer commented 1 year ago

Well, the value for "algorithm" depends on the capabilities of the JCE provider that is backing the KeyStore type.

In the case of PKCS#12, JCEKS and JKS it's the SUN provider of the JRE, which means there are differences when using different versions of the JRE. For example the included Java 17 shows the right algorithm name:

grafik

So for these keystore types this not surprising and while I could implement a workaround, by translating the OID into something human-readable, it would only mask the real issue and probably cause other problems somewhere else. It is one of those fundamental disadvantages that KSE has compared to keytool: Keytool only has to work with exactly one Java version, while KSE currently supports everything from Java 8 up to 19, the currently latest one (and Java 8 has had so many drastic changes in its overly long lifetime that it hardly counts as a single version). IMHO there are already too many workarounds in KSE for handling issues with older Java versions and this is simply not sustainable in the long run.

For BCFKS things are a bit more complicated. Everything (BC documentation, provider infos, source code) says that HMAC-SHA256 is supported and should work but for some reason it does not... I will have to debug through the BC code, which requires some preparation and therefore will take some time.

The-Lum commented 1 year ago

Ok, that responds at my interrogation:

the value for "algorithm" depends on the capabilities of the JCE provider that is backing the KeyStore type.

Then you can do whatever you want with this issue. Regards.