replay & integrity

Anton Stiglic astiglic at
Wed Jul 9 13:57:36 EDT 2003

> Integrity:  Financial protocols that use crypto
> (as opposed to ones abused by crypto) generally
> include signed messages.  The signature provides
> for its own integrity, as well as a few other
> things.

I don't believe that is enough.  Take for example
the SSL 2.0 ciphersuite rollback vulnerability or the 
SSL 3.0 key-exchange algorithm vulnerability . Any kind
of rollback attack is serious, and won't be protected
by signatures in the bulk data (and those signature might
be weakened by forcing a rollback to a possible weaker

> Replay:  One of the commonest problems in HTTPS
> sites is replay failure.  The solution is well
> known out in the real world - you have to have
> replay prevention at the higher layers.
> (Credit card processors have replay prevention
> too!)
> So, some protocols don't need replay prevention
> from lower layers because they have sufficient
> checks built in.  This would apply to any protocols
> that have financial significance;  in general, no
> protocol should be without its own unique Ids.

So maybe I can't replay a complete financial transaction, 
because at some high layer there is replay prevention,
what about replaying some init protocol request?
Is that not annoying?  Would a bank not care that 
their ATMs are not working for a day because someone
is executing a DoS attack on the lower layers of the 
protocols of their system? I think not, you need replay 
protection on both levels. 

How can a secure socket be dubbed secure if it doesn't
protect against these basic attacks?

To quote from Wagner and Schneier`s paper, Analysis
of the SSL 3.0 protocol:

"Replay attacks are a legitimate concern, and as they are
so easy to protect against, it would be irresponsible to fail
to address these threats."


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list