# What are easy yet fool proof ways of ensuring that AES encryption algorithm works like it should and no bugs/developer mistakes have sneaked in?

As a developer when it comes to encryption, there is an insane amount of weakness/mistakes/bugs that the programmer can add to the encryption algorithm.

So a pretty general question to the crypto pro’s, do you guys have maybe a checklist/test cases that you go through after implementing AES-Rijndael-CBC into any application/program to make sure that it works correctly.

The reason for this is when I use any kind of programming language such as python, me and probably most others simply use a prebuilt library for encryptions such as AES CBC and trust that it will simply work correct and be safe. But in reality, I have no idea since it’s just scrambled data in the output...

Is there maybe a trusted online tool or analyzing technique or something similar that we can compare the results to indeed see that our encryption works as good as excepted. For example, I made IV to all zeros and used an online aes program and the ciphertext was indeed the same so that made me certain that my program was working correctly. But this is the most simple test of string -> cipher... when we add more functionality to the program such as derived keys and etc, it gets harder and harder to find bugs that we may have accidentally put into the program.

Can we maybe analyze the randomness of bytes in the ciphered text to determine if the entropy is high and random etc... to make sure that our encryption still works as it should?

Thanks beforehand for any tips :)

• Analysis of randomness cannot prove correctness of the implementation. – kodlu Dec 26 '19 at 22:51
• Side channel analysis - measuring timing of operations. If you want more than passing narrow and specific tests, though, you need formal verification methods. – Natanael Dec 27 '19 at 11:14
• Such as FIPS and Common Criteria. But those are mainly for organizations rather than individuals (although there are plenty of individuals that could pay for them out of their back pocket in this idiotic world). – Maarten Bodewes Dec 28 '19 at 19:52
• Note that a passing unit test does not guarantee with certainty the correctness of the implementation. This underhanded crypto contest entry demonstrates that pretty well; it is possible that your implementation just so happens to work out for the number of blocks that was tested, but fails for longer sequences of blocks in general. – Ella Rose Dec 29 '19 at 13:59
• @kelalaka I have studied in test vectors, and indeed it's a very straightforward and good way of testing encryption! I would have pick your comment as the answer if it was placed as an answer :) – CoffeDev Dec 29 '19 at 20:03

For this kind of problem, the cryptographic algorithm/protocol designers, usually, presents test vectors for their designs. You can find some of them in books, too.

In your case, AES is standardized by NIST on May 26, 2002, and they provide test vectors in Appendix F of NIST 800-38A for various mode of encryption.

Before the standardization on November 26, 2001, the NIST FIPS 197 document provided
example vectors in Appendix C. This is a more detailed vector for each round instead of just input and output.

input: cipher input
start: state at start of round[r]
s_box: state after SubBytes()
s_row: state after ShiftRows()
m_col: state after MixColumns()
k_sch: key schedule value for round[r]
output: cipher output