Re: [cryptography] Algorithm that can be *least* optimized on CPUs?
On Sep 1, 2014, at 1:15 AM, Rob Stradling rob.stradl...@comodo.com wrote: On 31/08/14 19:53, Paul Hoffman wrote: Greetings. I want to use openssl speed as a very loose proxy for how fast is this CPU right now. (Note the use of the word very there.) I also want to test systems that are running in VMs. However, if I'm comparing across CPU families, OpenSSL might have some optimizations for some algorithms (like AES) that work better or worse depending on the features of the CPU. If I were to pick one algorithm that is least likely to be optimized past normal C optimization, which would it be? Paul, if you build OpenSSL with the no-asm configuration option, presumably none of the algorithms will be optimized past normal C optimization. Does this help? Yep, thanks. Also, I got an off-line note that no one had ever figured out how to optimize TripleDES at all, so that was a safe one to use as a reference. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Algorithm that can be *least* optimized on CPUs?
Greetings. I want to use openssl speed as a very loose proxy for how fast is this CPU right now. (Note the use of the word very there.) I also want to test systems that are running in VMs. However, if I'm comparing across CPU families, OpenSSL might have some optimizations for some algorithms (like AES) that work better or worse depending on the features of the CPU. If I were to pick one algorithm that is least likely to be optimized past normal C optimization, which would it be? --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
On Apr 9, 2014, at 4:41 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: I figure there are some protocol design lessons maybe. There's a thread started on the TLS list about it today. [2] Be interesting to see what that turns up. There is actually a second thread on the TLS list today related to the topic of protocol design lessons: https://www.ietf.org/mail-archive/web/tls/current/msg11889.html. It will be interesting to see what that turns up as well. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Which programs need good random values when a system first boots?
Greetings again. The recent discussion seems to have veered towards having enough good random bits to create long-lived keys the first time that a system boots up. Which programs need this? sshd is at the top of the list; are there others? --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SSL session resumption defective (Re: What project would you finance? [WAS: Potential funding for crypto-related projects])
On Jul 2, 2013, at 1:52 PM, Ben Laurie b...@links.org wrote: Alternatively, we stay in this world, clients expire sessions hourly, and we're all happy. Is this what most recent browsers do? They expire their TLS sessions after an hour? That would be nice. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SSL session resumption defective (Re: What project would you finance? [WAS: Potential funding for crypto-related projects])
On Jul 2, 2013, at 2:59 PM, Ryan Sleevi ryan+cryptogra...@sleevi.com wrote: On Tue, July 2, 2013 2:02 pm, Paul Hoffman wrote: On Jul 2, 2013, at 1:52 PM, Ben Laurie b...@links.org wrote: Alternatively, we stay in this world, clients expire sessions hourly, and we're all happy. Is this what most recent browsers do? They expire their TLS sessions after an hour? That would be nice. --Paul Hoffman Firefox and Chrome use a 24-hour period, as recommended - see http://mxr.mozilla.org/nss/source/lib/ssl/sslnonce.c#21 CryptoAPI/SChannel defaults to 10 hours, but I don't know if IE is tweaking that at all - see dwSessionLifespan for http://msdn.microsoft.com/en-us/library/windows/desktop/aa379810(v=vs.85).aspx OS X/SecureTransport uses ten minutes as the default - see SESSION_CACHE_TTL in http://www.opensource.apple.com/source/Security/Security-55179.11/libsecurity_ssl/security_ssl/appleSession.c Is this what people are seeing when they test these clients against test servers? --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] crypto breakage in SALT
The comment thread is interesting for the level of I'm not a cryptographer but I know X is true -- oh wait, now I'm not so sure. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Interesting Webcrypto question
You've now exported crypto to a restricted country. What happens next? You ask a lawyer or a legislator, not a bunch of amateurs in the subject? --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
On Feb 18, 2013, at 5:43 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Bodo Moeller bmoel...@acm.org writes: If you wonder why NSS would prefer Camellia over AES (I sure did), here's the rationale. (Not a very good one, in my opinion -- if servers in certain countries are expected to have a strong preference for certain ciphersuites, those servers should override client preferences rather than hope that clients list them at higher priority than AES.) Another option is: switch( locale ) case Japan: cipher = Camellia; case Russia: cipher = GOST; case Korea: cipher = SEED; case France: cipher = JEAN_PAUL_GAULTIER; // Since we're making fashion statements ... case Burkina_Faso: cipher = whatever; This one would make more sense than forcing everyone to use Japan's vanity cipher. I like this approach, although I would change cipher to one_of_the_ciphers_offered or maybe first_cipher_offered, not the only cipher offered. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Bonding or Insuring of CAs?
On Jan 25, 2013, at 4:11 PM, Natanael natanae...@gmail.com wrote: If somebody wants there to be a pure cryptography mailing list and separate more generic one (like this one currently is), I think that person would have to try starting a more strict crypto mailing list, because I don't think most people here would want the rules here to get stricter or that they would want to switch to a different list that would be just like this one is now. The off-list responses to my message would disagree with you. We also don't want too many different lists. Some of we do. My question was to tease this out a bit. I'm happy to shut up about it if I'm in the minority, but the question that started this thread was a perfect example of something that is about security (actually, security operations), not cryptography, and yet gets brought up on this list more and more. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] current limits of proving MITM (Re: Gmail and SSL)
There is an IETF mailing list for discussing CT: https://www.ietf.org/mailman/listinfo/therightkey Discussions on this list may or may not affect the document that Google is preparing as an RFC; discussions on that list will be much more likely to do so. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Just how bad is OpenSSL ?
On Oct 30, 2012, at 9:11 AM, Thierry Moreau thierry.mor...@connotech.com wrote: Then it's just a matter of the shortest route to finish: route a) secure the swap, route b) monitor software components for maximum memory usage vs physical mem plus make a memory exhaustion fault analysis. Errr, isn't the shortest route c) don't use swap in that system? You are not *forced* to use swap in Linux: I have plenty of Linux instances where it is not turned on. Noting that it is humorous that people are attributing this to bad OpenSSL, not bad understanding of the places where OpenSSL runs --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Bitcoin in endgame
On Feb 24, 2012, at 11:49 AM, Thor Lancelot Simon wrote: Is the major purpose of this mailing list really the discussion of political and social theory? I thought I had subscribed to cryptography@randombit.net, not I already spent four years doing political science, thanks. +1. Although it is nice to discover that I'm not the only person on the list who did four years doing political science. :-) --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Duplicate primes in lots of RSA moduli
On Feb 20, 2012, at 9:22 AM, Thierry Moreau wrote: First, let me put aside the initial entropy assessment issue -- it's not solvable without delving into the details, and let me assume the freebsd entropy collection is good, at the possible cost of slowing down the boot process. But that is central to this thread. FreeBSD doesn't block on first boot because it doesn't create SSH keys on first boot. The security team decided long ago that good security that system administrators could not screw up was of high priority. Thus, FreeBSD doesn't come with SSH installed; it has to be installed after installation. This has two big security wins: - There is no chance that the OpenSSH version that is part of the distro has a bug that was later fixed because there is no OpenSSH version in the distro - The act of first booting and then pulling down things like OpenSSH gives the entropy pool a chance to grow to a sufficient size to create good keys So, the freebsd design appears reasonable to me. Can it be brought into Linux? Is it a Linux design flaw to omit boot-time entropy assessment? Different Linux distros make different choices. Linux is an operating system, not a distribution. FreeBSD is a distribution. My answers are only as an option and no. Given the above, I suggest that both of your answers are wrong. Even if a distro creator wants to include an ssh server as part of the distro, it is obviously dangerous to generate keys immediately on the first boot. The only possible reason to do so is so that the installer can immediately log in over SSH, but without knowing the actual keys being created. That is possibly tolerable on a network where there is no possible MITM, but is otherwise piss-poor security. A trivial way around the problem, even if you want to include an ssh server as part of the distro, is to not start ssh server in the first boot but to include a program that will install it later. The program that creates the ssh keys could check for /dev/random being blocked and, if it is, let the operator type a bunch of stuff that would unblock it. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Duplicate primes in lots of RSA moduli
On Feb 16, 2012, at 9:52 AM, Marsh Ray wrote: How often have we seen Linux distros generate SSH keys 2 seconds after the first boot? The paper that started this thread was talking about keys used for TLS, not SSH. TLS certs are not usually generated during first boot. The devices had plenty of time to get I/O. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Duplicate primes in lots of RSA moduli
On Feb 18, 2012, at 11:37 AM, Jeffrey I. Schiller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2012 01:50 PM, Thor Lancelot Simon wrote: Um, why would it ever _unblock_, on such a device under typical first-boot conditions? The idea would be that bootstrap would continue without the key being generated. The key generation could then be retried periodically. Eventually the device should gather some entropy from network packet arrival time and similar environmental input (whether or not that input, particularly in the VM environment, is providing really good entropy is a different question). Really? Many cryptographers would say that number of unpredictable bits is very much a part of the question. For example, you cannot prove that the duplicate keys found were generated when the PRNG of the system was uninitialized: it's quite possible that they were generated when the PRNG was initialized with the same inputs. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Applications should be the ones [GishPuppy]
On Feb 17, 2012, at 4:55 AM, Jack Lloyd wrote: On Thu, Feb 16, 2012 at 09:41:04PM -0600, Nico Williams wrote: developers agree). I can understand *portable* applications (and libraries) having entropy gathering code on the argument that they may need to run on operating systems that don't have a decent entropy provider. Another good reason to do this is resiliance - an application that takes some bits from /dev/(u)random if it's there, but also tries other approaches to gather entropy, and mixes them into a (secure) PRNG, will continue to be safe even if a bug in the /dev/random implementation (or side channel in the kernel that leaks pool bits, etc) causes the conditional entropy of what it is producing to be lower than perfect. I'm sure at some point we'll see a fiasco on the order of the Debian OpenSSL problem with /dev/random in a major distribution. Note the and mixes them into a (secure) PRNG. If the app developer does a bad (typical?) job and mixes them poorly, they can end up with less unpredictable bits than if they had just took the results from /dev/random. Looked at another way, if an app developer is going to do any processing on /dev/random, they should really look at the result as the app having its own fully-functional PRNG that has input from the OS, not the app making an improvement on the OS. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] This paper was presented in August?
This coming August. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] OT: Key Internet [DNS] operator VeriSign hit by hackers
In case people want to read the, you know, actual text: https://investor.verisign.com/secfiling.cfm?filingID=1193125-11-285850CIK=1014473 tl;dr: Nothing about cryptography. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Well, that's depressing. Now what?
Why is this depressing? Because the snake oil was snakier or oilier? --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ECDSA - patent free?
On Nov 9, 2011, at 10:22 AM, Adam Back wrote: Anyone have informed opinions on whether ECDSA is patent free? Define informed. Seriously. Do you want to hear from actual lawyers? People who have talked to lawyers? People who think they understand law? Any suggestions on EC capable crypto library that implements things without tripping over any certicom claimed optimizations? Certicom claims patents on many things, among them optimizations. They are (IMNSHO) purposely vague on what they claim. (Someone pointed out to me recently that the redhat shipped openSSL is devoid of ECC which is kind of a nuisance!) Sure is. Suite B pushed use of EC you would think would increase the interest in having clarity on the EC patent situation.. How could that clarity possibly be achieved? Again, this is a serious question. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] factoring challenge no more?
On Oct 18, 2011, at 4:10 AM, ianG wrote: Another meta question: I seem to have missed the news that RSA has stopped their factoring challenge in 2007! http://en.wikipedia.org/wiki/RSA_Factoring_Challenge Has anything replaced it? This is a great loss, what on earth where RSA thinking? Can you say more why it is a great loss? --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] factoring challenge no more?
On Oct 18, 2011, at 8:24 AM, ianG wrote: On 19/10/11 01:51 AM, Paul Hoffman wrote: On Oct 18, 2011, at 4:10 AM, ianG wrote: Another meta question: I seem to have missed the news that RSA has stopped their factoring challenge in 2007! http://en.wikipedia.org/wiki/RSA_Factoring_Challenge Has anything replaced it? This is a great loss, what on earth where RSA thinking? Can you say more why it is a great loss? Well, it gave us a reliable benchmark. We still have that. When someone wants to break RSA 768 in a way that will be useful to the crypto community, they'll know exactly how to do it. It's also a very strong message, an easy to understand event. Cracking the code was easy for the media to grasp. There are very few such easy to explain events. In comparison, if you look at all the other crypto news, it's very hard to get a grasp of what it means .. to laymen. We strongly disagree here. Few, if any, media reports of the previous factorings did a reasonable job of explaining what breaking a key of ~700 bits meant to users of 1024 bit keys, much less of 2048 bit keys. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Let's go back to the beginning on this
On Sep 13, 2011, at 11:57 AM, Steven Bellovin wrote: From personal experience -- I use https to read news.google.com; Firefox 6 on a Mac complains about wildcard certificates. And ietf.org's certificate expired recently; it took a day or so to get a new one installed. This last bit might be relevant to the mailing list. - The IETF's cert was for *.ietf.org - It took a week, not a day or so to get the new one installed Steve: I wonder if your browser, after you dismissed the dialog once, silently remembered that dismissal for a week, or if it stopped asking you after a day. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] After the dust settles -- what happens next? (v. Long)
On Sep 11, 2011, at 4:50 PM, Ian G wrote: So, what happens now? As we all observe, there are two approaches to dealing with the collapse of faith of the PKI system: incremental fixes, and complete rewrite. We don't all observe that. Some of us observe a third, more likely approach: nothing significant happens due to this event. The collapse of faith is only among the security folks whose faith was never there in the first place. A week after the event, who was talking about it other than folks on these lists and lists like them? This is not to say that nothing should happen: it should, but it should have happened long ago. The fact that it didn't, and continues not to, should be significant to those predicting what will happen next. Personally, I'm hoping that the DANE work finishes and gets widely deployed, but I would not bet that it will. Even if it does, I would be absolutely shocked if 90% of major web sites ten years from now were *not* using CA-issued certs for TLS. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] After the dust settles -- what happens next? (v. Long)
On Sep 11, 2011, at 6:40 PM, Marsh Ray wrote: On 09/11/2011 07:26 PM, Paul Hoffman wrote: Some of us observe a third, more likely approach: nothing significant happens due to this event. The collapse of faith is only among the security folks whose faith was never there in the first place. A week after the event, who was talking about it other than folks on these lists and lists like them? The 300,00+ Iranians who were actively attacked and now have to change their password and are wondering if they'd said anything in Gmail to get them arrested and interrogated. Do you have any evidence that improving crypto is being talked about by those affected in Iran? I haven't seen it yet. The unknown numbers of Chinese (and people in other countries) who were hoping a US product like Gmail could provide a censorship-free email service. Same question. However, I have first-hand evidence that people in China are not talking about that, but instead are talking about how to make *Chinese* services work outside of government censorship. And those people aren't talking about PKIX. The Dutch IT people who have to replace the ~58,000 certs issued by DigiNotar PKIoverheid CA. http://www.techworld.com.au/article/400068/dutch_government_struggles_deal_diginotar_hack/ Look what you just wrote. Those folks aren't looking for us to fix PKIX: they are looking for different CAs. That's not a collapse of faith, just a desire for a quick fix. The management at Google who are likely scared as hell that the webmasters and security auditors of the 50% of major sites that source Javascript from https://google-analytics.com/ will realize that they would have been pwned too (and possibly been obligated to report it) had the attacker issued a cert for that. Could be, but neither you nor I work at Google so that's pure speculation. (There are likely some Googlers on this list who can speak authoritatively on whether their management are scared as hell or even noticing.) Who else thinks he probably will next time? The people responsible for security at Amazon, PayPal, every other big retailer and the financial services companies that handle high-value accounts. Again: where is your evidence that they (other than Andy) care enough? I have seen zero in the serious business press (Forbes, BusWeek, etc.) after the first few days. If there was much interest on the part of their readers (as in every other big retailer and the financial services companies), they would likely be milking it, but they are not. The governments and government contractors who depend on SSL VPNs with an in-band second factor of auth (like hardware token codes) to secure their remote access. I have first-hand evidence that they are not discussing the topic. The attacker himself: https://twitter.com/#!/ichsunx2 Why do you think he's not on this list? :-) The people who've generated the 367,772 views (so far) of Comodohacker's Pastebin texts: http://pastebin.com/u/ComodoHacker Pageviews != concern. Slashdot and their bazillion subscribers are still talking about it as of yesterday: http://it.slashdot.org/story/11/09/10/2129239/GlobalSign-Web-Server-Hacked-But-Not-CA Yes, true. Who isn't talking about it really? See above. Many of the people who you and I *want* to be concerned are not as concerned as you say. The full damage is not even out yet. This thing is just getting started. If there is more significant damage in the future, of course people will talk about it more. But that's just guessing about the future. Despite rumors to the contrary, there are, in fact, a great many influential people who do give a shit about the actual effective security delivered by SSL/TLS (beyond its ability to add an air of confidence to consumers' $50-liability-limit credit card transactions). Slashdot commenter are, by and large, not influential people. Please show evidence of the other groups you list above. This time is not like the previous SSL is broken again ho hum bugs. True. The fact that Mozilla is doing a review that might cause them to delist the worst CAs is more than we have seen in the past. However, if they delist only a few, the result will be that people will think that the rest of the CAs are just fine. If they delist a significant proportion, *that* will cause more discussion and concern among the non-security-geek populace than the current news because it will hit businesspeople in their pocketbooks. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Oddity in common bcrypt implementation
On Jun 29, 2011, at 4:49 AM, Peter Gutmann wrote: I realise it's fun to jump in and bikeshed the living daylights out of this, +1. i18n geeks do this all the time. but before we do that we'd really need to figure out whether the cure is worse than the disease. +1. When we first applied i18n to passwords, we argued long and hard about it because there were strong arguments on both sides. We ended up with yes we should do it and now can evaluate what came of that decision. For example my own code treats a password as an opaque string of bytes in whatever the local system's character set is. It's used all over the place, including CJK countries and other places whose character sets are about as far removed from ASCII as you can get. That would be the billion+ people who use the Arabic script for many different written languages. So far I've had exactly zero complaints about i18n or c18n-based password issues. And that's a very valuable data point. It weighs heavily against the developer problems we have seen with using stringprep in password preparation. In retrospect, I believe we made the wrong choice to go with process passwords with this complex algorithm, but I don't think we could have known that at the time. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Brute force attacks, explained
http://geekandpoke.typepad.com/geekandpoke/2011/06/simply-explained-brute-force-attack.html --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Oddity in common bcrypt implementation
And this discussion of ASCII and internationalization has what to do with cryptography, asks the person on the list is who is probably most capable of arguing about it but won't? [1] --Paul Hoffman [1] RFC 3536, and others ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Current state of brute-forcing random keys?
Greetings again. I am helping someone design a system that will involve giving someone a randomly-generated key that they have to type in order to unlock data that is private but not terribly valuable. Thus, we want to keep the key as short as practical to reduce typing and mis-typing, but long enough to prevent trivial brute-force attacks. The encryption will be AES-128 in CBC mode. What is the current state of brute-force attacks on AES-128 blobs? Are there recent results where we can estimate the cost of brute-forcing 64-bit and 80-bit keys? --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Current state of brute-forcing random keys?
On Jun 9, 2011, at 10:43 AM, Ian G wrote: On 10/06/11 3:14 AM, Paul Hoffman wrote: Greetings again. I am helping someone design a system that will involve giving someone a randomly-generated key that they have to type in order to unlock data that is private but not terribly valuable. Thus, we want to keep the key as short as practical to reduce typing and mis-typing, but long enough to prevent trivial brute-force attacks. The encryption will be AES-128 in CBC mode. What is the current state of brute-force attacks on AES-128 blobs? Are there recent results where we can estimate the cost of brute-forcing 64-bit and 80-bit keys? Not quite what you are asking for, but you could poke around here: http://www.keylength.com/en/3/ Poked, rejected. I want measurements from which I can derive my own recommendations. I don't see any recent measurements here. --Paul Hoffman ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Fwd: [gsc] Fwd: OpenBSD IPSEC backdoor(s)
At 7:06 PM -0600 12/16/10, Marsh Ray wrote: On 12/16/2010 04:46 PM, Steven Bellovin wrote: I've known Angelos Keromytis since about 1997; he's now a colleague of mine on the faculty at Columbia. I've known John Ioannidis -- the other name attached to that code -- for considerably longer. I've written papers with both of them. To anyone who knows them, the thought that either would insert a bug at the FBI's behest is, shall we say, preposterous. For the record, though I don't know him, I agree with that sentiment. If you don't know them, then your agreement or disagreement is kind of irrelevant. (I knew them both in that timeframe, and knew Steve pretty well, and agree with his assessment.) There were some wild accusations made and widely repeated, I'm trying my best to stick to facts and not direct accusations about anyone. You failed (miserably, in my opinion). In specific, you said: At 4:09 PM -0600 12/16/10, Marsh Ray wrote: How's this: OpenBSD shipped with a bug which prevented effective IPsec ESP authentication for a few releases overlapping the time period in question: http://code.bsd64.org/cvsweb/openbsd/src/sys/netinet/ip_esp.c.diff?r1=1.74;r2=1.75;f=h No advisory was made. The developer who added it, and the developer who later reverted it, were said to be funded by NETSEC http://monkey.org/openbsd/archive/misc/0004/msg00583.html I think there's more. I'm out of time to describe it right now, BBIAB. Which part of that even has a hint of not direct accusations about anyone? There was a need for facts, so I went diving into CVS logs and mailing list archives. This is some of the stuff I found that might fit the claims. I would be very reluctant to draw any conclusions for a long time. I see nothing in the message quoted above that indicates that reluctance. Possibly the thing which gets proven here is that even high-quality clean C code is very difficult to make provable statements about, even with the benefit of hindsight. No one here is asking for provable statements, just ones that are germane to the topic. I found a code change in the CVS log that might be relevant, here's the URL, does anyone agree is quite different than what you said in your message. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] NSA's position in the dominance stakes
At 8:47 PM +1000 11/16/10, James A. Donald wrote: On 2010-11-16 1:36 PM, Marsh Ray wrote: All I know is that it is said that one can do asymmetric crypto with elliptic curves using keys a bit shorter than RSA, but that those who do so sometimes end up paying ++$M. From my perspective, this is effectively equivalent to the algorithm having a rather severe form of security vulnerability. I don't think that elliptic curves are more patented or less patented than everything else. The proposition that there are unusual patent hazards looks like FUD to me. +1 Marsh: could you be more specific on which patents you think apply to normal use of ECDSA and ECDH? Or were you just saying because some company says they have patents, I believe them? For extra credit, please read draft-mcgrew-fundamental-ecc-03.txt and suggest where it might be wrong. --Paul Hoffman, Director --VPN Consortium ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
