|
Well, this explains why the NSA recommended ECDH: https://freedom-to-tinker.com/blog/haldermanheninger/how-is-nsa-breaking-so-much-crypto/  420 break DH errday
|
#
?
Oct 15, 2015 14:40
|
|
|
|
| # ? May 17, 2024 08:40 |
|
|
I am not a book posted:Well, this explains why the NSA recommended ECDH: Is this different from the Logjam news from a few months ago? EDIT - I guess it's the same root story, but the new news is a cost analysis revealing exploitation of 1024 bit DH primes to be within the means of a well-funded actor Jesse Iceberg fucked around with this message at 22:48 on Oct 15, 2015 |
|
#
?
Oct 15, 2015 21:54
|
|
|
Jesse Iceberg posted:Is this different from the Logjam news from a few months ago? Yes. LogJam was a way to trick the server into using a weaker version of TLS. This new attack allows them to decrypt any communications using primes they have "cracked". The former is a MITM attack, that can probably be detected and can be easily turned off. The latter allows them to passively scoop up data and decrypt it. They don't even need to have the prime cracked at the time they collect the data. They could start collecting the data then come back once they identify and crack the primes used by the site. If this is true, and they started this several years ago, they have effectively defeated encryption for a huge swath of the internet. quote:Would this be worth it for an intelligence agency? Since a handful of primes are so widely reused, the payoff, in terms of connections they could decrypt, would be enormous. Breaking a single, common 1024-bit prime would allow NSA to passively decrypt connections to two-thirds of VPNs and a quarter of all SSH servers globally. Breaking a second 1024-bit prime would allow passive eavesdropping on connections to nearly 20% of the top million HTTPS websites. In other words, a one-time investment in massive computation would make it possible to eavesdrop on trillions of encrypted connections. EDIT: Yeah, it defeats DH in the same way but they no longer need to MITM to downgrade the crypto. The solution to logjam was to disable 512bit crypto. This doesn't appear to have an easy solution. size1one fucked around with this message at 22:59 on Oct 15, 2015 |
|
#
?
Oct 15, 2015 22:54
|
|
|
size1one posted:EDIT: Yeah, it defeats DH in the same way but they no longer need to MITM to downgrade the crypto. The solution to logjam was to disable 512bit crypto. This doesn't appear to have an easy solution. The paper says that 2048bit should be out of reach for the NSA for now (or moving to elliptic curves sidesteps the issue).
|
|
#
?
Oct 15, 2015 23:11
|
|
|
Heavy_D posted:The paper says that 2048bit should be out of reach for the NSA for now (or moving to elliptic curves sidesteps the issue). There are huge piles of legacy equipment that will never support 2048bit keys due to java being a piece of poo poo.
|
|
#
?
Oct 16, 2015 03:54
|
|
|
So basically they found a way to rainbow-table D-H?  karthun posted:There are huge piles of legacy equipment that will never support 2048bit keys due to java being a piece of poo poo. Well, now we have to do the fix anyway. If the NSA wasn't doing it before, they will be now.  For that matter so will everyone else. If Bitcoin has taught us anything, it's that custom hardware is now easily within the reach of everyone and their dog. Paul MaudDib fucked around with this message at 19:28 on Oct 16, 2015 |
|
#
?
Oct 16, 2015 19:21
|
|
|
Paul MaudDib posted:So basically they found a way to rainbow-table D-H? Sounds more like a rainbow nightstand given that factoring one prime breaks 50% of VPN traffic.
|
|
#
?
Oct 16, 2015 20:51
|
|
|
Maybe the takeaway from this will be that shared secrets on millions of devices should be avoided, even if the underlying method seems sound at the time. What was the rationale for shared DH primes at the time? That it wasn't cost effective to compute unique ones given available hardware?
|
|
#
?
Oct 16, 2015 21:24
|
|
|
Jesse Iceberg posted:Maybe the takeaway from this will be that shared secrets on millions of devices should be avoided, even if the underlying method seems sound at the time. What was the rationale for shared DH primes at the time? That it wasn't cost effective to compute unique ones given available hardware? Correct, it's computationally difficult to find large primes (a desirable aspect of this system). Also apparently not all large primes are suitable for this, so the intention was to keep people from choosing weak values. There's still a few dozen known-good values available, but most of the users are clustered on a few standard values. Also "factor a prime" is a bit of a misnomer since that's a trivial problem - a prime only has itself and 1 as factors. The idea of D-D is you take a large prime and put it to the power of your secret and then do a mod or something. What they're actually doing is creating a rainbow table of discrete log values that let them look up the secret based on the output for a given prime (is my understanding)
|
|
#
?
Oct 16, 2015 21:49
|
|
|
Also apparently Cisco has hosed it up even harder - a bunch of their stuff is only running on 768-bit keys.
|
|
#
?
Oct 16, 2015 21:50
|
|
|
Paul MaudDib posted:Also apparently Cisco has hosed it up even harder - a bunch of their stuff is only running on 768-bit keys. How the poo poo does someone even choose that number? It's not a power of 2.
|
|
#
?
Oct 16, 2015 22:10
|
|
|
So if someone wanted to understand better these encryption standards and how they work/don't, how would one do this? Asking for a friend. The friend being me.
|
|
#
?
Oct 16, 2015 23:09
|
|
|
IUG posted:So if someone wanted to understand better these encryption standards and how they work/don't, how would one do this? Asking for a friend. The friend being me. Number Theory and a few crypto books. Crypto really isn't that easy to explain and can be kind of counter-intuitive. What's currently being discussed is the Diffie-Hellman key exchange. Basically D-H is an asymmetric way to securely transmit critical information. It exploits an architectural weakness that computers have with processing discrete factorization and logarithms. D-H starts off with the parties (Alice and Bob per the common Crypto naming standards) agreeing to 2 prime numbers, p and g. (there are specific conditions that need to be met for p and g, but we'll leave that for a later discussion) Alice chooses her secret key and represents it as an integer. Alice sends a message consisting of A = g^a % p. (% is modulo, which can basically be thought of as the remainder. eg 5 % 2 = 1) Bob receives the message and then as a reply sends B = g^b % p. Alice and Bob can then decrypt the messages by taking log base g(A^b) or (B^a), and come up with a common secret S. S is then used as a key to further communications - this entire processes is extremely computationally expensive to brute force. You would then use the key in something like AES, which isn't as strong, but a much more faster and inexpensive symmetric encryption algorithm. This is a very secure process as long as good values for p and g are chosen, and they are updated. In the case of what's happening right now, while g & p have restrictions, institutions are limiting their set of them. So instead of D-H being really secure, an implementation flaw has allowed for an efficient brute force attack - the potential death knell for a crypto algorithm.
|
|
#
?
Oct 16, 2015 23:56
|
|
|
IUG posted:So if someone wanted to understand better these encryption standards and how they work/don't, how would one do this? Asking for a friend. The friend being me. There's a free crypto class offered by Stanford you can take online. It's a better intro than you'll find in any book and will help provide you the foundation for whatever you decide to pick up after. I think you can find the class on coursera.
|
|
#
?
Oct 18, 2015 16:13
|
|
|
Paul MaudDib posted:Also apparently Cisco has hosed it up even harder - a bunch of their stuff is only running on 768-bit keys. I'm not a cryptographer, but I am a network engineer. What Cisco product or technology are you referring to here?
|
|
#
?
Oct 18, 2015 18:27
|
|
|
inignot posted:I'm not a cryptographer, but I am a network engineer. What Cisco product or technology are you referring to here? Middleware, like VPNs and Citrix-style shells and what have you. Some of it supports stronger key exchange, but others don't. And as a result of that legacy support, 768-bit is the default. Apparently 768-bit is weak enough that the authors describe it as being in the reach of "academic researchers" (probably meaning anyone who can put together a little cluster). Paul MaudDib fucked around with this message at 22:26 on Oct 21, 2015 |
|
#
?
Oct 21, 2015 22:20
|
|
|
The Feds argue that those EULAs you sign give it free reign to force those companies to work with it to undermine your security after the fact.
|
|
#
?
Oct 23, 2015 21:19
|
|
|
ComradeCosmobot posted:The Feds argue that those EULAs you sign give it free reign to force those companies to work with it to undermine your security after the fact. They're really, really mad at Apple, aren't they? Their barely withheld fury that someone isn't doing exactly what they want when they want is...a little freaky, honestly.
|
|
#
?
Oct 23, 2015 21:22
|
|
|
Paul MaudDib posted:Middleware, like VPNs and Citrix-style shells and what have you. Some of it supports stronger key exchange, but others don't. And as a result of that legacy support, 768-bit is the default. I've done a bunch of IPSec VPNs with Cisco routers. The two IPSec related things that could involved RSA keys would be using RSA keypairs for authentication, and the Diffie-Hellman group used for phase 1 key exchange (and I guess DH group for PFS also). Both of those require user intervention to configure, there's no 768 bit default that I know of. SSHv2 in IOS won't accept an RSA keysize smaller then 1024 for incoming connections. Actually IOS 15.2 introduced a bunch of new stuff: EC keys for SSH; a bunch of EC DH groups; AES-GCM; SHA2-256/384/512. Cisco has a huge product line, while it's possible something uses 768 bit RSA keys by default, I don't think it's IPSec on IOS.
|
|
#
?
Oct 24, 2015 00:17
|
|
|
Sorry Wikimedia! You might have been called out explicitly as a target for NSA spying but you just aren't big enough to have standing.
|
|
#
?
Oct 24, 2015 00:22
|
|
|
ComradeCosmobot posted:Sorry Wikimedia! You might have been called out explicitly as a target for NSA spying but you just aren't big enough to have standing. That's a stupidly misleading description of the judgment in that case. (Not attacking you, just Ars Technica, by the way.) The judgment says that the plaintiffs' allegations are based on conjecture about how much Upstream surveillance architecture there is, about how much it is used, and about how much of their own traffic is affected. Even if Wikimedia were even bigger than they are, they could still only conjecture, and Clapper has established that conjecture is not enough to establish standing. The relevant bits are on pages 24 and following in the judgment, by the way, in case anybody wants to read this stuff.
|
|
#
?
Oct 24, 2015 14:02
|
|
|
botany posted:That's a stupidly misleading description of the judgment in that case. (Not attacking you, just Ars Technica, by the way.) The judgment says that the plaintiffs' allegations are based on conjecture about how much Upstream surveillance architecture there is, about how much it is used, and about how much of their own traffic is affected. Even if Wikimedia were even bigger than they are, they could still only conjecture, and Clapper has established that conjecture is not enough to establish standing. The relevant bits are on pages 24 and following in the judgment, by the way, in case anybody wants to read this stuff. It continues to be a hell of a catch-22 though that covert lawbreaking can be legally unassailable by being sufficiently covert.
|
|
#
?
Oct 24, 2015 14:49
|
|
|
eSports Chaebol posted:It continues to be a hell of a catch-22 though that covert lawbreaking can be legally unassailable by being sufficiently covert. Oh yeah, absolutely.
|
|
#
?
Oct 24, 2015 19:03
|
|
|
inignot posted:I've done a bunch of IPSec VPNs with Cisco routers. The two IPSec related things that could involved RSA keys would be using RSA keypairs for authentication, and the Diffie-Hellman group used for phase 1 key exchange (and I guess DH group for PFS also). Both of those require user intervention to configure, there's no 768 bit default that I know of. quote:The component technologies implemented for use by IKE include the following: So yeah, they actually do support D-H for key exchange, and 768-bit exchange is the default for that mode. 768-bit exchange is trivially breakable with that method, even by academic researchers. No idea on legacy support for the higher-strength D-H modes, but really just the fact that it's a default is bad enough. Paul MaudDib fucked around with this message at 00:08 on Oct 25, 2015 |
|
#
?
Oct 24, 2015 23:58
|
|
|
botany posted:That's a stupidly misleading description of the judgment in that case. (Not attacking you, just Ars Technica, by the way.) The judgment says that the plaintiffs' allegations are based on conjecture about how much Upstream surveillance architecture there is, about how much it is used, and about how much of their own traffic is affected. Even if Wikimedia were even bigger than they are, they could still only conjecture, and Clapper has established that conjecture is not enough to establish standing. The relevant bits are on pages 24 and following in the judgment, by the way, in case anybody wants to read this stuff. Well, courts won't allow classified documents to be admitted as legal evidence, regardless of whether you have them. Therefore, any allegations are merely speculation and conjecture because you have no evidence, QED. Case closed. You can't prove the take levels unless the NSA is dumb enough to take out a NYT advert and broadcast that they capture 32.1% of internet traffic, even if you have a slide that says as much. And you wouldn't even have to be making that circuitous argument if you could just admit the slide that says that Wikimedia was a target.
|
|
#
?
Oct 25, 2015 00:13
|
|
|
Paul MaudDib posted:http://www.cisco.com/en/US/docs/ios...5C-2DBBF6BE3EEA The definition of 'default' in that doc is really bizarre. If you don't create an isakmp policy there are several pre-defined policies available with low priority numbers in the IKE proposal sequence, none of which use 768 bit DH exchange. code:code:quote:Cisco no longer recommends using DES, 3DES, MD5 (including HMAC variant), and Diffie-Hellman (DH) groups 1, 2 and 5; instead, you should use AES, SHA-256 and DH Groups 14 or higher. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.
|
|
#
?
Oct 25, 2015 18:35
|
|
|
IUG posted:So if someone wanted to understand better these encryption standards and how they work/don't, how would one do this? Asking for a friend. The friend being me. All you need to know is that data is encrypted using a "I'm thinking of a number" and each bit makes that number a power of two bigger. Both sides need to know the number and key exchange is how they do this. Once you understand that being close is as worthless as being off by a million then you pretty much know enough to participate.
|
|
#
?
Oct 25, 2015 18:40
|
|
|
According to this, weak DH is not as prevalent as claimed. https://nohats.ca/wordpress/blog/2015/10/17/66-of-vpns-are-not-in-fact-broken/
|
|
#
?
Oct 27, 2015 15:30
|
|
|
Considering the current tenuous state of internet security, is it possible that the use of block-chains for transactions could provide a more secure and private means to transmit personal information and record transactions between individuals and major companies? E: Note that although buttcoin uses blockchain, blockchains appear to more useful than providing a means for overblown price speculation. America Inc. fucked around with this message at 09:21 on Nov 3, 2015 |
|
#
?
Nov 3, 2015 08:52
|
|
|
LookingGodIntheEye posted:Considering the current tenuous state of internet security, is it possible that the use of block-chains for transactions could provide a more secure and private means to transmit personal information and record transactions between individuals and major companies, making it much more difficult for governments or malicious third parties to snoop on our information? Why on earth would it do that? The blockchain is, if nothing else, a reliable, distributed log. Everyone who has a copy can be sure that they have the same copy everyone else does because of the consensus model and the cryptographic chain guaranteeing that identities need not be public. But the transactions themselves are public. There's no way to hide "I just got such-and-such many Bitcoins" in the blockchain, only the identity of the sender and the recipient are hidden. At best, it's security through obscurity (not knowing which wallet ID corresponds to which real-world individual), not real security needed to secure private information. This is why most applications of the blockchain are bunk, never mind the very-real technological and economic hurdles that block Bitcoin from being anything other than a toy currency that would impact an independent blockchain for most large-scale public purposes (transaction limits, rate of growth of the blockchain, incentives and fees, etc.) EDIT: The "blockchain" is basically the next virtual-reality or WebTV (if VR itself isn't that). Yeah, it might have some interesting things under the hood, and have some plausible applications, but it's not the silver bullet that it's been hyped to be. ComradeCosmobot fucked around with this message at 09:27 on Nov 3, 2015 |
|
#
?
Nov 3, 2015 09:16
|
|
|
ComradeCosmobot posted:Why on earth would it do that? The blockchain is, if nothing else, a reliable, distributed log. Everyone who has a copy can be sure that they have the same copy everyone else does because of the consensus model and the cryptographic chain guaranteeing that identities need not be public. But the transactions themselves are public. There's no way to hide "I just got such-and-such many Bitcoins" in the blockchain, only the identity of the sender and the recipient are hidden. At best, it's security through obscurity (not knowing which wallet ID corresponds to which real-world individual), not real security needed to secure private information.
|
|
#
?
Nov 3, 2015 09:29
|
|
|
This is encouraging: Snowden Meets the Internet Engineering Task Force http://www.internetsociety.org/publications/ietf-journal-november-2015/snowdon-meets-ietf quote:During IETF 93, approximately 170 participants attended a screening of Citizenfour, the movie about Edward Snowden’s revelations and the information that led the IETF to declare such pervasive monitoring as an attack on the Internet itself. The audience, the very people who design and maintain the Internet, watched the movie intently, their eyes glued to the screen; not a laptop was open.
|
|
#
?
Nov 3, 2015 13:42
|
|
|
LookingGodIntheEye posted:E: Note that although buttcoin uses blockchain, blockchains appear to more useful than providing a means for overblown price speculation. Blockchains are useless, due to the fact that their sole means of "security" is requiring a bunch of processing power to be wasted on making each write to it. We already have blockchains without the waste: it's every appendable database in the world.
|
|
#
?
Nov 3, 2015 15:43
|
|
|
Nintendo Kid posted:Blockchains are useless, due to the fact that their sole means of "security" is requiring a bunch of processing power to be wasted on making each write to it. We already have blockchains without the waste: it's every appendable database in the world. You're discounting the distributed aspect of the block chain though, so it's more like "every fault-tolerant distributed appendable database in the world" You're right that it's mostly useless though.
|
|
#
?
Nov 3, 2015 16:56
|
|
|
ComradeCosmobot posted:You're discounting the distributed aspect of the block chain though, so it's more like "every fault-tolerant distributed appendable database in the world" The distributed aspect is garbage and takes relatively forever for record updates to resolve
|
|
#
?
Nov 3, 2015 17:05
|
|
|
LookingGodIntheEye posted:Do you know of any good books or resources on how common (defined as: used by major companies) means of securing transactions are implemented? Like for example how to implement simple encryption algorithms in code for confidentiality or hashes to preserve the integrity of data? One of the rules of cryptography is "never roll your own", there's just too many ways to get it wrong. Any worthwhile language is going to have an official library that provides stuff like encryption and hashing, and they have already encountered and fixed all those weaknesses for you. Bruce Schneier's "Cryptography Engineering" is probably the place to start. It's not really a trivial subject to begin programming on - cryptography is a nitpicky, math-heavy subject by its very nature, on top of the other challenges of learning to program.
|
|
#
?
Nov 3, 2015 17:09
|
|
|
ComradeCosmobot posted:You're discounting the distributed aspect of the block chain though, so it's more like "every fault-tolerant distributed appendable database in the world" The distributed aspect only works due to massive wasted computing time part. (which also makes it utterly impractical for real use) That's why it's more like non distributed appendable databases.
|
|
#
?
Nov 3, 2015 17:15
|
|
|
~The blockchain is poo poo and bitcoin will never succeed because of it~ I hate when bitcoiners try and evangelize it as a solution for communication.
|
|
#
?
Nov 3, 2015 17:17
|
|
|
ayn rand hand job posted:The distributed aspect is garbage and takes relatively forever for record updates to resolve Hence the "mostly useless" part. It's an interesting technical exercise. Nothing more. EDIT: Nintendo Kid posted:The distributed aspect only works due to massive wasted computing time part. (which also makes it utterly impractical for real use) That's why it's more like non distributed appendable databases. Correct me if I'm wrong, but I was under the impression that the 10-minute resolution time was arbitrarily picked and could be made shorter or longer? ComradeCosmobot fucked around with this message at 17:47 on Nov 3, 2015 |
|
#
?
Nov 3, 2015 17:40
|
|
|
|
| # ? May 17, 2024 08:40 |
|
|
ComradeCosmobot posted:Correct me if I'm wrong, but I was under the impression that the 10-minute resolution time was arbitrarily picked and could be made shorter or longer? Buddy, it's the eventually needing to keep terabytes of data on multiple independent systems that's impractical, as well as having to dump massive amounts of processing time into each block that further makes it impractical. And then when you start decreasing the average block times there's more opportunities for conflicting results that take several block cycles to sort out. The entire concept, frankly, is dumb. Especially for purported business applications where it's being used between a few parties that trust each other... so why use a technology where the only thing it kinda solves is relationship between thousands of untrusted parties? Why do we need everybody to have on hand all individual transactions since the beginning of time, when all you need is say the current balances/information, discrete transactions for a few months online, and then anything older can be put into another form of storage if needed?
|
|
#
?
Nov 3, 2015 18:09
|
|