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] RSA recommends against use of its own products.
On 24 September 2013 17:01, Jerry Leichter wrote: > On Sep 23, 2013, at 4:20 AM, ianG 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: [Cryptography] The hypothetical random number generator backdoor
On 23 September 2013 01:09, Phillip Hallam-Baker 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] What TLS ciphersuites are still OK?
On 10/09/13 15:58, james hughes wrote: On Sep 9, 2013, at 9:10 PM, Tony Arcieri mailto:basc...@gmail.com>> wrote: On Mon, Sep 9, 2013 at 9:29 AM, Ben Laurie mailto:b...@links.org>> wrote: And the brief summary is: there's only one ciphersuite left that's good, and unfortunately its only available in TLS 1.2: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 A lot of people don't like GCM either ;) Yes, GCM does have implementation sensitivities particularly around the IV generation. That being said, the algorithm is better than most and the implementation sensitivity obvious (don't ever reuse an IV). I think the difficulty of getting a fast constant time implementation on platforms without AES-NI type hardware support are more of a concern. ___ 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]
"usable security" at www.usable.com
www.usable.com has launched a new password management service intended to make it easy to login to participating web sites. However, I don't see any details of the protocols or algorithms. In particular, I don't see any mention of whether or not the system even attempts to prevent people with access to the servers at usable.com from having the ability to impersonate users of the service. --apb (Alan Barrett) - 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]
"Verified by VISA" looks phishy
I tried to renew a domain name registration and pay by credit card,
and encountered a nasty problem with (some implementations of?) a
service called "Verified by VISA", which is nominally intended to secure
Internet credit card transactions.
The domain name registrar asked what domains I wanted to renew, and
redirected my browser to a third party credit card payment service. So
far so good: the domain name registrar told me "you will be redirected
to ${PAYMENT_SERVICE}."
The payment service confirmed the amount to be paid, asked
for my credit card number and a few other details, and told
me that I would be redirected to my bank to confirm my PIN
number. But I was not redirected to my bank, I was redirected to
https://${some_string_resembling_the_name_of_my_bank}.bankserv.co.za.
The bankserv.co.za web site claimed to be part of a system called
"Verified by VISA", and asked me for the PIN that I use for ATM
transactions with my credit card.
The problems with this include:
1) Locating the verification web site at a domain name not associated
with the bank looks phishy.
2) Telling customers not to worry about (1) trains them to be more
vulnerable to phishing.
3) Providing both the ATM PIN and the card number to the verification
web site enables fraud by insiders, is possibly a violation of the
cardholder's contractual requirement to keep the PIN secret, and is
a violation of the ordinary prudent desire to keep the PIN secret.
4) Telling customers not to worry about (3) trains them to take less
good care of their PIN.
I phoned my bank, and talked to somebody who could not understand
the problem: "See the lock icon? That means its secure." I have
subsequently tried to explain the problem to the bank via email. I
asked them to: use the bank's domain name, not bankserv.co.za; use a
unique PIN instead of re-using the ATM PIN; use one time passwords
instead of PINs. I haven't had a response to my suggestions.
--apb (Alan Barrett)
-
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: "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. 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: 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: 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: Researchers Combat Terrorists by Rooting Out Hidden Messages
On Tue, 2005-02-01 at 23:21 -0800, Steve Schear wrote: > At 02:07 PM 2/1/2005, Tyler Durden wrote: > > >Counter-stego detection. > > > >Seems to me a main tool will be a 2-D Fourier analysis...Stego will > >certainly have a certain "thumbprint", depending on the algorithm. Are > >there certain images that can hide stego more effectively? IN other words, > >these images should have a lot of spectral energy in the same frequency > >bands where Stego would normally show. > > Images that ideal for hiding secret messages using stego are those that by > default contain stego with no particular hidden content. A sort of Crowds > approach to stego. If you really want to send secret messages, just send it in the chaff in spam. Everyone is programmed to ignore it or filter it out. -- "When a student reads in a math book that there are no absolutes, suddenly every value he's been taught is destroyed. And the next thing you know, the student turns to crime and drugs." - Mel Gabler - Censor - 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, Bill Stewart wrote: > The reason it's partly a cryptographic problem is forgeries. > Once everybody starts whitelisting, spammers are going to > start forging headers to pretend to come from big mailing lists > and popular machines and authors, so now you'll not only > need to whitelist Dave Farber or Declan McCullough if you read their lists, > or Bob Hettinga if you're Tim (:-), you'll need to verify the > signature so that you can discard the forgeries that > pretend to be from them. > > You'll also see spammers increasingly _joining_ large mailing lists, > so that they can get around members-only features. This has already happened: Krazy Kevin pulled this stunt 5 years ago on at least one list I was on, joining the list to harvest the most common posters, then spamming using them as sender envelopes after he'd been kicked off. > At least one large mailing list farm on which I've joined a list > used a Turing-test GIF to make automated list joining difficult, ...discrimination against blind users - this is legally actionable in several countries. There is a blind group in the UK taking action against a number of companies for this and the Australian Olympic committee ended up being fined several million AU$ for the same offence in 1999. > and Yahoo limits the number of Yahoogroups you can join in a day, > but that's the kind of job which you hire groups of Indians > or other English-speaking third-world-wagers to do for you. To underscore that point, I've _watched_ cybercafes full of SE asians(*) doing exactly this kind of thing for the princely sum of US$5/day - twice the average wage of the area, even after the cafe fees were deducted. (*) Philippines and east Malaysia. AB - 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]
