Re: Requesting comments: SRP based IRC encryption

And above all, what problem do we really solve here? An attacker
doesn't know the session key, so he can't inject his own messages.
What he can do is take an old message from Alice and send it again,
or take Alice message and say it origninated from Bob.

I'll have one last stab at convincing you. Your fault is right there
in front of you. Not knowing the key *does not* prevent changing the
messages!

The easiest way to see this is to look at AES in CTR. In CTR mode, AES
is a stream cipher. Let's say I'm writing some code that tells the
cash point that the transaction is authorised. I decide to use AES in
CTR mode and I encrypt a single bit that tells the cash point whether
to give out money: 1 for yes, 0 for no.

Is this secure? Of course not! I can use my card and enter the wrong
pin. I know that the answer back is going to be a zero, so I flip the
bit. Bingo! The machine gives me free money.

What went wrong here? CTR is provably secure, how could it fail this
badly? Well CTR is proven to protect the secrecy of the message - not
the authenticity. CBC mode has a similiar proof.

Let's say I've put a patch in to the IRC server so that I can muck
about with your messages. Let's say I change one of your blocks from x
to y.

What happens? Well, most of the time everything after this block is
garbage. The question is, how does your software *know* that this has
happened? How can you be sure that under a chosen plain-text attack,
the result will always be nonsense?

Consider a final scenario: You're using your protocol on an IRC base
file sharing network. Somebody on this network knows that you're about
to transfer a copy of [your favourite game]. What's to stop them
corrupting the stream in such a way that they know will predictably
remove a length check on a string, effectively injecting an exploit in
transit?

Unlikely perhaps, but I always assume an attacker is smarter and has
significantly more resources than me. The difference between unlikely
attack and a plausible one is often only intellect and time.

This is why all cryptographers demand that their messages have secrecy
protection, in the form of AES, and authenticity protection in the
form of a MAC: either through an encrypt/authenticate mode or through
something like HMAC.

Simon.



.

Relevant Pages

  • Re: Triple-AES, NIST and RNGs
    ... usefulness if future weaknesses are seen in AES. ... >> CTR is faster and easier to implement. ... An example of such a generator ... This cipher does have one distinguishing characteristic. ...
    (sci.crypt)
  • Re: Symmetric encryption scheme
    ... Are they (Pohlig-Hellman, CTR, OFB) are symmetric encryption schemes? ... If you don't know what PH, CTR and OFB modes are you really need to put ... They're covered in essentially all entry level crypto ... Are they as fast as AES? ...
    (sci.crypt)
  • Re: Triple-AES, NIST and RNGs
    ... but the mode breaks down to ... It does include a spec for AES ... CTR is faster and easier to implement. ... RND need not be cryptographically secure. ...
    (sci.crypt)
  • Re: strengthening /dev/urandom
    ... to be a subjective and not objective matter. ... AES in CTR is secure enough, ...
    (sci.crypt)
  • Re: Data Compression Before or After Encryption ?
    ... > In the case of, for instance, illegal music downloads, all an attacker has ... So far the only other mode that people have suggested;) is CTR mode. ... reversing an empty KEY with xor DATA. ...
    (sci.crypt)
Quantcast