Je veux crypter la chaîne à base64, l'entrée de la chaîne peut être en longueur différentielle (la limite est de 16 caractères) et je souhaite obtenir la chaîne cryptée en longueur fixe.
Est-ce que quelqu'un sait de la manière de le faire dans le cadre ?NET? ou a un algorithme pour faire ça?
4 Réponses :
(EDIT: Je suppose que vous voulez que vous voulez chiffrer une chaîne, puis encoder résultat comme base64, en finissant toujours avec la même longueur de sortie. Cela vous aiderait si vous pouviez clarifier la question pour confirmer cela ou expliquerait ce que vous les veux si ce n'est pas le cas.)
Eh bien, il y a un assez simple algorithme qui fonctionnerait compte tenu de tout schéma de cryptage qui chiffre toujours une entrée d'une longueur fixe à une sortie d'une longueur fixe (et il y a beaucoup de ceux):
Pour déchiffrer, simplement inverser le processus:
(Utilisez MSDN pour trouver des détails de chaque étape et n'hésitez pas à demander de l'aide dans une partie spécifique. Votre choix d'algorithme de cryptage dépendra de ce que vous essayez de faire, et je ne suis pas un expert à ce sujet, J'ai peur.)
Edit: Si vous avez seulement besoin d'un hachage, d'autres questions entrent en jeu. Voulez-vous toujours que la même chaîne finisse par être hachée à la même chaîne? C'est généralement souhaitable pour hachage mais pas cryptage.
convert.tobase64string
convert.frombase64string
Son look bien, si ce n'est pas important pour moi de déchiffrer la chaîne, mais je veux que Alaways je donne la corde cryptée de 22 charcuts, que puis-je faire? Pouvez-vous joindre un extrait de code en démontrant cela?
@RRRR: Si vous n'avez jamais besoin de déchiffrer la chaîne, vous recherchez un hash plutôt que du cryptage. Ce sont des algorithmes complètement différents et vous devez donner vos exigences précisément. Voir mon édition à la fin de la réponse.
Oui, toujours je veux que la même chaîne finisse par être ignorée à la même chaîne, mais savez-vous sur le hachage qui me donne toujours la sortie sur la longueur kixède - 22 charcuters?
@Rrr: Eh bien, la base droite64 ne va jamais vous donner 22 caractères, car il s'agira toujours d'un multiple de 4. Vous pouvez obtenir 15 octets de données brutes dans 20 caractères ou 18 octets dans 24. Vous pouvez toujours utiliser un supplément rembourrage cependant. Pourquoi avez-vous besoin exactement de 22 caractères et si cela est vraiment une exigence, pourquoi ne l'avez-vous pas mentionné dans la question? Toute autre exigence que nous devrions connaître?
Il n'est pas judicieux de minimiser la longueur du hachage résultant, car il sera plus facile pour tout programmeur avec certains cerveaux d'obtenir la chaîne source de manière très élémentaire
Et pourquoi exactement 22 caractères?
Ho, sage ou pas ce n'est pas ce que j'ai demandé, je devrais exactement 22 caractères parce que je sénérez la chaîne à un autre programme pouvant recevoir seulement 22 caractères, je ne peux pas le changer!
@RRRR: 22 caractères n'est pas ce que vous avez demandé à l'origine non plus, ni de hachage. Si vous vous posez mal une question, vous ne devriez pas être surpris lorsque les gens posent beaucoup de questions à ce sujet.
Peut-être que Yoy doit être d'accord avec moi que ce n'est pas très important si 22 caractères ou un autre numéro, ce que cela est important que je nedd que sur la longueur fixe, et je le pose sur la question fondamentale.
@RRRR: Non, c'est très important - parce que vous avez dit "une longueur fixe" plutôt que la longueur de . En d'autres termes, je pensais que c'était bien pour des réponses pour trouver une longueur qu'ils voulaient, tant que cela donnerait la même longueur pour toute entrée. Ajoutez que le fait que vous souhaitiez hachage plutôt que de cryptage, et vous avez essentiellement écrit une question qui aurait été très difficile à répondre à votre satisfaction, autre que par la chance.
22 Les caractères de base64 sont très importants car il est plus petit que l'entropie d'un 16 caractères unicodes. Donc, crypter la chaîne d'entrée comme demandé dans votre question initiale est mathématiquement impossible pour le cas général. Je pense que vous auriez besoin de 44 caractères de base64 pour faire du cryptage possible. Et le schéma Jon Skeet proposé utilise une sortie de charcuterie 44, il offre une sortie de longueur fixe la plus courte possible en considérant que vous avez dit que vous souhaitez chiffrer l'entrée et non le hayh.
@Jonskeet pouvons-nous avoir un échantillon de code pour cela. J'ai essayé de suivre les étapes mentionnées ci-dessus, je ne suis pas capable de comprendre cette étape "Pad les données binaires à 32 octets (c'est-à-dire la taille maximale) à l'aide de données aléatoires"
@Shahidmanzoorbhat: éventuellement à un moment donné, mais probablement pas aujourd'hui. (Je ne vais pas le considérer comme urgent étant donné que cette réponse a déjà 9 ans ...) Vous voudrez peut-être poser une question spécifique à ce sujet, y compris ce que vous avez déjà essayé.
Merci @jonskeet apprécier que :)
@ Jonskeet Si je reçois une valeur de 8 octets après l'encodage UTF-16 dans la deuxième étape, dois-je ajouter 24 octets d'origine à la valeur d'origine?
@Shahidmanzoorbhat: Oui, supposant que vous ayez la même longueur fixe attendue que dans la question.
Si vous recherchez un cryptage à 1 voie (pas besoin de déchiffrer), vous pouvez utiliser SHA1
string secretKey = "MySecretKey";
string salt = "123";
System.Security.Cryptography.SHA1 sha = System.Security.Cryptography.SHA1.Create();
byte[] preHash = System.Text.Encoding.UTF32.GetBytes(secretKey + salt);
byte[] hash = sha.ComputeHash(preHash);
string password = System.Convert.ToBase64String(hash);
Pourquoi pensez-vous que quelqu'un qui veut utiliser base64 devrait utiliser SHA?
Je comprends toujours le terme "cryptage" à signifier à deux sens - c'est juste un hachage. Néanmoins, non -1 comme il peut Soyez ce que l'OP veut et a mal exprimé.
@Vash, de ma compréhension, il veut crypté puis convertir en base64. Il a dit "Je veux crypter la chaîne à base64". S'il a dit qu'il voulait coder, nous n'avons pas besoin de SHA1.
@Fun: S'il avait voulu un hachage à sens unique, j'espère qu'il aurait dit :)
@ Jon-Skeet, hachage peut convenir si son objectif est de stocker du code secret pouvant être vérifié plus tard sans compromettre le secret réel. J'ai eu cette idée de son exigence d'une sortie de longueur fixe. Il est peut-être toujours possible qu'il souhaitait que je souhaitais que j'avais mentionné RSA.
@Fun Mun Pieng, assez juste, merci de pointer cela. Mais je pense toujours qu'il est parfois préférable de poser des questions sur les besoins, puis de donner une réponse. En outre, je pense que c'est probablement une situation qui manquait de comprendre la signification du cryptage que ce qu'il doit utiliser (codage de base64).
J'essaie ce code, il cherche ce dont j'ai besoin, mais c'est le résultat toujours de 28 caractères?
Oui, le résultat est toujours la même longueur quelle que soit l'entrée. La sortie est toujours de 28 caractères. SHA1 génère toujours 160 bits, soit 20 octets. 20 octets codés dans la base64 sont toujours de 28 caractères.
Il existe un exemple très clair dans le bas de cette Référence MSDN
Dans des mots plus clairs, vous devez utiliser RSA avec un algorithme de hachage telle que SHA1 dans l'exemple précédent. L'utilisation d'algorithmes SHA consiste à transformer toute chaîne de longueur arbitraire en chaîne de longueur fixe et donc si vos chaînes sont de 1 000 000 000 caractères, par exemple. Vous n'avez pas besoin de 1 000 000 000 octets pour les stocker. Vous n'avez besoin que de stocker la chaîne résultante après avoir appliqué des algorithmes Sha, soit 160 caractères dans le cas de SHA1. Je pense que dans votre cas, vous n'avez besoin que de chiffrer et de ne pas chiffrer. L'avantage de l'utilisation des algorithmes Sha est de sécuriser vos données codées. Sinon, tout mec intelligent pourra déchiffrer votre chaîne cryptée.
Comme vous devez avoir besoin d'un hachage résultant moins long que les célèbres fonctions de hachage, il y a plusieurs façons, un moyen célèbre est de Xor les 22 premiers octets du hachage résultant dans un
Tout d'abord, "base64" n'est pas un cryptage, il s'agit simplement d'un encodage ou d'une encapsulation de transport. Il est destiné à transférer des données binaires sur un transport qui permet uniquement aux caractères ASCII.
second, "base64" sa longueur est une longueur variable, nous devons donc plafonner la corde codée manuellement et retirer le rembourrage pour le décodage.
Cependant, le code suivant montre comment accomplir votre objectif.
Non, base64 n'est pas conçu pour coder Strings en tant que caractères ASCII. Il est d'encoder Données binaires arbitraires en tant que caractères ASCII. Grande différence.
OK, son travail errant si vous la chaîne codée à la longueur qui trite de la limite, mais que pouvez-vous faire quand c'est plus long? Je sais que je peux couper les charcuts supplémentaires, mais ce n'est pas un risque que j'accepte pour différentes chaînes d'entrée, même sortie codée?
Je ne comprends pas pour quelle longueur de cheveux? et pourquoi j'ai besoin d'utiliser une longueur fixe s'il est réglé sur 43 ?
@ user2167382: l'affiche originale souhaitée aux données codées pour avoir une longueur fixe. Cette 43 est la longueur de sortie fixe que mon code génère, tant que les données d'entrée sont suffisamment courtes.
@Rrr Oui, bien sûr. Si la chaîne d'entrée est trop longue pour la taille de sortie fixe, vous devez gérer cette condition. Dans ma mise en œuvre, je crée simplement une chaîne de sortie plus longue, mais vous pouvez également tronquer (avec une perte de données) ou jeter une exception.
Juste parce qu'il y avait une "suggestion d'édition" hier, ici quelques éclaircissements: (x / 4) * 4 n'est pas égal à x avec des arithmétiques entier. L'expression ((index + 3) / 4) * 4 arrondit l'index au prochain multiple de 4. Testez-le vous-même, e. G. en Python: >>> pour i in gamme (10): Impression I, ((i + 3) / 4) * 4 ... 0 0 1 4 2 4 3 4 4 4 4 5 8 6 8 7 8 8 8 9 12
base64 est coding , pas de cryptage (ce qui signifie qu'il ne vous donne aucune sécurité). Il est utilisé pour convertir une donnée binaire en une textuelle (c'est-à-dire une qui utilise des caractères extrêmement imprimables). Est-ce ce dont vous avez besoin?
Les codépoints Unicode en dehors de l'avion de base comptent-ils deux caractères ou un seul? Un point de code Unicode ne convient pas à un charret 16 bits.
Est-ce votre chaîne d'entrée limitée à 16 caractères, ou votre chaîne de sortie? Si votre entrée est limitée à 16 caractères, ce que vous recherchez est faisable avec soin. Si votre sortie est limitée à 16 octets, mais vos entrées ne sont pas, vous ne traitez pas de cryptage (réversible) mais avec hachage. Et 16 octets de codage de base-64 ne peuvent contenir que 96 bits, de sorte que vos choix d'algorithme de hachage sont un peu constitués (ou vous devez hacher la valeur produite par un algorithme plus long à 96 bits).