Re: Attacks against GOST? Was: Protocol Construction

2009-08-06 Thread Joseph Ashwood

My apologies for the delay, I had forgotten the draft message.

--
From: Alexander Klimov alser...@inbox.ru
Subject: Attacks against GOST? Was: Protocol Construction


On Sun, 2 Aug 2009, Joseph Ashwood wrote:

 So far, evidence supports the idea that the stereotypical Soviet
 tendency to overdesign might have been a better plan after all,
 because the paranoia about future discoveries and breaks that
 motivated that overdesign is being regularly proven out.

And that is why Kelsey found an attack on GOST


Do you want to say that the GOST (28147-89) block cipher is broken? I
have never heard of an attack against it that is faster than the
exhaustive search.


I just said there are attacks, the situation is open for interpretation 
because of the nature of the attacks and the unknown S-box. Kelsey and 
Schneier published the first related key attack in 1996, in 1997 Kelsey 
enhanced the attack. My point was that the proposed method of boosting 
security (increased key size and rounds) does not necessarily correlate to 
increased security and since GOST was given as an example of how to do it 
right the attacks by Kelsey, et al mattered.



By the way, it was not overdesign (IMO it is simpler even than DES),
nor it was an example of the stereotypical Soviet... According to an
informed source [1], it was specifically made to be not like military
ciphers:  its only purpose was to make something for non-military
cryptography that would not betray any Soviet cryptographic know-how
(this is why they chose to do something very similar to DES).


Good to know, I didn't remember that part.
   Joe 


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-08-06 Thread James A. Donald

Ben Laurie wrote:

So, I've heard many complaints over the years about how the UI for
client certificates sucks. Now's your chance to fix that problem -
we're in the process of thinking about new client cert UI for Chrome,
and welcome any input you might have. Obviously fully-baked proposals
are more likely to get attention than vague suggestions.


The fundamental problem with certificates is getting them.

OK, suppose you hit a web site that wants a client side certificate, 
maybe it wants a claimed email address with proof that you can receive 
email at that address, maybe it wants proof you are over 18, maybe it is 
run by the company you work for and wants proof you are an employee and 
wants to know which employee you are.  Maybe it wants evidence that you 
a member in good standing of the committee to slay infidels.


If we suppose your browser *has* such a certificate, and merely needs 
permission from you, the user, to show it, then the problem is 
relatively easy - which however does not stop existing browsers from 
fouling up mightily, perhaps because they are designed around verisign's

business model, rather than anything the user might actually want to
do.

But the problem is much harder, much much harder, if we suppose you do 
*not* have the certificate.


I will ignore the easy problem, because I am sure that anyone worth 
talking to can figure out the solution, even though existing browser 
writers have failed to do so.


OK. Hard Problem:  You the user have hit a website that wants a 
certificate with certain characteristics, and either you do not have it, 
or you have it somewhere, but your browser does not know you have it, 
perhaps because it is on another browser on another computer.


It appears to me that existing solutions to this problem are designed 
around Verisign's business model, rather than user needs.  If a client 
certificate is to identify you to examplecorp as an employee of 
examplecorp, why does Verisign need to get involved?  It's easier for 
examplecorp to issue its own @#$%^ certificates.


So, assuming you are pretty smart, as I know you to be, and assuming 
your boss is not evil and not in Verisign's pocket, which I do not know 
at all ...


So where *would* you have a certificate?  Where would you keep it, and 
what would it look like?


The kind of things that people are used to storing in a browser are 
bookmarks:  Bookmarks have the convenient property that they implement 
Zooko's triangle: petname, nickname, and guid.  They also have the 
property that if you click on them they take you somewhere.  So a 
certificate should act like some kind of smart bookmark and look to the 
user like a smart bookmark,  which if clicked on should bring you to 
your logged in web page with the authority issuing the certificate. 
Your secret key is something like a a secret link or bookmark that 
automatically logs you in to something like your facebook page, and your 
public key is something like a link or bookmark that enables other 
people to view something like your facebook page.  Maybe it is your 
employee page at examplecorp, which shows any records pertaining to you 
in the company database, some of which, such as contact information, are 
editable by you, but most of which are not.


And the something like your facebook page as seen by others is almost 
the same link the live authorization that your certificate is still valid.


So how do you *get* a certificate?  Suppose, for example, your 
certificate identifies you to your company, in which case your boss 
probably gave it to you.  What would he give you? Well, obviously, he 
would give you a username and password, or more likely you would create 
an account, a username and password, which he would then authorize.


Which username and password would I expect enable you to get to that 
logged in web page with the authority issuing the certificate, in this 
case some location on the company web server.  And you get to that web 
page, you would then get an install certificate title dialog, and if 
you accept, get something that looks and acts like a bookmark, though it 
is in fact a company issued certificate, certifying that you are 
username, where username is also a primary key in the company employee 
database.


But the trouble with this, of course, is that usernames and passwords 
can be phished.


The solution to that is password login and account creation in the 
chrome, not in the web page implementing password-authenticated key 
agreement, so that the phisher can gain nothing, so long as the user 
attempting to use the chrome login facilities, rather than html web page 
login facilities.


It should have been obvious that logging in on a user interface provided 
by a web page, provided by html code, was entirely insecure - the 
problem of spoofed logins was well known at the time. So what we
needed, from day one, was a secure login that was in the browser chrome, 
not the web page - and no other form of 

Re: Client Certificate UI for Chrome?

2009-08-06 Thread Peter Gutmann
Ben Laurie b...@google.com writes:

So, I've heard many complaints over the years about how the UI for
client certificates sucks. Now's your chance to fix that problem -
we're in the process of thinking about new client cert UI for Chrome,
and welcome any input you might have. Obviously fully-baked proposals
are more likely to get attention than vague suggestions.

This is predicated on the assumption that it's possible to make certificates 
usable for general users.  All the empirical evidence we have to date seems to 
point to this not being the case.  Wouldn't it be better to say What can we
do to replace certificates with something that works?, for example TLS-SRP
or TLS-PSK?

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: cleversafe says: 3 Reasons Why Encryption is Overrated

2009-08-06 Thread Ben Laurie
Zooko Wilcox-O'Hearn wrote:
 I don't think there is any basis to the claims that Cleversafe makes
 that their erasure-coding (Information Dispersal)-based system is
 fundamentally safer, e.g. these claims from [3]: a malicious party
 cannot recreate data from a slice, or two, or three, no matter what the
 advances in processing power. ... Maybe encryption alone is 'good
 enough' in some cases now  - but Dispersal is 'good always' and
 represents the future.

Surely this is fundamental to threshold secret sharing - until you reach
the threshold, you have not reduced the cost of an attack?

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-08-06 Thread Anne Lynn Wheeler

On 08/06/09 07:33, James A. Donald wrote:

The fundamental problem with certificates is getting them.


digital certificate design point supposedly was the dial-up email of the early 
80s,
dial-up, exchange email, hang-up ... and then faced with how to deal with first
time email from complete stranger. basically electronic analog for letters of
credit/introduction from sailing ship days.

in the 90s, because of numerous privacy and liability issues ... there
was some number of relying-party only certificates; individual registered
their public key with the institution, institution then created a digital
certificate with the public key, archived it, and returned a copy to the
individual. the individual, in communication with the institution would
digitally sign the communication and then append the digital certificate.
However, it was trivial to prove that the institution/relying-party already
had a copy of the information ... and the appended digital certificate
was redundant and superfluous. misc. past posts discussion relying-party only
digital certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

furthermore, major foreys into this sector were by financial institutions
for the purpose of payment transactions. a complicating factor ... besides
the digital certificates being redundant and superfluous ... they added
a 100 times payload size bloat to the typical payment transactions. misc.
past posts
http://www.garlic.com/~lynn/subpubkey.html#bloat

there was a financial standards effort that looked at possibly doing
compressed digital certificates (trying to achieve only ten times bloat)
... eliminating redundant fields and information already in the possession
of the individual's financial institution. we showed that the individual's
financial institution already had superset of the information in the
digital certificate ... so it was possible to compress digital certificates
to zero bytes ... and then mandate that financial transactions would always
have zero-byte certificates appended (as opposed to no appended digital
certificate).

Something similar was demonstrated for RADIUS and Kerberos ... registering
a public key in lieu of password ... some past references
http://www.garlic.com/~lynn/subpubkey.html#radius
and
http://www.garlic.com/~lynn/subpubkey.html#kerberos

and also something similar for registering public key with domain
name registration with domain name infrastructure ... for use in
lieu of SSL digital certificates
http://www.garlic.com/~lynn/subpubkey.html#catch22

that left institutions and relying party with no-value business processes
as digital certificate opportunities ... i.e. no-value transactions where
the relying party couldn't justify the cost of their own entity repository
and/or justify the cost of doing an online transactions to obtain such entity
information ... and of course ... the original design point, the offline
email scenario with first time communication with complete strangers.

One of the problems with no-value market segment is that it is hard for
institutions and individuals to justify paying for things without
any value ... and therefor it is hard to find entities looking
at selling things for nothing.

--
40+yrs virtualization experience (since Jan68), online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


RE: Client Certificate UI for Chrome?

2009-08-06 Thread Thomas Hardjono
Ben,

Having worked at a large CA for along time (trying to push for client-side 
certs with little luck), here are some thoughts on what Chrome could provide:

(a) Association with net identities: Provide some way for the user to associate 
his/her X.509 cert with an internet identity string (eg. OpenID, email 
address, etc etc) in the browser. (Yes, we could add such an identity in the 
SubjAltName, but that's outside the control of the end-user). This would allow 
the user to choose which cert to deliver to the server when the user is 
engaging the server using one of his/her identities. 

(PS. being able to associate with a small image/icon/photo of the user would 
also be nice).

The UI should be a simple as click cert and click identity, and then click 
associate.


(b) Export of certs: Provide an easy way to export client-certs to other apps.  
Currently some CAs use the browser as the primary means for cert enrollment. 
Currently in IE this is somewhat a lengthy process and the response (ie. export 
of cert successful or not) is also not very clear to the end-user.

The UI should not even talk about export. It should say something along the 
lines of Do you want to make your certificate available to the following Apps.


(c) Lock showing which cert/identity used: It would be useful if in addition to 
the Lock symbol (ie. SSL session established) there is a string (next to the 
Lock symbol) showing which client-side cert the browser is using for that SSL 
session. This is related to item (a) above, where a human-readable net identity 
is associate with the cert.

This helps the user in distinguishing which identity he/she is using when 
connecting to a Bank versus a Blog versus a corporate web-mail (all of which 
could be using distinct cert/identity). If there is a mismatch, the user can 
see this visually.


(d) Notification of expired certs:  It would be good if the browser could 
somehow notify the user if there are some expired certs (belonging to the user) 
in the browser. I'm finding that some browsers deliver the first cert in the 
list even when it has expired (thus causing the server to reject).


(e) Better notification/alerts of errors regarding server-certs:  This is a 
hard one as the average user (eg. my Mom) does not understand about certs to 
begin with. Since one of the main aims of SSL server-certs today is to prevent 
phishing, perhaps those messages should be phishing-oriented.

This one need further thought, but perhaps a third button/option could be 
provided (in addition to the Cancel and Continue buttons). This third button 
could provide the user with some alternate sites with similar sounding domain 
names but with proven/valid server-certs.


(f) Better graphical representation of cert hierarchy: Perhaps not crucial, but 
a nice graphical representation of the cert hierarchy/tree might help educate 
the average user (my Mom/Dad) about what a CA is and where the user is located 
in the hierarchy. This would even help the average employee when his/her 
company is using a subordinate CA off a public CA.

When the user clicks on a node in the tree, it should show the organization 
name and other human friendly details.


(g) Easy check button for server-certs: It would be great if I could 
right-click the Lock symbol on the browser and be able to choose an action 
along the lines of Validate Server Certificate. The browser would then hit 
the corresponding OCSP Responder (as denoted in the server-cert) and report the 
status to the user using some graphical notation (eg. icon of server with a big 
X if the server-cert is invalid or status unknown).



That's all for now. Will send more thoughts if any come up :)

/thomas/





 -Original Message-
 From: owner-cryptogra...@metzdowd.com [mailto:owner-
 cryptogra...@metzdowd.com] On Behalf Of Ben Laurie
 Sent: Wednesday, August 05, 2009 9:59 AM
 To: Cryptography
 Subject: Client Certificate UI for Chrome?
 
 So, I've heard many complaints over the years about how the UI for
 client certificates sucks. Now's your chance to fix that problem -
 we're in the process of thinking about new client cert UI for Chrome,
 and welcome any input you might have. Obviously fully-baked proposals
 are more likely to get attention than vague suggestions.
 
 I imagine I may well hear what about the UI around server
 certificates? - fair enough, feel free, and I'll see what I can do.
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to
 majord...@metzdowd.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com