Longueur d'une SecretKey

Bonjour à tous,

Voilà mon souci :

Je cherche à stocker une SecretKey que je génère (AES 128) dans une BDD.
Je fais donc une conversion en String via un BASE64Encoder.

Mais la question à laquelle je ne trouve pas de réponse c'est quelle est la longueur de la clé générée ?

J'ai évidement testé et vu que la longueur de ma String était de 24 caractères, mais est-ce que cette taille est constante ?

Si non... pourquoi ? et quelle peut être la taille max ?
Si oui... pourquoi ? (un rapport entre 128 et 24 ???)

Merci d'avance :)


[Edit] Je viens de remarquer que la clé termine systématiquement par "==" ...

les == c'est lié je pense à l'encodage en base 64 que tu as fait via BASE64Encoder.

Mais en fait ici c'est pas le problème.

Une clef de chiffrement pour un algorithme symétrique est de longueur fixe (pour un algo asymétrique aussi d'ailleurs mébon).

AES128 = 128 bits soit un tableau de 16 bytes (128 / 8 = 16).

On ne stocke pas un clef de chiffrement dans une BDD. La sécurité devient tellement faible qu'il n'y a plus aucun intérêt à chiffrer quoi que ce soit.

On stocke une clef dans un magasin de clés, le standard étant PKCS#12. Java dispose aussi d'un magasin spécial nommé JKS. Regardes du côté de KeyStore.

Ceci dit pour revenir à tes questions :

Citation:

---

J'ai évidement testé et vu que la longueur de ma String était de 24 caractères, mais est-ce que cette taille est constante ?

---

Donc 24 c'est la longueur de ta clef après passage dans BASE64Encoder. C'est logique vu que Base64 augmente d'environ un tiers la taille des données qu'il encode.

Donc 24 * 0.66 = 15.84 donc ça colle avec la longueur de ta clef AES.

Mais encoder en Base64 n'est pas une bonne idée. Utilises un magasin.

Ok !

Merci pour les réponses :)

Je travaille sur une appli web, je dois donc stocker mes infos en BDD...

En fait, je crypte la valeur d'un cookie j'enregistre un ID+séquence (générée)+clé de cryptage en base.
J'interroge ensuite la base via l'ID, qui me retourné la séquence+clé et je décrypte le cookie pour vérifier la que la séquence est bonne.

Ceci est fait après vérification d'un login/mdp et le chiffrement du cookie n'est pas vraiment nécessaire, c'est juste une demande client :roll:

Merci encore pour tes réponses et pour le KeyStore que je ne connaissait pas !

Citation:

---

Envoyé par kronos85

Ok !

Je travaille sur une appli web, je dois donc stocker mes infos en BDD...

---

Pourquoi ce corollaire. Tu peux très bien avoir des applis web qui ne stockent absolument rien dans une BDD (dans du XML par exemple, ou alors ne fait des que des opérations dépendant de services externes ou que ne sais-je encore). Et puis stocke bien certains paramètres dans des fichiers properties ou de configuration (genre web.xml ou autres).
Ce que tu dis au dessus est éminemment faux.

De plus les conteneurs web (type tomcat) ou JEE (type FlassFish, WebSphere & cie) possède tout le nécessaire pour stocker des clefs de ce type et offrent directement un KeyStore à disposition. De fait stocker une clef de cryptage hors du KeyStore serait une faute professionnelle, et une porte ouverte aux failles de sécurité.

Oui le corolaire est faux, sauf quand il est imposé par le client :)

Par contre, comme je le disais également, je ne connaissait pas le KeyStore, mais en effet, si le serveur d'app le permet, il me semble bien meilleur de l'utiliser.

Mais pourquoi ton client veut ça ?

Il n'y a aucun intérêt à faire une chose pareille. Du moins j'en comprends pas les raisons.

Le client est peut être roi mais c'est pas parce qu'il exige quelque chose dans un premier temps que tu peux pas lui expliquer pourquoi sa demande est infondée. Ça fait aussi parti du boulot (il me semble) d'expliquer aux profanes pourquoi leurs demandes sont inutiles ou posent plus de problèmes qu'elles n'amènent de solution ou qu'elles sont faisable d'une autre manière.

Si le but de est de chiffrer le contenu du cookie sur le poste du navigateur pour masquer des choses à l'utilisateur c'est idiot car si quelqu'un vole la BDD ou parvient simplement à la lire via une SQL injection par exemple il aura accès aux données chiffrées de tout le monde.

Et puis c'est super malpoli.

Oui je suis d'accord, pas de raison apparente de chiffrer ces données, en fait, il n'y a aucune donnée sensible dans ce mécanisme.

C'est le chiffrage en lui-même qui est inutile, j'ai bien remonté l'info, mais "ils" ne s'en soucient pas vraiment, d'autres prios toussa ! En gros ils veulent du chiffrage parce que ça les rassure :roll:

Mais je répète qu'il n'y a aucune donnée sensible qui est chiffrée ou en base (du moins dans cette table en particulier).

Je comprends pas ... Ça les rassure par rapport à quoi ? Si rien n'est sensible ils craignent quoi ...

Pas grave, pour l'instant c'est en l'état, la question du cryptage est entre les mains du client qui a les billes pour faire son choix... conscience tranquille :ccool:

[EDIT] Poire coupée en deux ! on ne génère qu'une clé unique que l'on stocke dans un .properties sur le serveur :)