[Cryptography] What faults would you inject to test crypto mechanisms/protocols?

[Dmitry Belyavsky]

Hello Peter,


On Tue, May 13, 2014 at 9:03 AM, Peter Gutmann <pgut001 at cs.auckland.ac.nz>wrote:

> As a number of recent research papers (and published vulnerabilties) have
> highlighted, quite a lot of implementations of security protocols and
> mechanisms don't really detect problems with everything from invalid
> signatures through to the crypto verifying but whatever it is that's
> verified
> being for the wrong web site.
>
> One way of checking that your implementation doesn't have (some of) these
> problems is through testing via fault injection, creating some failure like
> the presence of corrupted data leading to an invalid signature and then
> making
> sure that it's detected.  Problem is, what sort of faults do you inject?
>  The
> reductio ad absurdum approach is that you need to test every bit of every
> byte
> of any protocol, but what we're looking for here is high-level
> implementation
> flaws in which crypto mechanisms aren't applied properly (and we're
> assuming
> that something like a MAC failure will occur whether we corrupt bit 1 of
> byte
> 1 or bit 8 of byte n).  So, what sort of faults need to be injected to test
> for typical flaws?  What I've been using is:
>
>   SSH and SSL/TLS:
>
>     Wrong certificate/key
>     Handshake message corruption
>     Payload data corruption
>     Bad signature - wrong hash value
>     Bad signature - data corrupted
>
>   S/MIME and PGP:
>
>     Wrong certificate/key
>     Bad signature - wrong hash value
>     Bad signature - data corrupted
>     Bad signature - signed attributes corrupted
>
> Can anyone think of anything else that needs to be checked?  I'm looking
> for
> faults that check for specific failures, not something like "check every
> X.509
> extension in every certificate in an SSL server's cert chain".
>
>
> What check is to catch the Apple "gotofail" bug?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140513/921d7e5e/attachment.html>