EvilZone
Hacking and Security => Hacking and Security => : vezzy September 08, 2013, 04:03:31 AM
-
Source: http://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html (http://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html)
Speaking as someone who followed the IPSEC IETF standards committee
pretty closely, while leading a group that tried to implement it and
make so usable that it would be used by default throughout the
Internet, I noticed some things:
* NSA employees participted throughout, and occupied leadership roles
in the committee and among the editors of the documents
* Every once in a while, someone not an NSA employee, but who had
longstanding ties to NSA, would make a suggestion that reduced
privacy or security, but which seemed to make sense when viewed
by people who didn't know much about crypto. For example,
using the same IV (initialization vector) throughout a session,
rather than making a new one for each packet. Or, retaining a
way to for this encryption protocol to specify that no encryption
is to be applied.
* The resulting standard was incredibly complicated -- so complex
that every real cryptographer who tried to analyze it threw up
their hands and said, "We can't even begin to evaluate its
security unless you simplify it radically". See for example:
https://www.schneier.com/paper-ipsec.html
That simplification never happened.
The IPSEC standards also mandated support for the "null"
encryption option (plaintext hiding in supposedly-encrypted
packets), for 56-bit Single DES, and for the use of a 768-bit
Diffie-Hellman group, all of which are insecure and each of which
renders the protocol subject to downgrade attacks.
* The protocol had major deployment problems, largely resulting from
changing the maximum segment size that could be passed through an
IPSEC tunnel between end-nodes that did not know anything about
IPSEC. This made it unusable as a "drop-in" privacy improvement.
* Our team (FreeS/WAN) built the Linux implementation of IPSEC, but
at least while I was involved in it, the packet processing code
never became a default part of the Linux kernel, because of
bullheadedness in the maintainer who managed that part of the
kernel. Instead he built a half-baked implementation that never
worked. I have no idea whether that bullheadedness was natural,
or was enhanced or inspired by NSA or its stooges.
In other circumstances I also found situations where NSA employees
explicitly lied to standards committees, such as that for cellphone
encryption, telling them that if they merely debated an
actually-secure protocol, they would be violating the export control
laws unless they excluded all foreigners from the room (in an
international standards committee!). The resulting paralysis is how
we ended up with encryption designed by a clueless Motorola employee
-- and kept secret for years, again due to bad NSA export control
advice, in order to hide its obvious flaws -- that basically XOR'd
each voice packet with the same bit string! Their "encryption"
scheme for the control channel, CMEA, was almost as bad, being
breakable with 2^24 effort and small numbers of ciphertexts:
https://www.schneier.com/cmea-press.html
To this day, no mobile telephone standards committee has considered
or adopted any end-to-end (phone-to-phone) privacy protocols. This is
because the big companies involved, huge telcos, are all in bed with
NSA to make damn sure that working end-to-end encryption never becomes
the default on mobile phones.
John Gilmore
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
So it looks like the spooks are trying to directly tamper with the RFCs. Not surprising. However, this does offer evidence in favor of the existence of IPsec backdoors in OpenBSD, which was the subject of much controversy a while ago and something that I just recently mentioned in the closed 'BSD magazine' thread.
Sure as hell it's not just Linux.
-
I agree; there's likely far more affected than just Linux. However, I would be interested to see what it would take to create a viable implementation. I'll review the RFCs & other docs. It could be fun to put together a private implementation that was known not to be backdoored.
-
I agree; there's likely far more affected than just Linux. However, I would be interested to see what it would take to create a viable implementation. I'll review the RFCs & other docs. It could be fun to put together a private implementation that was known not to be backdoored.
It'd probably be a fair bit of work though, mainly because of kernel mode debugging which is never exactly fun (for me at least).
-
@bluechill; when has the amount of work involved ever affected how interested in a project we are? For that matter, when has that ever stopped either of us from some basic R&D?
-
This is extremely disturbing.
If even opensource software is backdoored I should get into gardening.
Im reading so much scary news lately, SSL defeated by gov clusters, this .. ouch.
Where the hell do we go.
-
@bluechill; when has the amount of work involved ever affected how interested in a project we are? For that matter, when has that ever stopped either of us from some basic R&D?
Exactly :) I also picked up a AI project once and learned for weeks until i got a piece of it. But i needed to learn it :D I am sure it wont last too long until there will be distro's with a revised everything.
-
This is extremely disturbing.
If even opensource software is backdoored I should get into gardening.
Im reading so much scary news lately, SSL defeated by gov clusters, this .. ouch.
Where the hell do we go.
Open source can get backdoored if it's subtle and takes time before the developers spot it, slowing down Linus' Law. No doubt it has happened, will continue to and is probably going on right now somewhere.
The real issue here is that the feds are systematically weakening the base standards, so even a proper implementation would be weak because the standard itself is weak.
I don't think they've technically defeated SSL, so much as they've taken over the certificate authorities and have access to the master keys. They could also feasibly implement attacks against HTTP compression as civilian researchers have done.
What they did do was feasibly break RC4, however I don't think that's surprising. RC4's pretty notorious for leading to insecure cryptosystems because of poor implementation and has had many proposed attacks. Bonus points if the key size is small.
Also, you really can't be certain. I take it you use Arch? Yeah, a binary distro. All your packages are delivered as precompiled binaries, so who knows how they were compiled? What's in them? What's in the compiler? Then we go down to hardware level. How do you know your CPU is doing only the instructions you want it to do? How are you sure the chipsets cannot be programmed to arbitrarily weaken their RNG, as has been implied?
Or it could be in the firmware. There's tons of ways to fuck you over. Most new PCs will be shipping with TPMs, so that's even worse.
-
Open source can get backdoored if it's subtle and takes time before the developers spot it, slowing down Linus' Law. No doubt it has happened, will continue to and is probably going on right now somewhere.
The real issue here is that the feds are systematically weakening the base standards, so even a proper implementation would be weak because the standard itself is weak.
I don't think they've technically defeated SSL, so much as they've taken over the certificate authorities and have access to the master keys. They could also feasibly implement attacks against HTTP compression as civilian researchers have done.
What they did do was feasibly break RC4, however I don't think that's surprising. RC4's pretty notorious for leading to insecure cryptosystems because of poor implementation and has had many proposed attacks. Bonus points if the key size is small.
Also, you really can't be certain. I take it you use Arch? Yeah, a binary distro. All your packages are delivered as precompiled binaries, so who knows how they were compiled? What's in them? What's in the compiler? Then we go down to hardware level. How do you know your CPU is doing only the instructions you want it to do? How are you sure the chipsets cannot be programmed to arbitrarily weaken their RNG, as has been implied?
Or it could be in the firmware. There's tons of ways to fuck you over. Most new PCs will be shipping with TPMs, so that's even worse.
Your right, it basically comes down to trust, trust being the only thing that matters.
But how is g0vs became the enemy?
What fucking planet do we live on.
If any practises we discussed here would be done by a civillian you would go away for life.
...reader thinks ; thats not argument...
Yes it fucking is, our privacy is being skullraped on a massive scale and they get away with it.
About the binary packages , your right , might not be as bad as some prop software but still.
Firmware, yep there have been scary speculations on backdoored firmware etc :S
Wtf are we gonna do?
Built a machine yourself and code everything :P
And yes I get fuzzy when I think about this stuff.
Scares the living hell out of me.
-
Just like this. (http://homebrewcpu.com)