In the previous post of the series, I made an introduction on why it is important for programmers to have a basic knowledge of cryptography, and I ...
For further actions, you may consider blocking this person and/or reporting abuse
This series of posts is incredibly helpful. Thank you for creating it! :-D
Just one note: nowadays, XChaCha20 is getting more and more popular and is usually recommended over AES. Also, since libsodium uses it as the default for secretbox, it's a no-brainer to use it. :-D
In CBC mode, IV must be random but does not have to be unique. In case PRNG generates the same IV twice, it's fine.
In CTR or GCM mode, IV must be unique but does not have to be random. I designed a protocol that uses random IV with GCM mode, and the NIST cryptographer rejected that design upon review because there's a small risk of IV collision.
The application/protocol must guarantee that IVs for the same key never repeat.
One method is to split the IV into three portions:
Hi Junxiao, thanks for the reply. I wanted to give general rules for all iv generation to not go into too much detail, and I felt generating random ivs is ok in most cases.
About CBC, I don't agree that ivs don't have to be unique. It is not as important that they are unique than with stream modes, but reusing ivs in CBC can leak information about the first block / repeated prepends in messages. For CBC the very small probability of a PRNG collision is acceptable, but that does not mean that it would be ok to use a static iv, or to reuse the same iv intentionally.
I can see why that probability is not so acceptable in stream modes. Still we should be aware that there is a very very small chance of that happening. I find your solution to guaranteeing uniqueness very interesting, thanks. I will take this into account when I explain GCM.
Is the CBC part (the splitting into blocks) done by the crypto library behind the scenes? Shouldn't it be asynchronous, or is it assumed that the amount of data encrypted will always be relatively small?
Yes the library handles the blocks and padding. You could make it asyncronous depending of your use case. However if you are encrypting large amounts of data, then maybe CBC is not the best mode since it can not be parallelized.
Kudos Sergi! Really nicely written, easy to understand even for developers with not a deep knowledge in cryptography 👏👏
Part 3 now published! I took a while because I was busy and it was hard to summarize, I hope you like the new episode too 😊
Oh thanks Sergi, I had been checking every few days so as to not miss it; I am sure I will like it!
@shierve Wow! Thank you for this excellent series!
Thank you John. I published part 3 today I hope you like it as well 😄
You have indeed done a good job :-)
Thanks! I have finally published part 3 after a while working on it. Check it out!
nice work
Thanks Carlos! I have published part 3 talking about authentication topics. Check it out!
Nice Work, looking forward for the next part
Thank you Luiz. I took a while but part 3 is finally out, I hope you like it! 😄