Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
On 02/10/13 18:42, Arnold Reinhold wrote: On 1 Oct 2013 23:48 Jerry Leichter wrote: The larger the construction project, the tighter the limits on this stuff. I used to work with a former structural engineer, and he repeated some of the bad example stories they are taught. A famous case a number of years back involved a hotel in, I believe, Kansas City. The hotel had a large, open atrium, with two levels of concrete skyways for walking above. The skyways were hung from the roof. As the structural engineer specified their attachment, a long threaded steel rod ran from the roof, through one skyway - with the skyway held on by a nut - and then down to the second skyway, also held on by a nut. The builder, realizing that he would have to thread the nut for the upper skyway up many feet of rod, made a minor change: He instead used two threaded rods, one from roof to upper skyway, one from upper skyway to lower skyway. It's all the same, right? Well, no: In the original design, the upper nut holds the weight of just the upper skyway. In the m o di fied version, it holds the weight of *both* skyways. The upper fastening failed, the structure collapsed, and as I recall several people on the skyways at the time were killed. So ... not even a factor of two safety margin there. (The take-away from the story as delivered to future structural engineers was *not* that there wasn't a large enough safety margin - the calculations were accurate and well within the margins used in building such structures. The issue was that no one checked that the structure was actually built as designed.) This would be the 1981 Kansas City Hyatt Regency walkway collapse (http://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse) Which says of the original design: Investigators determined eventually that this design supported only 60 percent of the minimum load required by Kansas City building codes.[19], though the reference seems to be a dead link. (And as built it supported 30% or the required minimum.) So even if it had been built as designed, the safety margin would not have been well within the margins used in building such structures. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The hypothetical random number generator backdoor
On 23 September 2013 01:09, Phillip Hallam-Baker hal...@gmail.com wrote: 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. Are you talking about http://en.wikipedia.org/wiki/Dual_EC_DRBG#Controversy or hypothetical RNGs in general, maybe not even EC based? 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. For an RSA key exchange without ephemeral DH, the _client_ generates the premaster secret from which the session key is derived. However, ClientHello and ServerHello both contain random numbers sent before key exchange. If you are intercepting traffic, you have a nonce generated shortly before the session key generation for every key exchange, even without starting sessions of your own. Possibly you can use the client nonces to reduce the search space for the session keys (and if it's an RC4 session key, maybe the biases in RC4 help?). (Or, if using DHE, maybe it helps find DH private keys.) And possibly if you have server nonces based on the same PRNG seed as was used when the RSA key was generated, you can search for the RSA key. -- alan.bragg...@gmail.com http://www.chiark.greenend.org.uk/~armb/ ___ 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 24 September 2013 17:01, Jerry Leichter leich...@lrw.com wrote: On Sep 23, 2013, at 4:20 AM, ianG i...@iang.org wrote: ... But they made Dual EC DRBG the default ... At the time this default was chosen (2005 or thereabouts), it was *not* a mistake. https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html Problems with Dual_EC_DRBG were first described in early 2006 With hindsight, it was definitely a mistake. The questions are whether they could or should have known it was a mistake at the time and whether the NSA played any part in the mistake, and whether they should have warned users and changed the default well before now. -- alan.bragg...@gmail.com http://www.chiark.greenend.org.uk/~armb/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: Lava lamp random number generator made useful?
On Tue, 2008-09-23 at 00:09 -0700, Jon Callas wrote: A cheap USB camera would make a good source. The cheaper the better, too. Pull a frame off, hash it, and it's got entropy, even against a white background. No lava lamp needed. I sort of agree, but I feel cautious about recommending that people use their holiday snaps. And then post them on line... if you see where I am going :) But it is a good suggestion. That's not at all what I suggested. There are so many ways that one can creatively screw up reasonable cryptographic advice that I don't think it's worth bothering with. The point is that if you take a cheap 640x480 (or 320x240) webcam and point it against a photographic grey card, there's going to be a lot of noise in it, and this noise is at its bottom quantum in nature. Thus, there's a lot of entropy in that noise. Photographic engineers work *hard* to remove that noise, and you pay for a lack of noise. I'm willing to bet that if I give you hashes of frames, knowing this process, you can't get pre-images. I'll bet that you can't get pre- images even if I let you put a similar camera next to the one I'm using. In short, I'm willing to bet that a cheap camera is a decent random number source, even if you try to control the image source, to the tune of 128-256 bits of entropy per frame. No lava lamps are needed, no weird hardware. Just use the noise in a CCD. Another option would be to use noise. If you have a webcam, you also have some sort of sound input usually. Crappy microphones will give you all sorts of hashable input. (My non-webcam enabled laptop has two tiny microphones above the screen. It would be good to put them to some use...) And is it every truly quiet? Not certain how long of a sample you would need. I suspect not that long. To generate a random seed, please scream at your computer for 30 seconds. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Question on export issues
On Sun, 2007-12-30 at 08:30 -0500, Richard Salz wrote: In my personal experience, if you are developing a mass-market item with conventional crypto (e.g., SSL, S/MIME, etc ) then it is fairly routine to get a commodity export license which lets you sell globally. Disclaimers abound, including that I'm not a lawyer and certainly don't speak for IBM. My question was more on the lines of what gets rejected, not what does it take to do it. Is there some technology that they are so afraid of that they still won't let it ship or does it just matter who you are, not what it is? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Question on export issues
What are the rules these days on crypto exports. Is a review still required? If so, what gets rejected? Just wondering... I have people at work ask me what the rules are and I have not kept up with them. If GnuPG can ship, what gets rejected? Is there some magic cryptotech I am not aware of? (Or is it just theater at this point?) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More on in-memory zeroisation
On Tue, 11 Dec 2007, Leichter, Jerry wrote: You can almost, but not quite, get the desired effect for memory zero- ization with volatile. I thought that this was guaranteed to work: volatile char buf[SIZE]; /* ... do stuff with buf ... */ memset(buf, 0, sizeof(buf)); --apb (Alan Barrett) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: using SRAM state as a source of randomness
On Tue, 18 Sep 2007, James A. Donald wrote: Using SRAM as a source of either randomness or unique device ID is fragile. It might well work, but one cannot know with any great confidence that it is going to work. It might work fine for every device for a year, and then next batch arrives, and it completely fails. Worse still, it might work fine on the test batch, and then on the production run fail in ways that are subtle and not immediately obvious. And you might get better results from cheaper ram which may fail more often. (Adding a different sort of randomness.) I have a friend who is a hardware engineer who is preparing a talk on just this sort of issue with the state of DRAM chips. It will be interesting to see what he says. (For those people in Portland, OR, it will be given at the PLUG Advanced Topics meeting sometime early next year.) -- Never trust a queue structure designed by a cryptographer. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How the Greek cellphone network was tapped.
On Mon, 9 Jul 2007, Florian Weimer wrote: * Ian Farquhar: Crypto has been an IP minefield for some years. With the expiry of certain patents, and the availability of other unencumbered crypto primitives (eg. AES), we may see this change. But John's other points are well made, and still valid. Downloadable MP3 ring tones are a selling point. E2E security isn't (although I've got to wonder about certain teenage demographics... :) It's also an open question whether network operators subject to interception requirements can legally offer built-in E2E encryption capabilities without backdoors. Makes me wonder how this will effect the OpenMoko phone if someone builds an encryption layer for it. (OpenMoko is a totally open sourced phone.) I am still trying to convince my wife to let me get a developers kit for it. -- ANSI C says access to the padding fields of a struct is undefined. ANSI C also says that struct assignment is a memcpy. Therefore struct assignment in ANSI C is a violation of ANSI C... - Alan Cox - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Hamiltonian path as protection against DOS.
On Tue, 15 Aug 2006, Bill Stewart wrote: Crypto is usually about economics and scalability. If you're doing this for DOS/DDOS prevention, you don't need the NP-completeness perfection you get from Hamiltonian paths or similar problems - SHA is fine, or any other hash that's quick to verify and hard to reverse. Even MD5 is probably still ok... Calculating any of the hashes probably takes less time than handling the packets does. It's almost certainly better for you if they harass you by sending you bogus SHA pieces that you can process quickly than bogus DH pieces that take you a while, and if it's not too distributed an attack, you can also blacklist senders IP addresses. But if the packets are forged, wouldn't that turn it into a different kind of DOS? If I can get you to blacklist Alice by sending n forged attack packages, then my DOS succeeded, if my goal is to deny a connection between you and Alice. -- I want to live just long enough to see them cut off Darl's head and stick it on a pike as a reminder to the next ten generations that some things come at too high a price. I would look up into his beady eyes and wave, like this... (*wave*!). Can your associates arrange that for me, Mr. McBride? - Vir Flounder Kotto, Sr. VP, IBM Empire. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypto to defend chip IP: snake oil or good idea?
On Tue, 25 Jul 2006, Perry E. Metzger wrote: EE Times is carrying the following story: http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=190900759 It is about attempts to use cryptography to protect chip designs from untrustworthy fabrication facilities, including a technology from Certicom. Unlike ordinary DRM, which I think can largely work in so far as it merely provides a (low) barrier to stop otherwise honest people from copying something they find inexpensive in the first place, it seems to me that efforts like this are doomed. It is one thing if you're just trying to keep most people honest about something that doesn't cost much money, and another if you're trying to protect something worth millions of dollars from people with extremely sophisticated reverse engineering equipment. In particular, people who operate fabs are also in possession of exquisitely good equipment for analyzing the chips they've made so they can figure out process problems, and the key injection equipment Certicom is making could easily be suborned as well. I'd be interested in other people's thoughts on this. Can you use DRM to protect something worth not eight dollars but eight million? This has already been attempted with video game machines back in the 80s and with consoles like the X-Box more recently. In both cases, the encryption made it more difficult, but not impossible. There seems to be this idea that if we just use enough DRM, or enough encryption, we can overcome its weaknesses. It is like saying if we wish for something hard enough we can overcome the laws of nature. (And if it didn't happen, we did not wish hard enough.) But enough about US foreign policy... -- I want to live just long enough to see them cut off Darl's head and stick it on a pike as a reminder to the next ten generations that some things come at too high a price. I would look up into his beady eyes and wave, like this... (*wave*!). Can your associates arrange that for me, Mr. McBride? - Vir Flounder Kotto, Sr. VP, IBM Empire. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NSA knows who you've called.
On Fri, 12 May 2006, [EMAIL PROTECTED] wrote: alan writes: -+-- | | Probably because most Americans believe they are being spied on | anyways. (And have for a very long time.) | Au contraire', it is precisely what, for example, my spouse would say: I live a decent life and have nothing to hide. I ask people who say they have nothing to hide for their credit card numbers. Everyone has something to hide. The point is that you do not have to have done *anything* to be worried. How do you know that your name is not a known alias of some evil nasty terrorist who buggers FBI agents in his spare time? As this and all security-related lists are composed of people who are off-center when it comes to risk, it is us what be the outliers in the distribution and in no way are our various paranoias widely shared. The question is should they be?. -- Waiter! This lambchop tastes like an old sock! - Sheri Lewis - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NSA knows who you've called.
On Fri, 12 May 2006, [EMAIL PROTECTED] wrote: Perry E. Metzger writes: -+ | | And a personal note to you all: | | Let me again remind people that if you do not inform your elected | representatives of your displeasure with this sort of thing, | eventually you will not be in a position to inform them of your | displeasure with this sort of thing. | Perry, While I agree with you, the public does not, so far as I can tell, find itself willing to risk insecurity for the benefit of preserving privacy, as this article in today's Boston Globe would tend to confirm. http://www.boston.com/news/nation/articles/2006/05/12/most_put_security_ahead_of_privacy/ Most put security ahead of privacy (By Bruce Mohl, Globe Staff) Mark Jellison, a Verizon customer in Quincy, isn't fazed that his phone company may have turned over his calling records and those of millions of others to the National Security Agency as part of an effort to thwart terrorism. snip Probably because most Americans believe they are being spied on anyways. (And have for a very long time.) I find it interesting that the question is always about fighting terrorism. I am willing to bet you would get different answers if the question was phrased as Should a president be allowed to carry out massive wiretaps to spy on his political enemies? I have seen NO proof that this spying was limited, or even directed towards, terrorists. (Unless Democrats, peace activists, eco-freaks, hackers, and the like are now considered Terrorists.) Since there is no oversight allowed, we must assume that this effort has more to do with rooting out and destroying threats to the President than it does to actual threats to the security of the country. -- Waiter! This lambchop tastes like an old sock! - Sheri Lewis - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ID theft -- so what?
On Fri, 22 Jul 2005, Jerrold Leichter wrote: The banks, operating through the clearing agents, could if they wished impose a requirement on the way names appear in billing statements, regardless of how the names appear on contracts. Alternatively, they could at least require that an end-user-familiar name be made available in whatever database records all merchants, which the banks obviously have access to. A bank once told me that it was impossible for them to convert from an unintelligible name on a credit card statement into any other kind of name whatsoever (and certainly not into an end-user-familiar name), and impossible for them to show me a copy of any document whatsoever that might be related to the charge; however, they said that if I repudiated the charge, then they could get a copy of the voucher or other documents. So I repudiated the charge, but the bank was still unable or unwilling to show me the promised copies of relevant documents. The merchant eventually contacted me about the repudiated charge. --apb (Alan Barrett) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Financial identity is *dangerous*? (was re: Fake companies, real money)
On Sat, 23 Oct 2004, Aaron Whitehouse wrote: Oh, and make it small enough to fit in the pocket, put a display *and* a keypad on it, and tell the user not to lose it. How much difference is there, practically, between this and using a smartcard credit card in an external reader with a keypad? Aside from the weight of the 'computer' in your pocket... The risks of using *somebody else's keypad* to type passwords or instructions to your smartcard, or using *somebody else's display* to view output that is intended to be private, should be obvious. --apb (Alan Barrett) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [camram-spam] Re: Microsoft publicly announces Penny Black PoW postage project
On Tue, 30 Dec 2003, Eric S. Johansson wrote: But using your spam size, , the slowdown factor becomes roughly 73 times. So they would need 73 machines running full tilt all the time to regain their old throughput. Believe me, the professionals have enough 0wned machines that this is trivial. On the flipside, it means the machines are burned faster. unfortunately, I think you making some assumptions that are not fully warranted. I will try to do some research and figure out the number of machines compromised. The best No. I had seen to date was about 350,000. It's at least an order of magnitude higher than this, possibly 2 orders, thanks to rampaging worms with spamware installation payloads compromising cablemodem- and adsl- connected Windows machines worldwide. AB - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
