nav search
Data Center Software Security Transformation DevOps Business Personal Tech Science Emergent Tech Bootnotes BOFH

back to article
'Bar Mitzvah attack' should see off ancient and crocked RC4 algo

Anonymous Coward

Not a bug...

...just another undocumented feature. Just ask the designer.

Tickled me that they're now enforcing SSL for connections to their website. I bet that raises a few smirks there too. ;)

What I can't help wondering is... are we all expected to go on pretending that, just because they haven't been publicly unpicked yet, all the other, more recent NSA NIST recommendations are secure? Shirley not!([1],[2],etc...) Yet there would appear to be something of a PR campaign going on to achieve that! How quaint.

[1] https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html

[2] http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html?pagewanted=all&_r=1

0
2
Silver badge

What's in a name?

The article fails to mention how the attack came to be dubbed the Bar Mitzvah attack, but the linked Dark Reading article does: It's because the vulnerability is 13 years old; I don't know (and can't be arsed to look up) the meaning of the term, but I know it's a Jewish term relating to boys once they are 13 - so there's the basic reason for the name.

However, as names for such things go, it's a bit crap, really.

POODLE - sounds fluffy and cute, but it's all in caps* so it must be REALLY BAD.

BEAST - not only is it all in caps* and therefore REALLY BAD, it's a word that itself is meant to be scary.

CRIME - again, all in caps*, so REALLY BAD, and a word with negative connotations.

Then there's the Bar Mitzvah attack.

Nah. Not good enough. Alternative suggestions:

UNLUCKY 13

TEEN TERROR

* Granted, the real reason for the caps is that they're acronyms. Just pretend not to realise that...

2
0

Re: What's in a name?

Ah, but it's reminiscent of the well-known Birthday Paradox and related Birthday Attack against secure hashes. I'd rate it Pretty Good on the TLS Attack Name scale.

By the way, you left out the Be'ery and Shulman TIME attack.

0
0
Anonymous Coward

Bar Mitzvah attack?

Oy vey!

3
0
Silver badge

Very interesting

I know and like RC4 and while I was aware of the weak-keying issue, that can be mitigated when choosing the initialization vector (or if using the algorithm as a proper stream cipher, rather than a block cipher as it was in WEP).

The "L shaped pattern" described in the PDF is a new one on me, even though it was apparently described in the same paper 13 years ago. Not sure it's a home run however, it still relies on a (larger) class of weak key, and (if I've read that paper right) the best case is those are only 1 in 2^16 of sessions. So an individual RC4 encryption is likely still fine, it's only when there are millions of them that one becomes statistically likely to fail. The odds of that one having a password, credit card or whatever are still low.

So I'm not going to panic just yet.

0
0

Re: Very interesting

So an individual RC4 encryption is likely still fine, it's only when there are millions of them that one becomes statistically likely to fail. The odds of that one having a password, credit card or whatever are still low.

Agreed, but - as always - the threat has to be evaluated against a threat model. The paper specifically suggests using the vulnerability for session hijacking, for example. If the attacker is in a position to passively sniff a lot of RC4-encrypted sessions against a busy site, and make use of hijacked sessions, and automate the whole thing (obviously), it could be a credible threat.

It also notes that accounts with commonly-used passwords could be particularly vulnerable because a password table grouped by LSB greatly decreases the number of passwords that have to be attempted. So attacker sniffs a lot of traffic, detects weak keys (the paper notes how this can be done with good probability), and then later does active attacks using passwords from the appropriate subset. That requires a fair bit of additional exposure to work: the attacker needs other information (eg account name) and the attacked system needs a sufficiently liberal password-attempt policy. But it's not outside what's believable.

I've suggested before on Reg forums that the "RC4 must die now!" argument is a little too broad; that lots of traffic isn't valuable enough for anyone to bother attacking it, that probability of success is still low, that RC4 has other applications that it's still suitable for. But clearly the recommendation to use AES-GCM for session encryption (and one of the PFS EC key-exchange ciphers) is the more cautious position.

0
0

Cost-effective?

Why does everyone assume that hackers will patiently sift through millions of conversations in the hope of decrypting a password? Especially, as the one they succeed in decoding might be that of a guy with $20 in his account.

Doesn't sound cost-effective to me.

0
0

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

The Register - Independent news and views for the tech community. Part of Situation Publishing