Lorsque j'essaie de chiffrer une chaîne à l'aide de la bibliothèque de cryptage par CI, la chaîne renvoyée est très grande, environ 178 caractères longs. Il y a une méthode pour réduire la longueur de la chaîne. Cipher par défaut est: AES-128.
Supposons: mise à jour: lorsque je chiffre un numéro, disons 6, il renvoie 178 longues chaînes. $ data = ceci - $ this-> cryptage-> chiffrer ("Bienvenue à Ooty");
Il retourne 178 longueur de chaîne. J'en ai besoin de réduire moins de 20
3 Réponses :
Bien que vous puissiez faire Vous réduiriez grandement l'entropie de la chaîne cryptée et donc la sécurité de ce cryptage. C'est aussi longtemps pour une raison! substr ($ encodedstring, 0, 20) mais ce serait un très mauvaise idée ™
Cela ferait juste une partie du HMAC, qui est inutilisable en soi.
Vous pouvez utiliser une combinaison différente d'algorithme de chiffrement, de mode chiffré et de HMAC qui ajouterait moins de données de données, mais non - le chiffre texte résultant ne sera pas réduit à 20 - le HMAC seul entraînera au moins 28 octets.
Aussi, à en juger par votre description ("environ 178 caractères"), le plaintre lui-même est plus long que 20 octets ... Le cryptage n'est pas une compression, vous ne pouvez pas vous attendre à ce que le chiffre supplémentaire a obtenu une plus petite longueur que le plaintre .
J'ai compris. Mais quand je chiffre juste "1", le résultat est de 178 caractères. J'ai oublié de mentionner ci-dessus, mon erreur.
172, pas 178 ... Mais oui - c'est long et vous ne pouvez pas la descendre à moins de 20 ans. Tout ce que vous essayez de faire, cela devra permettre des longueurs plus longues. Il y a juste une longueur de "base" que vous devez accepter. Sur le côté positif, si / lorsque vous chiffrez des données plus importantes, la différence ne serait pas si grande.
Mais il est en quelque sorte possible en chiffrant la classe de CodeDigniter Ref: codeigniter.com/user_guide/libries/.../a>
@NARF La longueur peut être réduite à la longueur des données à crypter avec un mode de diffusion telle que CTR. HMAC et etc. ne peuvent pas être nécessaires. Tout dépend de l'application / du protocole utilisé. Aussi le niveau de sécurité requis.
@zaph, vous n'êtes pas censé omettre l'authentification, je n'ai intentionnellement pas mentionné que, car il n'y a pas de "niveau de sécurité requis" - il est sécurisé ou non. Si quelqu'un regarde le code et dit que le CIPHertext manque d'authentification, c'est automatiquement un rapport de bogue valide.
Il existe des protocoles où l'authentification des données cryptées n'est pas effectuée / nécessaire. Il existe un "niveau de sécurité", plusieurs fois appelé "facteur de travail". Si vous avez une clé de cryptage sur un serveur, il n'est pas sécurisé, si vous utilisez le cryptage logiciel n'est pas sécurisé (ma femme rira du cryptage logiciel informatique). Déplacez-vous à une HSM et à la sécurité physique et vous venez vraiment près mais 100%. Mais tous les chiffres ne nécessitent pas un HSM avec une sécurité physique, il existe des niveaux de sécurité, on choisit le niveau nécessaire pour contrecarrer un certain niveau d'attaquant en tenant compte de la valeur des données.
Je suggère qu'un "niveau de sécurité" HSM n'est pas nécessaire pour les scores TIC-TAC-TOE.
Vous savez ce que je voulais dire aussi bien que vous savez que l'OP n'essaie pas de cacher les scores Tic-Tac-toe et qu'ils ne savent probablement pas s'ils ont besoin d'authentification ou non.
Le point est que vous avez dit: Il n'y a pas de "niveau de sécurité requis" - il est sécurisé ou non. Mais c'est une déclaration complète et incorrecte. La sécurité consiste à accroître le facteur de travail pour répondre à la sécurité requise. L'OP peut être en mesure de ne pas fournir le niveau de sécurité nécessaire, mais nous ne savons pas. Ensuite, nous avons PHP McRypt écrit par des Bozos qu'ils n'incluaient pas la noix de PKCS n ° 7 Née PKCS n ° 5 comme une option fournissant uniquement un rembourrage NULL et il est supposé qu'ils savent ce qu'ils font? Conservez-vous toujours qu'il n'existe pas de "niveau de sécurité requis"?
Si vous êtes enfermé à prouver que vous avez raison sur "Le point" que vous avez choisi arbitrairement d'un commentaire que vous savez était bien significatif - bien, vous avez raison. Mais s'il vous plaît rappelez-vous que nous sommes sur Stackoverflow, pas crypto.stackexchange.com, et les gens vont prendre les mauvaises décisions lors de leurs autres options que «sécurisées ou non».
@zaph, je peux penser à un certain nombre de cas d'utilisation pour cryptage lorsque le cryptage authentifié n'est pas strictement nécessaire, mais le chevauchement avec ce que la plupart des développeurs implémentent pratiquement zéro.
cryptage ne réduit pas la longueur des données.
La longueur de la sortie de cryptage AES dépend du mode. Un mode de streaming tel que le mode CTR ne changera pas la longueur. Un mode de bloc tel que BCE ou CBC devra être rembourré à un multiple de longueur de bloc mais le rembourrage n ° 7 PKCS n'augmentera que la longueur d'une taille de bloc maximale, 16 octets pour AES.
Il y a plus de choses que de crypter les octets. Un mode tel que CBC peut être utilisé et l'IV (une longueur de bloc) peut être préparé aux données cryptées. L'authentification peut être ajoutée et pouvait ajouter peut-être 32 octets. Il peut y avoir une dérivation de mot de passe et le sel et le nombre peuvent être ajoutés. Enfin, le résultat peut être codé pour base64 ou hexadécimal qui augmenterait la longueur respectivement de 33% ou 100%.
cas potentiel: "Bienvenue à Ooty" est de 15 octets. Le rembourrage est de 1 octet, authentification 32 octets, sel 32-octets, comptage 2 octets, version 1-octet = 83 octets, hexcode codé = 166 octets, près des 178 octets que vous obtenez.
Tout cette sécurité supplémentaire achète. En fonction de votre utilisation, cela peut ne pas être nécessaire, consultez un expert de domaine cryptographique.
Mais la question reste-t-elle, comment réduire la longueur de la chaîne cryptée dans le codeignier?
@Mujahedakas La réponse est: ça ne peut pas. Le cryptage ne peut pas, ne peut pas réduire la longueur des données, la longueur cryptée est la même que la longueur d'entrée et tout rembourrage. Un meilleur codage ou compression peut être en mesure de réduire la longueur avant le cryptage.
J'ai aussi besoin de cela si possible
"Bienvenue à Ooty" Vous avez orthographié butin
Vous ne pouvez pas changer la chaîne cryptée en base64? Cela devrait réduire la taille.
@ Кодсерфинг145 Non, ça ne va pas ... Base64 ajoute au moins 33% en hauteur et
CI_ENCROMPTIONBASE64_ENCODE () Le CIPHERTEXT par défaut.@Narf oh oh ok je comprends = p Eh bien, alors peut-être essayer ceci: github.com/ferno/base65536 xD probablement inutile
@ Кодсерфинг145 qui ne vous aidera pas non plus ... NO type de codage aidera.
@Narf mais il est d'une manière ou d'une autre possible en chiffrement de la classe de CodeDigniter Ref: codeigniter.com/user_guide/libries/.../a>.
Que faites-vous cela nécessite des caractères "moins de 20"?
Mais dans ce cas, vous ne serez pas capable de déchiffrer