Re: Fixing SSL (was Re: Dutch Transport Card Broken)
On Feb 11, 2008, at 8:28 AM, Philipp Gühring wrote: I had the feeling that Microsoft wants to abandon the usage of client certificates completely, and move the people to CardSpace instead. But how do you sign your emails with CardSpace? CardSpace only does the realtime authentication part of the market ... We (Morgan Stanley) were able to pressure them into a rapid fix, and they have committed to delivering it in SP1. Keep your fingers crossed. If anyone needs more information how to upgrade your Web-based CA for IE7: http://wiki.cacert.org/wiki/IE7VistaSource Step (2), On Vista you have to add this website to the list of trusted sites in the internet-settings. can be quite unpalatable. Depending on your customers' situations, an alternative might be more palatable: Generate the key and deliver a PKCS#12. This depends on whether you believe in the non-repudiation fairy or not -- or more accurately, whether you're already assuming the repudiation risk. -wps - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Toshiba shows 2Mbps hardware RNG
|SAN FRANCISCO -- Toshiba Corp. has claimed a major breakthrough in |the field of security technology: It has devised the world's |highest-performance physical random-number generator (RNG) |circuit. | |The device generates random numbers at a data rate of 2.0 megabits |a second, according to Toshiba in a paper presented at the |International Solid-State Circuits Conference (ISSCC) here. | | I'm wondering if they've considered the possibility of EMI skewing the | operation of the device, or other means of causing the device to | genearate less than completely random numbers. I wonder if they considered the possibility that the device will be destroyed by a static discharge? It's one thing to criticize a design about which you know nothing on the basis of a broad, little-known or brand new, attack. But the fact that EMI can skew devices has been known for years. Hardware that may need to work in (deliberately or otherwise) high-EMI environments has to be appropriately designed and shielded (just as devices have for years been protected against static discharge through multiple layers of protection, from the chip design itself through ground straps for people handling them). I know nothing at all about Toshiba or its designers. Do you know something that makes you think they are so incompetent that they are unaware of well-known issues that arise in the design of the kinds of devices they work with? | It is certainly an interesting device; I think this would find | considerable use in communication infrastructure and high-bandwidth | applications. As someone else mentioned, generating a single, random, | 128 bit seed is not too difficult with current technology, but it | doesn't address the issue that often times you want more than just a | single key. One of the problems with the Linux random number generator | is that it happens to be quite slow, especially if you need a lot of | data. | | Some potential uses: | 1.) Secure file erasure. Why? Writing hard random values over the previous data is neither more nor less secure than writing zeroes, unless you descend to the level of attacking the disk surface and making use of remnance effects. Once you do that ... it's still not clear that writing random values is better or worse than writing all zeroes! (As Peter Gutmann showed years ago, there are *highly technology-specific sets of patterns* that do a better job than all zeroes, or all ones, or whatever. There's little reason to believe that a random set of bits is good for much of anything in this direction.) If you're concerned about someone distinguishing between erased data and real data ... if the real data is unencrypted, then the game is over anyway. If the real data is encrypted, you want the erased data to look exactly as random as the encrypted real data. That is, if you believe that your AES-encrypted (say) data can be distinguished from random bits without knowning the key, then if you fill the erased blocks with *really* random bits, the distinguisher will tell you exactly where the real data is! Better to use exactly the same encryption algorithm to generate your random erasure pattern. BTW, even pretty average disks these days can write 50 MB/second, or 200 times the rate at which this device can generate random bits. | 2.) OTP keygen for those _really_ high security applications. OK. | 3.) Faster symmetric keyset generation. You know, when you need to | build 32k keys... OK, though given the computational overhead involved in generating symmetric keys, it's hard to see the random number generation as the throttling factor. | 4.) Random seeding of communication packets. If you're talking about inserting fillers to thwart traffic analysis, the same argument as for erasing disk blocks: Either you believe your encrypted packets can't be distinguished from random, in which case you don't need the generator; or you are afraid they *can* be, in which case you'd better not use the generator! | There used to be (maybe still) a TCP spoofing exploit that relied on the | timing of packets; there are also various de-anonymization attacks based | on clock skew. With a chip like this, you could add a small, random | number to the timestamp, or even packet delay, and effectively thwart | such attacks. Such systems need high-bandwidth, random number | generators. I don't buy it. First off, the rates are pretty low - how many packets per second do you send? Second, the attacks involved are probably impossible to counter using software, because the timing resolutions are too small. Maybe you can build random jitter into the hardware itself - but that brings in all kinds of other issues. (The hardware is, of course, *already* introducing random jitter - that's the basis of the attack. Just adding more without getting rid of the bias that enables the attacks is little help; at worst, it just requires the attacker to take more samples to average away the
RE: Open source FDE for Win32
On 11 February 2008 04:13, Ali, Saqib wrote: I installed TrueCrypt on my laptop and ran some benchmark tests/ Benchmark Results: http://www.full-disk-encryption.net/wiki/index.php/TrueCrypt#Benchmarks Thanks for doing this! Cons: 1) Buffered Read and Buffered Transfer Rate was almost halved after TrueCrypt FDE was enabled :-(. Yes, to almost the exact same rate as sequential reads. I'm guessing it simply doesn't implement look-ahead decryption. It might even be a positively good idea to not decrypt anything until you're specifically asked. 3) The initial encryption of the 120 GB HDD took 2 hours. You think a 1GB/min encryption rate is so slow as to count as a con? I think that's fairly reasonable. My lightly loaded AMD64x2 box just took 48s to copy a 584MB file from one place to another on a first trial, and between 26s and 39s on 'hot' retests. Or are you suggesting that it could encrypt each block OTF when it's first accessed, or run the encryption in the background while the system was still live, instead of converting the whole drive in one big bite? cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Open source FDE for Win32
Hello Dave, On 13/2/2008 21:26, Dave Korn wrote: Or are you suggesting that it could encrypt each block OTF when it's first accessed, or run the encryption in the background while the system was still live, instead of converting the whole drive in one big bite? Encrypting blocks only when they are used can be risky in terms of false sense of security. There is basically no way for you to tell what is left out there. Encrypting the drive while the system is live is what TC currently does. Encryption runs in the background while you can do other things (though much slower). Hagai. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Toshiba shows 2Mbps hardware RNG
Crawford Nathan-HMGT87 writes: One of the problems with the Linux random number generator is that it happens to be quite slow, especially if you need a lot of data. /dev/urandom is blindingly fast. For most applications, that's all you need. (Of course there are many Linux applications that use /dev/random simply because they don't know any better, but that's a pretty weak argument for a fast hardware RNG.) A fast hardware RNG could be useful but I'm not convinced high speed matters all that much for most applications. Grab 128 bits for a hardware RNG, feed it through AES-CTR to generate an unending stream of pseudorandom bits -- that's good enough for most applications. (Yes, I know there are exceptions where pseudorandomness is not enough. But even the exceptions rarely need true random numbers at a rate of several Mbps.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Toshiba shows 2Mbps hardware RNG
- Original Message - From: Pat Farrell [EMAIL PROTECTED] To: Subject: Re: Toshiba shows 2Mbps hardware RNG Date: Sun, 10 Feb 2008 17:40:19 -0500 Perry E. Metzger wrote: [EMAIL PROTECTED] (Peter Gutmann) writes: I've always wondered why RNG speed is such a big deal for anything but a few highly specialised applications. Perhaps it isn't, but any hardware RNG is probably better than none for many apps, and they've managed to put the whole thing in a quite small bit of silicon. The speed is probably icing on the cake. One of the benefits of speed is that you can use cleanup code to control bias. Carl Ellison put some out on his website last century. It is a HUGE win for designing a crypto system to have a really fast (and good) HW RNG. Being able to generate 10-20,000 AES keys per second means that you can engineer things that were impossible to do otherwise. You can generate as many keys as you like, throw away keys after one time use, treat them as ephemeral authentication keys (say give a few million or so to a user), etc. Or you could hand a sender 10 MBytes (less than a minute to generate), which then can be used to create billions of keys (say using Ueli Maurer's Bounded Storage Model). The sender could then use each key to uniquely encrypt (AES CTR) each message of a series of messages or packets to a receiver (AES key setup is fast). No need for an IV or worrying about message ordering (each one has a key id), or even the compromise of a key or two. Randomness is the most fundamental underpinning of a crypto system and having lots of it on demand is really fabulous to have in our system security design tool box. - Alex - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Toshiba shows 2Mbps hardware RNG
David G. Koontz [EMAIL PROTECTED] writes: Military silicon already has RNG on chip (e.g. AIM, Advanced INFOSEC Machine, Motorola), That's only a part of it. Military silicon has a hardware RNG on chip alongside a range of other things because they know full well that you can't trust only a hardware/noise-based RNG, there are too many variables and too many things that can go wrong with that single source. That's why I was sceptical of the we've solved the RNG problem with our custom hardware claim, they've created one possible source of input but not a universal solution. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
House o' Shame: Amtrak
Steve Bellovin documents on his blog a recent attempt by Amtrak to teach its customers to be phishing victims: http://www.cs.columbia.edu/~smb/blog/2008-02/2008-02-13.html My comments: Phish someone, and you inconvenience him for a week. Teach a man to be phished, and you screw him for the rest of his life. --me I got the exact same email from Amtrak. It is pretty disappointing to me, but sadly not surprising, that big organizations are still conditioning their users to become fraud victims. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Imagine if a website could instruct your browser to transparently generate a public/private keypair for use with that website only and send the public key to that website. Then, any time that the user returns to that website, the browser would automatically use that private key to authenticate itself. For instance, boa.com might instruct my browser to create one private key for use with *.boa.com; later, citibank.com could instruct my browser to create a private key for use with *.citibank.com. By associating the private key with a specific DNS domain (just as cookies are), this means that the privacy implications of client authentication would be comparable to the privacy implications of cookies. Also, in this scheme, there wouldn't be any need to have your public key signed by a CA; the site only needs to know your public key (e.g., your browser could send self-signed certs), which eliminates the dependence upon the third-party CAs. Any thoughts on this? You don't have to imagine this. It is exactly how Infocard (the generic name of the technology of which Microsoft's CardSpace is one implementation of one component) works in its most common mode (the personal or self-issued card). It has lots of other benefits as well even in this mode (user-managed attributes, graphical UI) as well as other modes to support identity providers (managed cards). Lest you think that this is Microsoft-only, be assured that there is a large community building implementations for many other platforms and systems. OSIS (http://osis.idcommons.net/) is the prime venue for people to work on interoperability across the spectrum of implementations. There's a big interop event coming up at the RSA conference in April. If you'd like to help make your scenario a pervasive reality, check it out. - RL Bob - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Is anyone aware of any third-party usability studies on CardSpace, OpenID, ...?). I'm not. It would be a good opportunity for security usability researchers to contribute though. [0] I'm not sure whether putting CardSpace and Liberty in such close proximity in the above line was a good idea. If your monitor starts smoking due to the friction generated, please cutpaste one of the two elsewhere. Actually lots of Liberty and WS/Infocard/etc people are working on interop scenarios, see: http://projectconcordia.org/index.php/Main_Page - RL Bob - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
