1
$\begingroup$

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 :)

Improve this question
$\endgroup$
8
  • 7
    $\begingroup$ Analysis of randomness cannot prove correctness of the implementation. $\endgroup$
    – kodlu
    Dec 26, 2019 at 22:51
  • 2
    $\begingroup$ Side channel analysis - measuring timing of operations. If you want more than passing narrow and specific tests, though, you need formal verification methods. $\endgroup$
    – Natanael
    Dec 27, 2019 at 11:14
  • $\begingroup$ 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). $\endgroup$
    – Maarten Bodewes ♦
    Dec 28, 2019 at 19:52
  • 1
    $\begingroup$ 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. $\endgroup$
    – Ella Rose
    Dec 29, 2019 at 13:59
  • $\begingroup$ @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 :) $\endgroup$
    – CoffeDev
    Dec 29, 2019 at 20:03

1 Answer 1

Reset to default
3
$\begingroup$

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
Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.