Re: Dutch Transport Card Broken

2008-02-10 Thread James A. Donald

Steven M. Bellovin wrote:
 There's another issue: initial account setup.  [Even
 with SRP] people will still need to rely on
 certificate-checking for that.  It's a real problem at
 some hotspots, where Evil Twin attacks are easy and
 lots of casual users are signing up for the first
 time.

For banks and health care, initial account setup always
involves out of band communication, so certificate
checking not needed.

We need to build our security mechanisms to fit
characteristic human out of band security, rather than
trying to force humans to imitate computers.

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


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

2008-02-10 Thread Leichter, Jerry
| By the way, it seems like one thing that might help with client certs
| is if they were treated a bit like cookies.  Today, a website can set
| a cookie in your browser, and that cookie will be returned every time
| you later visit that website.  This all happens automatically.  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?
While trying to find something else, I came across the following
reference:

Title:   Sender driven certification enrollment system
Document Type and Number:  United States Patent 6651166
Link to this page:  http://www.freepatentsonline.com/6651166.html
Abstract:
A sender driven certificate enrollment system and methods of its
use are provided, in which a sender controls the generation of a
digital certificate that is used to encrypt and send a document
to a recipient in a secure manner. The sender compares
previously stored recipient information to gathered information
from the recipient. If the information matches, the sender
transfers key generation software to the recipient, which
produces the digital certificate, comprising a public and
private key pair. The sender can then use the public key to
encrypt and send the document to the recipient, wherein the
recipient can use the matching private key to decrypt the
document.

This was work done a Xerox.  I was trying to find a different report
at Xerox in response to Peter Gutmann's comment that certificate aren't
used because they are impractical/unusable.  Parc has done some wonderful
work on deal with those problems.  See:

http://www.parc.com/research/projects/usablesecurity/wireless.html

Not Internet scale, but in an enterprise, it should work.

-- Jerry

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


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

2008-02-10 Thread Anne Lynn Wheeler

re:
http://www.garlic.com/~lynn/aadsm28.htm#30 Fixing SSL

so lots of the AADS
http://www.garlic.com/~lynn/x959.html#aads

scenarios are that every place a password might appear, have
a public key instead.

for various of the cookie authentication operations ... also
think kerberos tickets. recent reference
http://www.garlic.com/~lynn/2008c.html#31 Kerberized authorization service

part of the scenario for cookie/ticket encryption ... involving
servers, is brute force attack on the server secret key. the cookie
instead of all encrypted data ... has some sort of client registration
value ... analogous to an account number or userid. the cookie caries the
registration value followed by the server encrypted data.  the
encryption part uses a derived key ... formed by combination of the
server's secret key and the client's registration value. these derived
key scenarios are also found in transit system operation (both
magstripe and memory chip) as well as financial transactions.

the issue then is initial registration ... the part where the user
chooses their userid (and/or the client registration value is
otherwise selected) and supplies a password (but in this case a public
key). m'soft and others have been using CAPTCHA to weed-out the
non-humans, but this has come under attacks. reference to recent news
items
http://www.garlic.com/~lynn/2008d.html#2 Spammer' bot cracks Microsoft's 
CAPTCHA


the ticket/cookie carries the clients public key (and whatever other
characteristics) ... which then can be used by the server(s) to
perform dynamic authentication (digital signing of some server
supplied, random data, countermeasure to replay attacks). this is in
lieu of server having to maintain the client account record ... ala a
RADIUS scenario where public key has been registered in lieu of a
password (some sort of online access to RADIUS account
records). various RADIUS public key in lieu of password postings:
http://www.garlic.com/~lynn/subpubkey.html#radius

the ticket/cookie scenario (with derived key encryption) is cross
between dynamic server-side account record data (say RADIUS
repository) and stale, static digital certificate scenario. as in the
transit gate operation, the ticket/cookie could also be retrieved,
decrypted, updated, re-encrypted, and returned as part of the
operation. initial server hand-shakes can include server sending some
random challenge data. The client returns the digital signature
and their previously obtained cookie. in the straight RADIUS public
key handshake scenario, just the digital signature and client
userid/account-number is returned since the rest of the cookie/ticket
equivalent info is online in the RADIUS account repository.

The straight RADIUS scenario would be to combine the server-side
random challenge data and combine it with the client registration
value (account number, userid) and whatever else the client-side
digital signing requires ... and return the userid/account-number
any other data and digital signature (i.e. server-side has to be
able to reconstruct what the client actually digitally signed
as part of verifying the digital signature). In the straight RADIUS
scenario, the public key (and any associated permissions, authorization,
etc) is obtained from the RADIUS repository. In cookie/ticket
scenario, it is obtained from the cookie/ticket appended to the
message.

The business process still has the initial registration phase
... where the original cookie is created (or in the RADIUS
scenario, where the userid definitiion is initially created) and the
public key is supplied (in lieu of a password).

This is also effectively the original certificateless pk-init scenario
for kerberos (aka public key in lieu of password)
http://www.garlic.com/~lynn/subpubkey.html#kerberos

The cookie scenario is standard client/server ... attempting
to eliminate the server having to retain the account
record on behalf of every client (as in either the RADIUS
and/or KERBEROS scenario). Encrypting of the cookie data
is standard ... although transit systems and financial transactions
have gone to derived key for the situation ... as countermeasure
to brute force attack on the infrastructure secret key.

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


Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

2008-02-10 Thread Ian G

Peter Gutmann wrote:

Victor Duchovni [EMAIL PROTECTED] writes:


While Firefox should ideally be developing and testing PSK now, without
stable libraries to use in servers and browsers, we can't yet expect anything
to be released.


Is that the FF devlopers' reason for holding back?  Just wondering... why not
release it with TLS-PSK/SRP anyway (particularly with 3.0 being in the beta
stage, it'd be the perfect time to test new features), tested against existing
implementations, then at least it's ready for when server support appears.  At
the moment we seem to be in a catch-22, servers don't support it because
browsers don't, and browsers don't support it because servers don't.



I would say that this would not hold the FF developers back, 
as they were definately capable of implementing TLS/SNI 
extension a year or two back, without any support from 
stable libraries in Apache httpd, Microsoft IIS, etc (still 
waiting...).


I'd also suggest that the TLS/SNI (which will apparently 
turn up one day in Apache) will have a much more dramatic 
effect on phishing than TLS-PSK/SRP ... because of the 
economics of course.  Lowering the barriers on all TLS use 
is far more important than making existing TLS use easier.


Of course, this is not a competition, as the effect adds, 
not competes.  The good thing is that we may actually get to 
see the effects of both fixes to TLS rollout at similar 
times.  In economics, it is a truism that we can't run the 
experiment, we have to watch real life, Heisenberg style, 
and this may give us a chance to do that.


Also, we can observe another significant factor in the mix: 
 the rollout of virtual machine platforms (xen and the 
like) is dramatically changed the economics of IP#s, these 
now becoming more the limiting factor than they were, which 
might also put more pressure on Apache ... to release 
earlier and more often.


iang

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


Re: Toshiba shows 2Mbps hardware RNG

2008-02-10 Thread Bill Stewart

At 07:02 PM 2/9/2008, Peter Gutmann wrote:

I've always wondered why RNG speed is such a big deal for anything but a few
highly specialised applications.  For security use you've got two options:
1. Use it with standard security protocols, in which case you need all of 128
   or so bits every now and then (and very rarely a few thousand bits for
   asymmetric keygen).


One obvious application I can think of is Diffie-Hellman session key generation
for web or email servers that handle lots of sessions.
Sure, you _could_ use PRNGs to generate the keys, with real RNG now and then,
but a fast RNG can help protect you against one popular threat model, which 
is auditors.


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


Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

2008-02-10 Thread Werner Koch
On Thu,  7 Feb 2008 16:37, [EMAIL PROTECTED] said:

 I don't have any idea why or why not, but all they can release now is
 source code with #ifdef openssl = 0.9.9  ... do PSK stuff ... #endif,

The last time I checked the Mozilla code they used their own crypto
stuff.  When did they switched to OpenSSL and how do they solve the
GPL/OpenSSL license incompatibility?


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.

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