If I validate my implementation(s) of Rijndael against the Advanced Encryption Standard Algorithm Validation System (AESAVS) specified validation testing requirements is it fit for purpose and real world use cases? Can I then state as much? What about other ciphers and their test vectors that lack NIST authority?

  • $\begingroup$ Beyond demonstrating your implementation gets the right answers for some inputs (as with AESAVS) you can prove it is functionally correct against a target specification or reference implementation. For an example, see my "ugly-old-aes-verification". As others have said, functional correctness does not mean secure, so this only gives you more confidence in the one aspect in which you have already worked to gain confidence. $\endgroup$ Nov 15 '17 at 21:33

Based on my reading of that document, it looks like it only covers Rijndael (aka "AES"). Moreover, I would say that the AESAVS test the correctness of your implementation, but not the security.

From the linked document:

1 Introduction

This document specifies the procedures involved in validating implementations of the Advanced Encryption Standard (AES) algorithm in FIPS 197 : Advanced Encryption Standard 1. ... This publication ... includes the specifications for the three categories of tests that make up the AESAVS, i.e., the Known Answer Test (KAT), the Multi-block Message Test (MMT), and the Monte Carlo Test (MCT).

So these tests will show that your implementation produces the correct output for a given input. They do not make any claim about whether your implementation is robust to timing attacks, or power analysis attacks, or really, any kind of attack.

So, as to

is it fit for purpose and real world use cases?

That depends, does your purpose include being secure (in addition to being correct)?

  • 1
    $\begingroup$ Rijndael implementations that support other block / key sizes than AES are out of scope for that document. $\endgroup$
    – Maarten Bodewes
    Nov 15 '17 at 16:00
  • $\begingroup$ @Mike Ounsworth So I can establish correctness within the confines of those vectors, that's a start, and can then state as much but what options do I have open to me wrp security? Maybe I can spin up some background threads to make noise but I can't prove resistance to power analysis and I've read here about random thread sleeps etc but even to the point of reductio ad absurdum I can't secure against rubber-hose. So what realistically can I do beyond testing against the cipher appropriate vectors (sorry about incorrectly generalising AESAVS) $\endgroup$
    – headwedge
    Nov 15 '17 at 17:10
  • $\begingroup$ @headwedge: exactly what is required to be secure in your use case might depend somewhat on what your use case actually is... An AES implementation in a file encryptor has different requirements than, say, one on a smart card... $\endgroup$
    – poncho
    Nov 15 '17 at 17:35
  • 2
    $\begingroup$ @headwedge There's no formula for hardening a crypto implementation. It generally involves following the attacks published against other implementations, and asking "is my implementation also vulnerable to that attack?". As poncho says, while correctness is binary, security is a spectrum: how much hardening you need to do depends on your use case and your threat model. $\endgroup$ Nov 15 '17 at 18:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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