est ce morceau de code de sécurité?
SecureRandom randomizer = new SecureRandom(String.valueOf(new Date().getTime()).getBytes());
3 Réponses :
Le code est raisonnablement sûr car il n'utilise pas simplement la graine donnée pour semer le randomiseur.
Ce n'est pas beaucoup plus aléatoire que d'utiliser simplement. P>
SecureRandom randomizer = new SecureRandom();
Oui, probablement en utilisant la valeur par défaut est meilleur - on suppose que les concepteurs de l'algorithme choisiraient un bon schéma d'ensemencement. Le régime ci-dessus affaiblit probablement la graine légèrement en convertissant la représentation de caractères.
Il est considérablement moins aléatoire que d'utiliser le constructeur par défaut.
@Peterlawrey Vous recommandez ici d'utiliser «Nouveau SécuritéDom () 'mais à Ce vous dites à utiliser' System.nanOtime '. Dans Cette Situation Devrais-je utiliser «Nouveau SécuritéDandom () 'ou' Système.nanotime '. Merci d'avance
Non, vous devez éviter le Il est non portable car il se comporte différemment sur Windows contre d'autres systèmes d'exploitation. sur la plupart des OSES, l'algorithme par défaut est "natifprng", qui obtient données aléatoires du système d'exploitation (généralement sous Windows, l'algorithme par défaut est "SHA1PRNG", qui combine votre graine Avec un compteur et calcule un hachage du résultat. C'est une mauvaise nouvelle dans votre exemple, car l'entrée UTC actuelle) a une gamme relativement faible de valeurs possibles. Par exemple, si un attaquant sait que le RNG a été ensemencé au cours des 48 dernières heures, ils peuvent réduire la graine à moins de 2 28 valeurs possibles, c'est-à-dire que vous n'avez que 27 bits d'entropie. Si d'autre part, vous avez utilisé le constructeur par défaut Si vous souhaitez vraiment remplacer la graine par défaut (par exemple pour le test de l'unité), vous devez également spécifier l'algorithme. Par exemple voir aussi Comment résoudre le problème de la performance avec Java Securerandom? SECURUERANDOM (octet []) constructeur. Il est à la fois dangereux et non portable. "/ dev / aléatoire" ) et ignore la graine que vous fournissez. SECURUERANDOM () sur Windows, il aurait appelé la fonction native cryptogenrandom pour obtenir une graine de 128 bits . Donc, en spécifiant votre propre graine, vous avez affaibli la sécurité.
et ce blog post: http://www.cigital.com/justice-league-blog/2009/08/14/proper-utilisateur-of-javas-securerandom/
Notez que le code que vous fournissez initialise le générateur pseudo aléatoire avec juste la chaîne codée comme entrée. Cela créerait donc le même aléatoire à chaque fois. Je pense que vous vouliez dire exactement cela, mais vous voudrez peut-être que cela soit plus clair dans la réponse (comme cela n'est certainement pas sécurisé). Il pourrait également être différent si un autre fournisseur offrait "Sha1prng" , donc à cet égard, il est un peu dangereux.
@Maartenboteswes Pourquoi pensez-vous que la graine est ignorée lors de l'utilisation «natifprng»?
@ Alikelzin-Kilaka Il n'est pas possible d'utiliser une graine fournie par l'utilisateur avec / dev / aléatoire . Les fenêtres natives peuvent, mais quand j'ai posté cette réponse, le JRE n'en a pas profité de cela. C'était il y a 4 ans, ce qui peut avoir changé depuis lors.
Je pense qu'il est préférable de laisser la sécurité de la sécurité elle-même. Ceci est fait en appelant les prochainsttes immédiatement après sa création (appelera SetSeed l'empêchera).
final byte[] dummy = new byte[512];
SecureRandom sr = SecureRandom.getInstance("SHA1PRNG");
sr.nextBytes(dummy);
Si le Nextbytes () est destiné à seulement un coup de pied de l'ensemencement, je n'utiliserais pas 512 byes mais seulement 1 pour des raisons d'efficacité.