CODEWITHSUNDEEP
javaencryptionhexbyte
forum.test17
forum.test17

Reputation: 2219

How to store iv, salt and cipher text?

From this on how to achieve password based encryption it is clear that i need to save salt, IV and cipher text in order to decrypt it later.

From this iv and salt can be stored along with cipher text

I am storing the hex value in this format

DatatypeConverter.printHexBinary(salt) + DatatypeConverter.printHexBinary(iv) + DatatypeConverter.printHexBinary(ciphertext);

Do i need to store the values in Binary format ?

DatatypeConverter.printBase64Binary(salt) + DatatypeConverter.printBase64Binary(iv) + DatatypeConverter.printBase64Binary(ciphertext));

output clearly indicates the where the salt , iv is ending which is awful

lIvyAA/PZg4=fE4gTZUCPTrKQpUKo+Z1SA==4/gAdiOqyPOAzXR69i0wlC7YFn9/KOGitZqpOW2y3ms=

Will storing in hex format have any effects of data loss ?

Will the length of IV is constant ? in my case it is always 32 characters (hexadecimal) Or i need to even store length of IV as well ? as the salt length is fixed initially to 8 bits (16 hexadecimal characters)

(I am using PBKDF2WithHmacSHA1 algorithm for key generation and AES/CBC/PKCS5Padding for cipher)

Upvotes: 6

Views: 5779

Answers (2)

Frugal Guy
Frugal Guy

Reputation: 81

I think it is worth emphasizing again what the accepted answer above mentioned in passing.

That is, it is unnecessary and unwarranted to make any attempt to hide the salt or the IV. The security of your cryptography is entirely dependent on the secrecy of the secret key, and that of the secret key alone. The IV and the salt can be handed out in clear text along with the ciphertext, and as long as the secret key remains a secret, the ciphertext remains secure.

It's important to understand and accept that, or you will wind yourself about an axle trying to obfuscate things that don't matter. There is no security in obscurity.

It is important to note, however, that the salt should be generated in a cryptographically strong pseudorandom number generator. A new salt should be generated for each new plain text that is being encrypted. Likewise, the IV should be randomly generated for each new ciphertext.

Those parameters need to be independent and unpredictable but need not be secret.

So you can store them in separate fields or delimit them in a single field, or use fixed lengths for the first two of three fields. For maximum flexibility and future proofing, though, I suggest delimited fields, and include all parameters needed to deal with the data. If you are using PBE, I would include the algorithm name and the iteration count, too, rather than rely on default values.

Upvotes: 6

Ebbe M. Pedersen
Ebbe M. Pedersen

Reputation: 7528

Base64 encodes in chunks of 3 bytes into 4 base64 chars. If the number of bytes that needs to be encoded ain't a multiplum of 3 the last block is padded with one or two =, to indicate that this block ain't full 3 bytes.

As neither the salt nor the IV needs to be kept secret, there really ain't any problem about being able to detect where they start or stop. The base64 padding char = ain't a problem - but you ought to have a way to separate the three encoded strings. You could e.g. simply seperate the parts with a :.

The size of the IV is the same as the block size of your encryption algorithm. In this case you use AES that have a block size of 128 bits, which is 16 bytes. This would give 32 bytes if hex encoded, or 24 bytes if base64 encoded. Salt don't really have a fixed length, and will depend on your implementation.

Upvotes: 2

Related Questions