PBKDF2 avec bouncycastle en Java

Je suis en train de stocker en toute sécurité d'un mot de passe dans une base de données et pour cela j'ai choisi de stocker ses hash généré à l'aide de la fonction PBKDF2. Je veux faire cela en utilisant le château gonflable bibliothèque, mais je ne sais pas pourquoi je ne peux pas le faire fonctionner à l'aide de la JCE de l'interface...
Le problème est que la génération de la valeur de hachage dans 3 modes différents:

1. à l'aide de la PBKDF2WithHmacSHA1 clé secrète de l'usine offerts par la sun

2. en utilisant le château gonflable directement l'api

3. en utilisant le château gonflable par la JCE

résultats dans les 2 valeurs distinctes: une qui est commune pour les deux premiers et un pour le troisième.

Voici mon code:

    //Mode 1

    SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
    KeySpec keyspec = new PBEKeySpec("password".toCharArray(), salt, 1000, 128);
    Key key = factory.generateSecret(keyspec);
    System.out.println(key.getClass().getName());
    System.out.println(Arrays.toString(key.getEncoded()));

    //Mode 2

    PBEParametersGenerator generator = new PKCS5S2ParametersGenerator();
    generator.init(PBEParametersGenerator.PKCS5PasswordToUTF8Bytes(("password").toCharArray()), salt, 1000);
    KeyParameter params = (KeyParameter)generator.generateDerivedParameters(128);
    System.out.println(Arrays.toString(params.getKey()));

    //Mode 3

    SecretKeyFactory factorybc = SecretKeyFactory.getInstance("PBEWITHHMACSHA1", "BC");
    KeySpec keyspecbc = new PBEKeySpec("password".toCharArray(), salt, 1000, 128);
    Key keybc = factorybc.generateSecret(keyspecbc);
    System.out.println(keybc.getClass().getName());
    System.out.println(Arrays.toString(keybc.getEncoded()));
    System.out.println(keybc.getAlgorithm());

Je sais que PBKDF2 est mis en œuvre à l'aide de l'algorithme HMAC SHA1 c'est pourquoi j'ai choisi comme l'algorithme dans la dernière méthode de la "PBEWITHHMACSHA1" que j'ai pris depuis le château gonflable java docs.

Le résultat est le suivant:

com.sun.crypto.provider.SunJCE_ae
[-53, 29, 113, -110, -25, 76, 115, -127, -64, 74, -63, 102, 75, 81, -21, 74]
[-53, 29, 113, -110, -25, 76, 115, -127, -64, 74, -63, 102, 75, 81, -21, 74]
org.bouncycastle.jce.provider.JCEPBEKey
[14, -47, -87, -16, -117, -31, 91, -121, 90, -68, -82, -31, -27, 5, -93, -67, 30, -34, -64, -40]
PBEwithHmacSHA

Des idées?

Je ne suis pas sûr de ce que "Mode 3" est en train de faire, mais je préfère l'ignorer. Il est de sortie est de 160 bits, 128 pas, comme vous l'avez demandé. 160 bits est de la taille d'un hachage SHA-1. Pour la portabilité, je collerais avec le "Mode 1."
Je suis d'accord avec erickson - est-il un réel besoin pour vous d'utiliser le "Mode 3" ou "Mode 1" être acceptable pour le stockage en toute sécurité le mot de passe? Bonne question détaillée pour votre première question, ici, par la manière.
Il n'est pas nécessaire en effet. J'essaie juste de comprendre pourquoi la PBEWITHHMACSHA1 de BouncyCastle ne pas faire la même chose. Et je suis d'accord, je n'aurais pas choisi la deuxième méthode en raison de problèmes de portabilité.
Merci s'accoupler, le numéro 1 de sauver ma vie au travail 😀

InformationsquelleAutor andrei.serea | 2011-12-29

30

En bref, la raison de cette différence est que PBKDF2 l'algorithme dans les modes de #1 et #2 utilise le fichier PKCS #5 v2 (schéma 2) (PKCS5S2) pour itératif de génération de clé, mais la BouncyCastle fournisseur pour "PBEWITHHMACSHA1" en mode #3 utilise le fichier PKCS #12 v1 (PKCS12) algorithme de la place. Ceux-ci sont complètement différents de la génération des algorithmes, de sorte que vous obtenez des résultats différents.

Plus de détails sur les raisons et pourquoi vous obtenez différentes tailles de résultats est expliquée ci-dessous.

Tout d'abord, lorsque vous êtes à la construction d'une entreprise criminelle commune KeySpec, le keyLength paramètre n'exprime qu'une "préférence" pour le fournisseur de ce que la taille de la clé que vous voulez. De l'API docs:

Note: ceci est utilisé pour indiquer la préférence sur une longueur de clé variable-clé de la taille d'algorithmes. La clé réelle de la taille dépend de chaque fournisseur la mise en œuvre.

Le Château Gonflable fournisseurs n'apparaissent pas à l'égard de ce paramètre, à en juger par la source de JCEPBEKey, de sorte que vous devriez vous attendre à obtenir une clé 160 bits à partir de n'importe BC fournisseur qui utilise l'algorithme SHA-1 lors de l'utilisation de la JCE de l'API.

Vous pouvez confirmer cela par programmation, en accédant à la getKeySize() méthode sur le revenu keybc variable dans votre code de test:
```
Key keybc = factorybc.generateSecret(keyspecbc);
//...
Method getKeySize = JCEPBEKey.class.getDeclaredMethod("getKeySize");
getKeySize.setAccessible(true);
System.out.println(getKeySize.invoke(keybc)); //prints '160'
```
Maintenant, pour comprendre ce que le "PBEWITHHMACSHA1" fournisseur correspond à, vous pouvez trouver les informations suivantes dans la source pour BouncyCastleProvider:
```
put("SecretKeyFactory.PBEWITHHMACSHA1", 
    "org.bouncycastle.jce.provider.JCESecretKeyFactory$PBEWithSHA");
```
Et la mise en œuvre de JCESecretKeyFactory.PBEWithSHA ressemble à ceci:
```
public static class PBEWithSHA
    extends PBEKeyFactory
{
    public PBEWithSHA()
    {
        super("PBEwithHmacSHA", null, false, PKCS12, SHA1, 160, 0);
    }
}
```
Vous pouvez le voir ci-dessus que cette clé usine utilise le fichier PKCS #12 v1 (PKCS12) algorithme itératif de génération de clé. Mais l'algorithme PBKDF2 que vous souhaitez utiliser pour le hachage de mot de passe utilise le fichier PKCS #5 v2 (schéma 2) ( PKCS5S2 ) à la place. C'est pourquoi vous êtes obtenir des résultats différents.

J'ai eu un coup d'oeil rapide à l'entreprise criminelle commune, fournisseurs inscrits dans BouncyCastleProvider, mais ne pouvait pas voir tout de génération de clés, algorithmes utilisés PKCS5S2, et encore moins celui qui l'utilise également avec HMAC-SHA-1.

Donc je suppose que vous êtes coincé soit avec l'aide du Soleil, de la mise en œuvre (mode #1 ci-dessus) et de perdre la portabilité sur d'autres machines virtuelles, ou en utilisant le Château Gonflable classes directement (mode #2 ci-dessus) et l'exigence de la colombie-britannique de la bibliothèque au moment de l'exécution.

De toute façon, vous devriez probablement passer à 160 bits clés, afin de ne pas tronquer le générés hachage SHA-1 inutilement.

InformationsquelleAutor Matt Ryall

J'ai trouvé un BC Crypto-Seule méthode (en fait à partir du cms paquet de la colombie-britannique), qui vise à produire de l'UTF-8 en fonction mot de passe d'encodage. De cette façon, je peux générer des KDF sortie, ce qui est compatible à

http://packages.python.org/passlib/lib/passlib.hash.cta_pbkdf2_sha1.html#passlib.hash.cta_pbkdf2_sha1

private byte[] calculatePasswordDigest(char[] pass, byte[] salt, int iterations)
    throws PasswordProtectionException
{
    try
    {
        /* JCE Version (does not work as BC uses PKCS12 encoding)
        SecretKeyFactory kf = SecretKeyFactory.getInstance("PBEWITHHMACSHA1","BC");
        PBEKeySpec ks = new PBEKeySpec(pass, salt, iterations,160);
        SecretKey digest = kf.generateSecret(ks);
        return digest.getEncoded();
        */
        PKCS5S2ParametersGenerator gen = new PKCS5S2ParametersGenerator();
        gen.init(PBEParametersGenerator.PKCS5PasswordToUTF8Bytes(pass), salt, iterations);
        byte[] derivedKey = ((KeyParameter)gen.generateDerivedParameters(160)).getKey();
        return derivedKey;
    }
    catch(Exception e)
    {
        LOG.error("Failed to strengthen the password with PBKDF2.",e);
        throw new PasswordProtectionException();
    }
}

InformationsquelleAutor eckes

PBKDF2WithHmacSHA1 est déjà pris en charge dans BouncyCastle 1.60

https://www.bouncycastle.org/specifications.html
Hachage de mot de passe et PBE

Test réussi avec OpenJDK de l'Environnement d'Exécution de 18,9 (version 11.0.1+13):

    Security.addProvider(new BouncyCastleProvider());

    String password = "xrS7AJk+V6L8J?B%";
    SecureRandom rnd = new SecureRandom();
    int saltLength = 16;
    int keyLength = 128;
    int iterationCount = 10000;

    byte[] salt = new byte[saltLength];
    rnd.nextBytes(salt);

//SunJCE
    SecretKeyFactory factorySun = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1", "SunJCE");
    KeySpec keyspecSun = new PBEKeySpec(password.toCharArray(), salt, iterationCount, keyLength);
    SecretKey keySun = factorySun.generateSecret(keyspecSun);
    System.out.println(keySun.getClass().getName());
    System.out.println(Hex.toHexString(keySun.getEncoded()));

//BouncyCastle  
    SecretKeyFactory factoryBC = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1", "BC");
    KeySpec keyspecBC = new PBEKeySpec(password.toCharArray(), salt, iterationCount, keyLength);
    SecretKey keyBC = factoryBC.generateSecret(keyspecBC);
    System.out.println(keyBC.getClass().getName());
    System.out.println(Hex.toHexString(keyBC.getEncoded()));

    Assert.assertArrayEquals(keySun.getEncoded(), keyBC.getEncoded());

La sortie est:

com.sun.crypto.provider.PBKDF2KeyImpl
e9b01389fa91a6172ed6e95e1e1a2611
org.bouncycastle.jcajce.provider.symmetric.util.BCPBEKey
e9b01389fa91a6172ed6e95e1e1a2611

InformationsquelleAutor Lancelot Chen

Vous devez vous connecter pour publier un commentaire.