Re: RNG using AES CTR as encryption algorithm
And while you are at it, please implement these test vectors and report to Niels Ferguson: http://blogs.msdn.com/si_team/archive/2006/05/19/aes-test-vectors.aspx Regards, Zooko - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
NSA intercepts led to a terrorist conviction
"Threat Level Privacy, Crime and Security Online NSA-Intercepted E-Mails Helped Convict Would-Be Bombers The three men convicted in the United Kingdom on Monday of a plot to bomb several transcontinental flights were prosecuted in part using crucial e-mail correspondences intercepted by the U.S. National Security Agency, according to Britain’s Channel 4. The e-mails, several of which have been reprinted by the BBC and other publications, contained coded messages, according to prosecutors. They were intercepted by the NSA in 2006 but were not included in evidence introduced in a first trial against the three last year. http://www.wired.com/threatlevel/2009/09/nsa-email/ has more. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: RNG using AES CTR as encryption algorithm
On Tue, Sep 1, 2009 at 11:28 PM, priya yelgar wrote: > I have implemented RNG using AES algorithm in CTR mode. > > To test my implementation I needed some test vectors. > > How ever I searched on the CSRC site, but found the test vectors for AES_CBC > not for AES CTR. > > Please can any one tell me where to look for the test vectors to test RNG > using AES CTR. The first thing that jumps out at me is that you're looking for a nebulous "Randon Number Generator" based on AES CTR mode (defined by SP 800-38A), and this is cast in the context of NIST's CSRC website (http://csrc.nist.gov/). Referencing NIST implies that you're looking for some kind Algorithm Certificate or FIPS 140-2 certification for a cryptographic module. If this is true, then you cannot just use 'AES CTR' to generate FIPS-approved random numbers. Instead, you need to use one of the approved RNG methods listed in FIPS 140-2 Annex C "Approved Random Number Generators". This includes several RNGs, including AES and 3DES variants based on ANSI X9.31, and SP 800-90. The closest thing to AES CTR is the CTR_DRBG defined in SP 800-90, which uses AES CTR for the random number generation, but also handles important things like distilling the initial entropy pool and periodic re-keying. Even if you're not intending to get FIPS 140-2 certification, I still highly recommend finding a good standard describing a 'recipe' for generating pseudo-random numbers, and follow the requirements for that. 'RNG using AES in CTR mode' is much different than 'Encryption using AES in CTR mode', and needs to be carefully handled accordingly. It's really easy to get things wrong outside of the AES CTR portion of the problem. You need to worry about justifying a particular entropy content of your true random source, which is then distilled down to create your key and nonce for the AES CTR portion of the RNG. This is not a task that is taken lightly. My personal recommendation is to go with the CTR_DRBG as defined in SP 800-90. You can easily find open source implementations of this algorithm, so I'm not even sure if you need to spend time implementing it. To test it, I recommend going through the process of getting an algorithm certificate from NIST. Cheers! Matt Ball, Chair, IEEE P1619 Security in Storage Working Group Staff Engineer, Sun Microsystems, Inc. 500 Eldorado Blvd, Bldg #5 BRM05-212, Broomfield, CO 80021 Work: 303-272-7580, Cell: 303-717-2717 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
On Wed, 09 Sep 2009 15:42:34 +1000 "James A. Donald" wrote: > Steven Bellovin wrote: > > Several other people made similar suggestions. They all boil down > > to the same thing, IMO -- assume that the user will recognize > > something distinctive or know to do something special for special > > sites like banks. > > Not if he only does it for special sites like banks, but if > "something special" is pretty widely used, he will notice when things > are different. We conducted a small-scale controlled user study -- it didn't work. > > > Peter, I'm not sure what you mean by "good enough to satisfy > > security geeks" vs. "good enough for most purposes". I'm not > > looking for theoretically good enough, for any value of "theory"; > > my metric -- as a card-carrying security geek -- is precisely "good > > enough for most purposes". A review of user studies of many > > different distinctive markers, from yellow URL bars to green > > partial-URL bars to special pictures to you-name-it shows that > > users either never notice the *absence* of the distinctive feature > > I never thought that funny colored url bars for banks would help, and > ridiculed that suggestion when it was first made, and said it was > merely an effort to get more money for CAs, and not a serious > security proposal > > The fact that obviously stupid and ineffectual methods have failed is > not evidence that better methods would also fail. > > Seems to me that you are making the argument "We have tried > everything that might increase CA revenues, and none of it has > improved user security, so obviously user security cannot be > improved." > Not quite. I'm not saying it "cannot be improved". I'm saying that controlled studies thus far have demonstrated none of the proposed methods have worked, against fairly straight-forward new attacks. And if we've learned one thing over the last ten years, it's that the attackers are as good as we are at what they do. There's money to be made and the market has worked its wonders: there is a demand for capable hackers, and they're making enough money to attract good people. What I am saying is twofold. First -- when you invent a new scheme, do a scientific test: does it actually help? Don't assume that because pure reason tells you it's a good idea, it actually is in the real world. Second -- you may very well be right that tinkering with the password entry mechanisms cannot succeed, because users are habituated to many different mechanisms and to login screens that regularly change because some VP in charge of publicity has decided that the site's web presence looks old-fashioned and needs to be freshened. In that case, we have to look at entirely different approaches. (How many different experiments will it take to convince people that you can't make gold by mixing chemicals together?) --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
Steven Bellovin wrote: Several other people made similar suggestions. They all boil down to the same thing, IMO -- assume that the user will recognize something distinctive or know to do something special for special sites like banks. Not if he only does it for special sites like banks, but if "something special" is pretty widely used, he will notice when things are different. Peter, I'm not sure what you mean by "good enough to satisfy security geeks" vs. "good enough for most purposes". I'm not looking for theoretically good enough, for any value of "theory"; my metric -- as a card-carrying security geek -- is precisely "good enough for most purposes". A review of user studies of many different distinctive markers, from yellow URL bars to green partial-URL bars to special pictures to you-name-it shows that users either never notice the *absence* of the distinctive feature I never thought that funny colored url bars for banks would help, and ridiculed that suggestion when it was first made, and said it was merely an effort to get more money for CAs, and not a serious security proposal The fact that obviously stupid and ineffectual methods have failed is not evidence that better methods would also fail. Seems to me that you are making the argument "We have tried everything that might increase CA revenues, and none of it has improved user security, so obviously user security cannot be improved." - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: RNG using AES CTR as encryption algorithm
David Johnston writes: >Convincing yourself that you have implemented AES-CTR correctly usually >involves first checking that your AES-ECB is correct, then putting the output >of you counter construction into some other known good AES-CTR implementation >and comparing the results with your implementation. I was just going to reply with a variation of this, if you're implementing a full protocol that uses AES-CTR (or any algorithm/mode for that matter), find other implementations that do it too and make sure that you can talk to them. In theory everyone could end up implementing it wrong, but that's somewhat unlikely. (This has already caught AES-CTR implementation bugs in the past, for example one particular version of OpenSSL 0.9.8 got AES-CTR keying wrong and it was noticed when SSH users couldn't connect to OpenSSH servers using this mode). Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: "Fed's RFIDiocy pwnd at DefCon"
On Sep 4, 2009, at 4:24 PM, Matt Crawford wrote: ". . . federal agents at the conference got a scare on Friday when they were told they might have been caught in the sights of an RFID reader. The reader, connected to a web camera, sniffed data from RFID- enabled ID cards and other documents carried by attendees in pockets and backpacks as they passed a table where the equipment was stationed in full view" I told them so... http://csrc.nist.gov/groups/SNS/piv/documents/FIPS201-Public-Comments/Fermilab-Computer-Security.pdf Remember: Before it's actually happened, any discussion is just reckless speculation, rumor-mongering, or worse. After it's actually happened, it's either (a) not a real issue; (b) a major new attack that could not have been foreseen but that will be dealt with immediately by top people. Top people. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
