![نقل قول](images/misc/quote_icon.png)
نوشته شده توسط
SZsXsZS
ضمنا روی سوال خودم بیشتر فکر کردم فکر کنم صورت سوالم اشتباه بوده اصلا نیازی نیست 256 باشه همون 128 هم کفایت میکنه خخخ
![لبخند گشاده!](images/smilies/yahoo/109.gif)
البته واسه اطمینان شاید بعدا رفتم crypto.stackexchange.com پرسیدم!
آره حتما بپرس...
معلوم شد خودتم نمودونی چی داری میگی![قهقهه](images/smilies/yahoo/124.gif)
If you cannot use GCM (for lack of support in your server-side programming framework), then you must do things old-style:
- Hash the key K with SHA-256 so as to get 256 bits of "key material". Split that into two halves: 128 bits for encryption (Ke), 128 bits for MAC (Km).
- Generate a random IV of 128 bits. You need a new one every time you encrypt, and you want to generate it with a strong PRNG (/dev/urandom).
- Pad the data (usual PKCS#5 padding) so that its length is a multiple of the AES block size (16 bytes).
- Encrypt the data with AES in CBC mode, using the IV generated just above, and Ke as key. Let's call C the resulting ciphertext.
- Compute HMAC/SHA-256 with key Km over the concatenation of IV and C, in that order. Call M the resulting value. It is crucial that the IV is part of the input to HMAC.
- Concatenate IV, C and M, in that order. This is your "registration key".
- When receiving a registration request, first verify the HMAC (by recomputing it), then (and only then) proceed to the decryption step.
میتونی بخونی یا ترجمه کنم برات؟