Re: [Cryptography] RSA equivalent key length/strength
Peter Fairbrother writes: >If you just want a down-and-dirty 2048-bit FS solution which will work today, >why not just have the websites sign a new RSA-2048 sub-certificate every day? >Or every few hours? And delete the secret key, of course. ... and I guess that puts you firmly in the theoretical/impractical camp. Would you care to explain how this is going to work within the TLS protocol? It's easy enough to throw out these hypothetical what-if's (gimme ten minutes and I'll dream up half a dozen more, all of them theoretically OK, none of them feasible), but they need to actually be deployable in the real world, and that's what's constraining the current debate. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
On 22/09/13 03:07 AM, Patrick Pelletier wrote: On 9/14/13 11:38 AM, Adam Back wrote: Tin foil or not: maybe its time for 3072 RSA/DH and 384/512 ECC? I'm inclined to agree with you, but you might be interested/horrified in the "1024 bits is enough for anyone" debate currently unfolding on the TLS list: http://www.ietf.org/mail-archive/web/tls/current/msg10009.html 1024 bits is pretty good, and there's some science that says it's about right. E.g., risk management says there is little point in making a steel door inside a wicker frame. The problem is more to do with distraction than anything else. It is a problem that people will argue about the numbers, because they can compare numbers, far more than they will argue about the essentials. There is a psychological bias to beat ones chest about how tough one is on the numbers, and thus prove one is better at this game than the enemy. Unfortunately, in cryptography, almost always, other factors matter more. So, while you're all arguing about 1024 versus 4096, what you're not doing is delivering a good system. That delay feeds in to the customer equation, and the result is less security. Even when you finally compromise on 1964.13 bits, the result is still less security, because of other issues like delays. and there was a similar discussion on the OpenSSL list recently, with GnuTLS getting "blamed" for using the ECRYPT recommendations rather than 1024: http://www.mail-archive.com/openssl-users@openssl.org/msg71899.html Yeah, they are getting confused (compatibility failures) from too much choice. Never a good idea. Take out the choice. One number. Get back to work. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
> "Patrick" == Patrick Pelletier writes: > On 9/14/13 11:38 AM, Adam Back wrote: >> Tin foil or not: maybe its time for 3072 RSA/DH and 384/512 ECC? > I'm inclined to agree with you, but you might be interested/horrified > in the "1024 bits is enough for anyone" debate currently unfolding on > the TLS list: > http://www.ietf.org/mail-archive/web/tls/current/msg10009.html I'm even more horrified, that the Apache webserver uses 1024-bit Diffie Hellman exchange for TLS/SSL with no way to increase group size other than modifying and recompiling the sources. Now that everybody calls for website operators to enable perfect-forward secrecy, we may in fact see an overall security downgrade. http://grokbase.com/t/apache/dev/1393kx4qn8/ http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html (Of course you can also get PFS via ECDHE, but many production webserver installations run older openssl versions that only support DHE) David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg Fingerprint: B63B 6AF2 4EEB F033 46F7 7F1D 935E 6F08 E457 205F pgpUBN3vC235n.pgp Description: PGP signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
I think, if we are about redesigning and avoiding the failures of the past, we have to unravel the false assumptions of the past... On 20/09/13 01:21 AM, Phillip Hallam-Baker wrote: ... Bear in mind that securing financial transactions is exactly what we designed the WebPKI to do and it works very well at that. Reasonable people may disagree with that claim. PKI for the web was designed to secure *one small part* of the financial process -- sending credit card numbers over the net. To secure financial transactions without limit, we'd need an end-to-end solution. E.g., online banking (which comes much later) requires an authentication solution, which offering by WebPKI (the client cert) is infamously not used; and, as a counterpoint, the biggest hacks occur at the server, being that "large part" of financial transactions that WebPKI explicitly ignored. Further, "very well" is a gross exaggeration of marketing proportions. In order to say it works "very well" at even its small part of protecting access to servers, we'd have to solve the browser authentication problem that is at the root cause of phishing. I grant that the phishing bug was addressed at a level of PKI-me-harder, but we still lack a solution... Criminals circumvent the WebPKI rather than trying to defeat it. If they did start breaking the WebPKI then we can change it and do something different. Oh, they broke it. Criminals send an unauthenticated URL and the user goes to that URL. The browser doesn't notice, the user doesn't notice, and the implementors conspire not to notice. WebPKI is totally broken. The fact that the criminals didn't follow the cutesy rules laid out in the WebPKI security model is not a circumvention but a breach and an excuse -- the rules weren't applicable to the real world. And, regardless of whether we decide that it is circumvention or breach, nothing positive was ever done about it. So we're left arguing about the point of something that is too easy to circumvent and doesn't get fixed. WebPKI is either an historical oddity or an economic drag on real security. (Quite where reasonable people might have a reasonable disagreement is where the breach/circumvention is; that's an argument that will (and did) roll on for a decade, which is perhaps why it never gets fixed... insert long thread.) But financial transactions are easier than protecting the privacy of political speech because it is only money that is at stake. The criminals are not interested in spending $X to steal $0.5X. We can do other stuff to raise the cost of attack if it turns out we need to do that. So I think what we are going to want is more than one trust model depending on the context and an email security scheme has to support several. Yes. Challenge is to get that into the supply chain. If we want this to be a global infrastructure we have 2.4 billion users to support. If we spend $0.01 per user on support, that is $24 million. It is likely to be a lot more than that per user. Enabling commercial applications of the security infrastructure is essential if we are to achieve deployment. If the commercial users of email can make a profit from it then we have at least a chance to co-opt them to encourage their customers to get securely connected. It's either that, or bypass completely. I agree email looks difficult, and the economics suggest bypass not rebuild. One of the reasons the Web took off like it did in 1995 was that Microsoft and AOL were both spending hundreds of millions of dollars advertising the benefits to potential users. Bank America, PayPal etc are potential allies here. Curiously (digression), Paypal bought Skype for a secure end-to-end solution to many of these problems. They never capitalised on it. Did they ever say why? iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
On 23/09/13 09:47, Peter Gutmann wrote: Patrick Pelletier writes: I'm inclined to agree with you, but you might be interested/horrified in the "1024 bits is enough for anyone" debate currently unfolding on the TLS list: That's rather misrepresenting the situation. It's a debate between two groups, the security practitioners, "we'd like a PFS solution as soon as we can, and given currently-deployed infrastructure DH-1024 seems to be the best bet", and the theoreticians, "only a theoretically perfect solution is acceptable, even if it takes us forever to get it". (You can guess from that which side I'm on). Lessee - a "forward secrecy solution" which either doesn't work now or won't work soon - so that it probably won't protect traffic made now for it's useful lifetime - versus - well, who said anything about theoretically perfect? To hell with perfect. I won't even use the word when describing forward secrecy (unless it's an OTP). If you just want a down-and-dirty 2048-bit FS solution which will work today, why not just have the websites sign a new RSA-2048 sub-certificate every day? Or every few hours? And delete the secret key, of course. Forward secrecy doesn't have to be per-session. Though frankly, I don't think ubiquitous 1024-bit FS without deployment of some software/RFC/standard is possible, and if so that deployment should also include a 2048-bit solution as well. And maybe 3072-bit and 4096-bit solutions too. And please please please don't call them all the same thing - because they aren't. But, the immediate question before the court of TLS now is - "do we recommend a 1024-bit FS solution?" And I for one cannot say that you should. In fact I would be horrified if you did. -- Peter Fairbrother ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
Patrick Pelletier writes: >I'm inclined to agree with you, but you might be interested/horrified in the >"1024 bits is enough for anyone" debate currently unfolding on the TLS list: That's rather misrepresenting the situation. It's a debate between two groups, the security practitioners, "we'd like a PFS solution as soon as we can, and given currently-deployed infrastructure DH-1024 seems to be the best bet", and the theoreticians, "only a theoretically perfect solution is acceptable, even if it takes us forever to get it". (You can guess from that which side I'm on). Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA recommends against use of its own products.
On 22/09/13 16:43 PM, Jerry Leichter wrote: On Sep 20, 2013, at 2:08 PM, Ray Dillinger wrote: More fuel for the fire... http://rt.com/usa/nsa-weak-cryptography-rsa-110/ RSA today declared its own BSAFE toolkit and all versions of its Data Protection Manager insecure, recommending that all customers immediately discontinue use of these products Wow. You took as holy writ on a technical matter a pronouncement of the general press. Etc. Yes, we expect the company to declare itself near white, and the press to declare it blacker than the ace of spaces. Meanwhile, this list is about those who know how to analyse this sort of stuff, independently. So... ... But they made Dual EC DRBG the default ... I don't see a lot of distance between choosing Dual_EC as default, and the conclusion that BSAFE & user-systems are insecure. The question that remains is, was it an innocent mistake, or were they influenced by NSA? We don't have much solid evidence on that. But we can draw the dots, and a reasonable judgement can fill the missing pieces in. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What is Intel® Core™ vPro™ Technology Animation
On Sep 22, 2013, at 7:56 PM, d.nix wrote: > ...If for example, the paper regarding manipulating the RNG circuit by > alternate chip doping is valid, then an adversary with deep pockets > and vast resources might well be able remotely target specific systems > on demand. Possibly even air gapped ones if this function is > controllable via a 3G signal as I have read elsewhere. > > Or perhaps just outright reroute and tap information prior to > encryption, or subtly corrupt things in other ways such that processes > fail or leak data You started off concerned about misuse of a "remote override" function that Intel deliberately puts on the chips - a valid concern - but now have wandered off into arbitrary chip modifications. Those, too, are perhaps valid concerns - but they've been concerns for many years. Nothing new here, except that the deeper we look, the more ways we find to hide attacks within the hardware. That said, the doping paper, if I understood the suggestion correctly, discussed a way to modify individual chips, not whole runs of them. (Presumably you could modify whole runs by spiking the production process, but that would be difficult to hide: Chip manufacturing is by its nature a very tightly controlled process, and an extra step isn't something that people would miss. It would probably even show up in the very tightly watched yield statistics: The extra step would delay wafers on the line, which would cause the yield to drop. The beauty of the doping attack is that it's undetectable - at least right now; for every attack, a defense; for every defense, an attack. But exactly how one might make the *implementation* of the attack undetectable isn't at all clear.) > H. Maybe time to pull my old 1996 SGI R10K and R4400 boxes out of > storage. For a few *very* dedicated and air gapped tasks they might be > a small measure of worthwhile trouble. You'll be amazed at how slow they now seem Still, it raises the question: If you can't trust your microprocessor chips, what do you do? One possible answer: Build yourself a processor out of MSI chips. We used to do that, not so long ago, and got respectable performance (if not, perhaps, on anything like today's scale). An MSI chip doesn't have enough intrinsic computation to provide much of a hook for an attack. Oh, sure, the hardware could be spiked - but to do *what*? Any given type of MSI chip could go into many different points of many different circuit topologies, and won't see enough of the data to do much anyway. There may be some interface issues: This stuff might not be fast enough to deal with modern memory chips. (How would you attack a memory chip? Certainly possible if you're make a targeted attack - you can slip in a small processor in the design to do all kinds of nasty things. But commercial of the shelf memory chips are built right up to the edge of what we can make, so you can't change a ll that much.) Some stuff is probably just impossible with this level of technology. I doubt you can build a Gig-E Ethernet interface without large-scale integration. You can certainly do the original 10 Mb/sec - after all, people did! I have no idea if you could get to 100 Mb/sec. Do people still make bit-slice chips? Are they at a low-enough level to not be a plausible attack vector? You could certainly build a respectable mail server this way - though it's probably not doing 2048-bit RSA at a usable speed. We've been talking about crypto (math) and coding (software). Frankly, I, personally, have no need to worry about someone attacking my hardware, and that's probably true of most people. But it's *not* true of everyone. So thinking about how to build "harder to attack" hardware is probably worth the effort. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Cryptographic mailto: URI
Op 20 sep. 2013, om 14:55 heeft Phillip Hallam-Baker het volgende geschreven: > On Fri, Sep 20, 2013 at 4:36 AM, Dirk-Willem van Gulik > wrote: > > Op 19 sep. 2013, om 19:15 heeft Phillip Hallam-Baker het > volgende geschreven: > > > Let us say I want to send an email to al...@example.com securely. > ... > > ppid:al...@example.com:example.net:Syd6BMXje5DLqHhYSpQswhPcvDXj+8rK9LaonAfcNWM > … ... > ...fqdn-in-some-tld. > > which is in fact a first-come, first-served secure dynamic dns updatable zone > containing the public key. > > Which once created allows only updating to those (still) having the private > key of the public key that signed the initial claim of that . > > Interesting, though I suspect this is attempting to meet different trust > requirements than I am. Most likely. The aim was not so much to secure an entry - but to provide a sufficiently solid bread-crum trail to the information which could be used to do so; to be able to use both 'trust on first contact' -or- a trust chain; and to provide 'low cost' yet very robust pillars that can be managed by 'untrusted' parties. Or in other words - the design focused more on a workable trust infrastructure with the governance pushed as close to the (end) user as possible; at the expense of some 'absolute default' trust (absolute as in the sort of trust you'd get by default from 'some deity/governement/big-mega-crop says I am good/interacting with a legal entity). Dw. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] The hypothetical random number generator backdoor
So we think there is 'some kind' of backdoor in a random number generator. One question is how the EC math might make that possible. Another is how might the door be opened. I was thinking about this and it occurred to me that it is fairly easy to get a public SSL server to provide a client with a session key - just ask to start a session. Which suggests that maybe the backdoor is of the form that if you know nonce i, and the private key to the backdoor, that reduces the search space for finding nonce i+1. Or maybe there is some sort of scheme where you get a lot of nonces from the random number generator, tens of thousands and that allows the seed to be unearthed. Either way, the question is how to stop this side channel attack. One simple way would be to encrypt the nonces from the RNG under a secret key generated in some other fashion. nonce = E (R, k) Or hashing the RNG output and XORing with it nonce = r XOR H (r) Either way, there is an extra crypto system in the way that has to be broken if a random number generator turns out to have some sort of relationship between sequential outputs. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What is Intel® Core™ vPro™ Technology Animation
On Sep 21, 2013, at 10:05 PM, d.nix wrote: > Hah hah hah. Uh, reading between the lines, color me *skeptical* that > this is really what it claims to be, given the current understanding > of things... > > http://www.intel.com/content/www/us/en/enterprise-security/what-is-vpro-technology-video.html The question isn't whether it's what it claims to be. It is that. But is it's *more* than it claims to be. There are a whole bunch of things in recent Intel chips to provide manageability and security. And there are cases where this is very valuable and necessary - e.g., if you have a large cluster or processors, it's good to be able to remotely configure them no matter what state they are in. There are many similar examples. If it's *your* hardware, *your* ability to control it, in detail, is a good thing. (Yes, if you've been lent the hardware by your employer, it's the *employer* who's the owner, not you, and it's the *employer* who can do what he likes. This has always been the case to a large degree. If it makes you uncomfortable - buy your own machine, don't use your work machine for non-work things.) The *theory* is that the owner can enable or disable these features, and has the keys to access them if enabled. What we don't know is whether anyone else has a back-door key. The phrase I always use to describe such situations is "if there's a mode, there's a failure mode". Such technology could have been present in previous generations of chips, completely invisibly - but it would have required significant effort on Intel's part with no real payback. But once Intel is adding this stuff anyway ... well, it's only a small effort to provide a special additional back door access. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The Case for Formal Verification
Tim, > With all due respect, most of the points you make are ridiculous. Could you please explain why you think they are ridiculous. > For example, you point out that the certified C compiler will not > make any guarantees about code that relies on undefined behavior. > Well, of course! Being certified doesn't magically fix your specification! > Certified just says the implementation matches the specification! Where did the word "certified" come from? I have not said anything about magically fixing a specification. The CompCert people are claiming a formally verified compiler and I think this claim is very misleading to say the least. > And to suggest that such a project is misguided because it places > blind trust in coq (and because it is written in ocaml?!) shows a I did not say that this project was misguided. > misunderstanding of the proof tools. There is a very small core of > trust that you need to have faith in and it is backed by solid theory Yes, the axioms. These need to be small in number and 'obviously' correct; something that cannot be said of the source code of coq. The nearest I can think of is the Lisp subset written in itself in under a 100 lines (my memory is vague on this point) > and is a much more solid foundation for building on than just about > any other software we have in computer science. I don't see how in > any way you can compare the f2c translator to this effort. Why not? What work has been done on the coq+other tools that has not been done on f2c? I describe work that was done to try and show the correctness of a Model Implementation for C here: http://shape-of-code.coding-guidelines.com/2011/05/02/estimating-the-quality-of-a-compiler-implemented-in-mathematics/ [ My original post to this list bounced, so I am reposting it here now), it cam ebefore the message it is replying to] ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
On 9/21/13 at 5:07 PM, c...@funwithsoftware.org (Patrick Pelletier) wrote: I'm inclined to agree with you, but you might be interested/horrified in the "1024 bits is enough for anyone" debate currently unfolding on the TLS list: http://www.ietf.org/mail-archive/web/tls/current/msg10009.html I think that this comment is a serious misinterpretation of the discussion on the TLS list. The RFC under discussion is a Best Current Practices (BCP) RFC. Some people, including me, think that changes to the protocol or current implementations of the protocol are out of scope for a BCP document. There are several implementations of TLS which will only do 1024 bit Diffie-Hellman ephemeral (DHE)[1]. The question as I see it is: Are we better off recommending forward security with 1024 bit DHE, with the possibility that large organizations can brute force it; or using the technique of having the client encrypt the keying material with the server's RSA key with the probability that the same large organizations have acquired the server's secret key. Now there are good arguments on both sides. The nearly complete database of who talks to who allows "interesting" communications [2] to be singled out for attacks on the 1024 bit DHE. Cracking all the DHE exchanges is probably more work than these large organizations can do with current technology. However, it is almost certain that these sessions will be readable in the not too distant future. It is widely believed that most large sites have had their RSA secret keys compromised, which makes all these sessions are trivially readable. I think that the vast majority of TLS list commenters want to have TLS 1.3 include fixes for the problems that have been identified. However, getting TLS 1.3 approved is at least a year, and getting it through the FIPS process will add at least another year. We already know that these large organizations work to delay better crypto, sometimes using the argument that we should wait for the perfect solution rather than incrementally adopt better solutions in the mean time. Cheers - Bill [1] Implementations which will only do 1024 bit DHE are said to include: Apache with OpenSSL, Java, and Windows crypt libraries (used by Internet Explorer). If longer keys are used by the other side, they abort the connection attempt. [2] I actually believe NSA when they say they aren't interested in grandma's cookie recipe. I am, but I like good cookies. :0) --- Bill Frantz| Privacy is dead, get over| Periwinkle (408)356-8506 | it. | 16345 Englewood Ave www.pwpconsult.com | - Scott McNealy | Los Gatos, CA 95032 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
On 09/22/2013 01:07 AM, Patrick Pelletier wrote: > "1024 bits is enough for anyone" That's a mischaracterisation I think. Some folks (incl. me) have said that 1024 DHE is arguably better that no PFS and if current deployments mean we can't ubiquitously do better, then we should recommend that as an option, while at the same time recognising that 1024 is relatively short. S. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Fwd: Re: What is Intel® Core™ vPro™ Technology Animation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Original Message Subject: Re: What is Intel® Core™ vPro™ Technology Animation Date: Mon, 23 Sep 2013 05:56:48 +0200 From: To: cypherpu...@cpunks.org Security Evaluation of Intel's Active Management Technology VASSILIOS VERVERIS Master of Science Thesis Stockholm, Sweden 2010 [...] During production AMT platforms are equipped with one or more active embedded hashed root certificates (factory default) from various SSL vendors worldwide. [...] In our laboratory environment (see section 3) we have tested and found that the ZTC remote provisioning can be implemented even while the Intel AMT functionality is disabled within the BIOS as illustrated in Figure 3.6. Surprisingly the AMT platform broadcasts an ARP request packet upon connecting to a wired network (typically a LAN) and follows the sequence described in section 3.7.1. From this point and beyond the attacker operates the SCS and could manipulate the PC according to his/her malicious activities (see section 3.7.5) even while the Intel AMT is disabled in BIOS. http://kth.diva-portal.org/smash/get/diva2:508256/FULLTEXT01 - -- H. That's not very reassuring. DN -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJSP8W2AAoJEDMbeBxcUNAeYpgH/il2j/5ipVpRDsTjzOw0nPQH MCiqNj9uqQGnAi9nCGHi99vFGax/IoTGcu/n7Tx+3Nqb9laacjyYu7lYREb5H/QR cncppjotuIvNpVBhkLHES80cg71KmQ/UwwTHw1SCXCB7SIuYWaLELzcQyiK+4hj+ txlzxvx7sPEanksixZGTuR6ikq/H5RdHtDQoww/9eT2WmV+VXAGgm0ffs0sA4iQW 6aEGY1+dwi/+fOAWRjG4Wg51GsCpXeIsJ9ofjcwS8iWpyht51lwkvC6uladTXmoR 5iM9IAxPp/yz9CUkiFRNxAYMrjbMXt4xvXPgbzGM6rOYEGhqfSCv4s6671yxmDk= =AibC -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What is Intel® Core™ vPro™ Technology Animation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/22/2013 2:23 PM, Jerry Leichter wrote: > On Sep 21, 2013, at 10:05 PM, d.nix wrote: >> Hah hah hah. Uh, reading between the lines, color me *skeptical* >> that this is really what it claims to be, given the current >> understanding of things... >> >> http://www.intel.com/content/www/us/en/enterprise-security/what-is-vpro-technology-video.html > >> The question isn't whether it's what it claims to be. It is that. But is it's *more* than it claims to be. > Yes, in my haste I neglected the "only" disclaimer bit; it is indeed a means by which the *rightful owner/administrator* might perform very useful tasks. The obvious crux of the biscuit is *who else* has access, and what can they do surreptitiously? If for example, the paper regarding manipulating the RNG circuit by alternate chip doping is valid, then an adversary with deep pockets and vast resources might well be able remotely target specific systems on demand. Possibly even air gapped ones if this function is controllable via a 3G signal as I have read elsewhere. Or perhaps just outright reroute and tap information prior to encryption, or subtly corrupt things in other ways such that processes fail or leak data. A universal on-demand STUXNET, if you will... Yes, idle unfounded speculation, I know... but still... these days the fear is that we're not paranoid enough. H. Maybe time to pull my old 1996 SGI R10K and R4400 boxes out of storage. For a few *very* dedicated and air gapped tasks they might be a small measure of worthwhile trouble. Regards, DN -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJSP4OfAAoJEDMbeBxcUNAeVmUH/3MRSd/QkH9J/fY4iezSX/ME 2AbXaRSJmyLhZPW/c+moH0aUYAIPUQQ3JmVt0InZWM06jrR0pO/I9GxIM9IUWYM7 /6u/NLUcdiDtJx+BLcyUdtqSpYErkWQH9qoWxunDtUUj988xxTgia1Q+yN0h+ZOg 6PJtXB8+fTAGSoRCkhuokitB/XGbMFgAxtIyq2CMVSr3v0fOGCItvEq2wVzw8+h1 o0ps90OE3RLnel6u4YNm5EFRWoDiwN45+u/wGdXHJlSUZrncX1o6NsGvSC/0Pl94 7CYF7qpeltMMzpgPrp0IeWrls/G89FdOnjD97nzcCQ480RZAfpYCNXOIBURXq+I= =SUzc -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
On Sat, Sep 21, 2013 at 05:07:02PM -0700, Patrick Pelletier wrote: > and there was a similar discussion on the OpenSSL list recently, > with GnuTLS getting "blamed" for using the ECRYPT recommendations > rather than 1024: > > http://www.mail-archive.com/openssl-users@openssl.org/msg71899.html GnuTLS is reasonably sound engineering in electing 2048-bit groups by default on the TLS server. This inter-operates with the majority of clients, all the client has to do is to NOT artificially limit its implementation to 1024 bit EDH. GnuTLS fails basic engineering principles when it sets a lower bound of 2048-bit EDH in its TLS client code. TLS clients do not negotiate the DH parameters, only the use of EDH, and most server implementations deployed today will offer 1024-bit EDH groups even when the symmetric cipher key length is substantially stronger. Having GnuTLS clients fail to connect to most servers, (and e.g. with opportunistic TLS SMTP failing over to plain-text as a result) is not helping anyone! To migrate the world to stronger EDH, the GnuTLS authors should work with the other toolkit implementors in parallel with and through the IETF to get all servers to move to stronger groups. Once that's done, and the updated implementations are widely deployed raise the client minimum EDH group sizes. Unilaterally raising the client lower-bound is just, to put it bluntly, pissing into the wind. -- Viktor. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Gilmore response to NSA mathematician's "make rules for NSA" appeal
On Sep 18, 2013, at 3:27 PM, Kent Borg wrote: > You foreigners actually have a really big vote here. All those US internet > companies want your business, and as you get no protections, in the current > scheme, not even lip-service, you should look for alternatives. As you do, > this puts pressure on the US internet companies, and they have the economic > clout to put pressure on Feinstein and Polosi and all the others. This does not go far enough. The US government is not the only one inclined to steal information which it can reach, either because the information goes over wires the government can listen in on, or because the companies handling the data can be compelled or convinced to hand it over. Right now, we're seeing leaks that confirm the serious efforts of one government to do this stuff, but it is absolutely silly to think the US is the only one doing it. The right way to address this is to eliminate the need to trust almost anyone with your data. If Google[1] has all your cleartext documents and emails, they can be compelled to turn them over, or they can decide to look at them for business reasons, or they can be infiltrated by employees or contractors who look at those emails and documents. You are trusting a lot of people, and trusting a company to possibly behave against its economic interests and legal obligations, to safeguard your privacy. If they have encrypted data only, you don't have to trust them. It needs to be in their business interest to convince you that they *can't* betray you in most ways. > -kb --John [1] I'm not picking on Google in particular--any US company may be compelled to turn over data they have. I imagine the same is true of any German or Korean or Brazilian company, but I don't know the laws in those places. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
