Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-14 Thread Bill Squier


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

2008-02-14 Thread Leichter, Jerry
|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

2008-02-14 Thread Dave Korn
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

2008-02-14 Thread Hagai Bar-El

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]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-14 Thread Peter Gutmann
Philipp =?iso-8859-1?q?G=FChring?= [EMAIL PROTECTED] writes:

I had the feeling that Microsoft wants to abandon the usage of client
certificates completely, and move the people to CardSpace instead.

While there's an obvious interpretation of that (Microsoft want to lock
everyone into CardSpace), there's a second interpretation that's equally
likely: After  10 years of effort and getting almost exactly nowhere with
client certs, Microsoft are moving on to something more likely to succeed
(actually I have no idea how workable CardSpace is since I don't think
anyone's done any usability studies on it, but I doubt it's more unworkable
than client certs.  Is anyone aware of any third-party usability studies on
CardSpace, OpenID, ...?).

But how do you sign your emails with CardSpace?

Does anyone care that you can't sign your emails with CardSpace?

(I could post my standard reference on this here again :-).  The unwashed
masses don't even know what signed email is, let alone care about using it.  I
know that there are assorted corporates and so on that are still keen on email
signing, but they can keep playing with PKI for that.  CardSpace/Liberty/
OpenID/SAML/whatever[0] should handle the rest.

Eventually.

Peter.

[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.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Toshiba shows 2Mbps hardware RNG

2008-02-14 Thread David Wagner
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

2008-02-14 Thread alex

 - 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

2008-02-14 Thread Peter Gutmann
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

2008-02-14 Thread Perry E. Metzger

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)

2008-02-14 Thread RL 'Bob' Morgan


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)

2008-02-14 Thread RL 'Bob' Morgan


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]