Monday, November 9, 2009

WEP Weakness Explained

HS^^: "Because RC4 is a stream cipher, the same traffic key must never be used twice. The purpose of an IV, which is transmitted as plain text, is to prevent any repetition, but a 24-bit IV is not long enough to ensure this on a busy network. The way the IV was used also opened WEP to a related key attack. For a 24-bit IV, there is a 50% probability the same IV will repeat after 5000 packets."
HS^^: so what happens if the IV is the same
HS^^: and the traffic key is the same...
HS^^: then you have 2 exactly the same packets, what does it matter
crunge: HS^^: Do you understand what stream ciphers do?
HS^^: crunge they encode per bit.. thats what i just read
crunge: HS^^: specifically they spit out a keystream that is XORed with the plaintext
crunge: HS^^: A given key will always spit out the same keystream. In WEP the IV is used as part of key. For 64 bit you have 40 bits of key and 24 bits of IV
crunge: HS^^: So when an eavesdropper sees two packets encrypted with the same key and IV he can XOR those packets together and recover the keystream for that key+IV. He can XOR that against the original packets and any other packets with that key+IV to decrpt them
crunge: HS^^: He can now also encrypt arbitrary packets using that keystream
crunge: HS^^: He can then use *that* technique to throw out broadcast messages using his known keystream to cause other hosts to send replies with previously unseen IVs which he collects. Thus he builds up his database of IV -> keystream mappings
crunge: HS^^: This database I believe is then used in a known plaintext attack to recover the key
ToXBoT: crunge, how the eavesdropper can manage to conclude that the two packets are encrypted with the same key+IV?
crunge: ToXBoT: the IV must be included in the packet in the clear. Otherwise no host would know the IV and therefore no one would be able to decrypt it.


Addendum: The above is slightly incorrect. XORing the two ciphertexts together produces the XOR of the two plaintexts. This should be fairly easy to crack. Once one of the plaintexts is recovered the attacker can recover the keystream.

Friday, November 6, 2009

I understand your reasons for making your choices, but try and understand mine before you discount them; I don’t vote for anybody who abuses my rights, like I wouldn’t put up with someone who would demand to kick me in the nuts before I could walk into my own house. I don’t vote for whoever might give my cojones the weakest kick- I vote for someone who isn’t going to kick me there. When more people do that, we will all see better presidents and senators. Until enough people do that, all we will see is more nut-kicking, and being handed an ice pack by the winner doesn’t make it any better.

"I understand your reasons for making your choices, but try and understand mine before you discount them; I don’t vote for anybody who abuses my rights, like I wouldn’t put up with someone who would demand to kick me in the nuts before I could walk into my own house. I don’t vote for whoever might give my cojones the weakest kick- I vote for someone who isn’t going to kick me there. When more people do that, we will all see better presidents and senators. Until enough people do that, all we will see is more nut-kicking, and being handed an ice pack by the winner doesn’t make it any better."
-- Bill Albertson in a comment on BoingBoing about the ACTA (via brettflorio)

ACTA: Are you guys done yet?

ACTA: Are you guys done yet?


Here we have a set of rules that are basically unenforceable.



“That ISPs have to proactively police copyright on user-contributed material.”



If you’re a connectivity provider you can’t effectively monitor all the traffic going through your network and still provide high quality service. The ISPs that have the most effective monitoring will provide the poorest service and lose customers to those ISPs that have less effective monitoring.



If you’re a hosting company it’s a similar problem. The servers on that network have an enormous amount of deep content that can’t easily be discovered through probing and can’t be discovered when going over an encrypted channel. Hosting companies charge for bandwidth. Are they going to charge their customers for bandwidth used while the hosting company is looking for copyrighted material?



“That ISPs have to cut off the Internet access of accused copyright infringers or face liability.”



And that will stop them from going to another ISP? Preferably one that doesn’t shut of their own customers (and lose business) so readily?



“Mandatory prohibitions on breaking DRM, even if doing so for a lawful purpose (e.g., to make a work available to disabled people; for archival preservation; because you own the copyrighted work that is locked up with DRM)”



Because it’s worked so well thus far.



Stuff like this is great. It wastes taxpayer time and dollars. The product serves to put pressure on the filesharers and make them better at what they do. I’d like to see some kind of evidence that DMCA has reduced copyright violation. I’m willing to bet that it’s gone up since DMCA was created.



If this goes through and we see that it does nothing to stop “the problem” can we finally agree that we as a society don’t have time for bullshit like this?

Tuesday, November 3, 2009

Can't Connect to Cyrus Sieve

So I’m trying to use sieveshell on a cyrus imap server. It just tells me it can’t connect. The logs are very not helpful:




Nov 3 19:39:50 li9-96 cyrus/master[2167]: about to exec /usr/lib/cyrus/bin/timsieved
Nov 3 19:39:50 li9-96 cyrus/sieve[2167]: executed
Nov 3 19:39:50 li9-96 cyrus/sieve[2167]: accepted connection
Nov 3 19:39:54 li9-96 cyrus/master[2160]: process 2167 exited, status 0


I try to telnet and it works:




jason@renfield:/etc$ nc localhost 2000
"IMPLEMENTATION" "Cyrus timsieved v2.2.13-Debian-2.2.13-14+lenny3"
"SIEVE" "fileinto reject envelope vacation imapflags notify subaddress relational comparator-i;ascii-numeric regex"
"STARTTLS"
OK
LOGOUT
OK "Logout Complete"


A lot of looking and I find this: http://linux.derkeiler.com/Mailing-Lists/Debian/2004-02/3871.html but I’m already set to PLAIN. In fact my configs, versions, and OS are exactly the same on this system as on another system where sieve is working fine.



Eventually I notice this connecting to my working box:




jason@hatchery:/etc$ nc localhost 2000
"IMPLEMENTATION" "Cyrus timsieved v2.2.13-Debian-2.2.13-14+lenny3"
"SASL" "NTLM LOGIN PLAIN DIGEST-MD5 CRAM-MD5"
"SIEVE" "fileinto reject envelope vacation imapflags notify subaddress relational comparator-i;ascii-numeric regex"
"STARTTLS"
OK
LOGOUT
OK "Logout Complete"


There’s an extra line in there, beginning with “SASL”. The other guy had a SASL problem. I had already check to make sure I have the same cyrus packages but I didn’t check sasl packages. I finally find that I’m missing libsasl2-modules. Install that, restart cyrus and saslauthd (probably didn’t need to restart both), and everything works.



It would have been nice if sieveshell said, “I can’t connect because there’s no SASL mechanisms”.