Re: browser vendors and CAs agreeing on high-assurance certificat es

2005-12-21 Thread leichter_jerrold
|  Imagine a E-commerce front end:  Instead of little-guy.com buying a
cert
|  which you are supposed to trust, they go to e-commerce.com and pay for a
|  link.  Everyone trusts e-commerce.com and its cert.  e-commerce provides
a
|  guarantee of some sort to customers who go through it, and charges the
|  little guys for the right.
| 
| Do you mean like Amazon Marketplace and Amazon zShops? I think it's been
| done already:
| 
| http://www.amazon.com/exec/obidos/tg/browse/-/1161232/103-4791981-1614232
Well, yes, and eBay provides the same service.  But how much protection are
they providing for buyers?  I think Amazon will cover the first $100 a
customer paid.  eBay gives you a bit of protection if you go with PayPal,
but not a whole load - they rely on their reputation system.

e-commerce.com would bring up a page saying:  We guarantee that
transactions
up to $nnn with this site will be to your satisfaction or your money back.
The merchant would specify the maximum dollar value, and pay e-commerce.com
based on the limit and, presumably, his reputation with e-commerce.  (This 
is one way it might be set up - there are certainly other ways.  And, even
in this style, the entire wording of the guarantee would be something agreed
upon between the seller and e-commerce.

-- Jerry


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


Re: whoops (residues in a finite field)

2005-12-21 Thread Alexander Klimov
On Mon, 19 Dec 2005, Travis H. wrote:
 He says no mpi/modular arithmetic libraries that he knows of use
 this technique

I guess the main reason is that the environments where these libraries
are supposed to be used are believed to be immune to the attacks
these checks are trying to prevent: the faults attacks are not
likely on a PC and especially hard to do remotely :-) OTOH, ICCs
(aka. smartcards) are quite vulnerable and usually do employ the
countermeasures.

 The idea is that if an attacker exploits a bug

A fault attack does not exploit a bug, but, say, a power glitch or
radiation.

 Exactly what you would do in that case, I'm not sure...

It depends on what exactly you try to prevent: which information you
want to hide. For example, if you calculate RSA signature (with CRT)
on an ICC using dummy multiplications (to avoid side channel attacks)
and checks correctness only in the end, the fact that no error occurs
may suggests that the glitch was introduced during such a dummy
operation and thus it does not matter what you do if you detect an
error. OTOH if you check error on each arithmetic operation (including
the dummy one) you can just stop -- this does not give an attacker any
additional information since he might as well guess himself that the
power glitch he applied would cause a fault.

BTW, fault-based cryptanalysis is not limited to RSA with CRT (or
public key in general): block ciphers can be also vulnerable.

-- 
Regards,
ASK

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


Re: A small editorial about recent events.

2005-12-21 Thread Adam Fields
On Sun, Dec 18, 2005 at 07:55:57PM -0500, Steven M. Bellovin wrote:
[...]
 The Court also noted that Congress rejected an amendment which would
 have authorized such governmental seizures in cases of emergency.
 Given that the Patriot Act did amend various aspects of the wiretap
 statute, it's hard to understand how the administration's reading is
 justified in any way, shape, or form.

There's some speculation that FISA could not have provided
authorization for the wiretaps, because what they were doing were not
actually directed wiretaps, but instead search-and-discard-negatives.

Josh Marshall has some analysis:

http://www.talkingpointsmemo.com/archives/007286.php
http://www.talkingpointsmemo.com/archives/007290.php

and discussion here:

http://www.tpmcafe.com/story/2005/12/19/20530/546

Here's Rockefeller's handwritten letter to Cheney, in which he says
As I reflected on the meeting today, and the future we face, John
Poindexter's TIA project sprung to mind.

http://talkingpointsmemo.com/docs/rock-cheney1.html

-- 
- Adam

** Expert Technical Project and Business Management
 System Performance Analysis and Architecture
** [ http://www.everylastounce.com ]

[ http://www.aquick.org/blog ]  Blog
[ http://www.adamfields.com/resume.html ].. Experience
[ http://www.flickr.com/photos/fields ] ... Photos
[ http://www.aquicki.com/wiki ].Wiki
[ http://del.icio.us/fields ] . Links




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


Re: another feature RNGs could provide

2005-12-21 Thread Ben Laurie
Jack Lloyd wrote:
 On Mon, Dec 12, 2005 at 12:20:26AM -0600, Travis H. wrote:
 2) While CTR mode with a random key is sufficient for creating a
 permutation of N-bit blocks for a fixed N, is there a general-purpose
 way to create a N-bit permutation, where N is a variable?  How about
 picking a cryptographically strong permutation on N elements, where N
 is not necessarily a power of 2?
 
 Use can use the Bear or Lion constructions to form 2^{arbitrary} bit block
 ciphers quite easily.

Good ciphers aren't permutations, though, are they? Because if they
were, they'd be groups, and that would be bad.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
**  ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ **
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 [EMAIL PROTECTED]


Re: browser vendors and CAs agreeing on high-assurance certificates

2005-12-21 Thread Peter Gutmann
James A. Donald [EMAIL PROTECTED] writes:

If no attacks, this is just an excuse for higher priced holy water, an 
attempt to alter the Browser interface to increase revenue, not increase 
security - to solve the CA's problem, not solve the user's problem.

That's a somewhat cynical view :-) of what I'd seen it as, a case of looking 
for 
the dropped contact lens where the light is.  The CAs and auditors are in the
business of auditing and checking, so they try and address the phishing problem 
by adding more auditing and checking to the cert issue process because that's 
the only thing they can do.  To grab a few chunks from an article on security 
usability that'll be published Real Soon Now (note that this is a summary of 
much preceding text containing examples of each of the cases mentioned below):

  The security model used with SSL server certificates might be called honesty-
  box security: In some countries newspapers are sold on the street by having a 
  box full of newspapers next to a coin box (the honesty box) into which people 
  are trusted to put the correct coins before taking out a paper. Of course 
they 
  can also put in a coin and take out all the papers, or put in a washer and 
  take out a paper, but most people are honest and so most of the time it 
works. 
  SSL.s certificate usage is similar. If you use a $495 certificate, people 
will 
  come to your site. If you use a $9.95 certificate, people will come to your 
  site. If you use a $0 self-signed certificate, people will come to your site. 
  If you use an expired or invalid certificate, people will come to your site. 
  If you.re a US financial institution and use no certificate at all but put up 
  a message reassuring users that everything is OK, people will come to your 
  site. In medical terms, the effects of this .security. are indistinguishable 
  from placebo.

  In fact the real situation is even worse than this. Although there has been 
  plenty of anecdotal evidence of the ineffectiveness of SSL certificates over 
  the years, it wasn.t until mid-2005 (ten years after their introduction) that 
  a rigorous study of their actual effectiveness was performed. This study, 
  carried out with computer-literate senioryear computer science students (who  
  one would expect would be more aware of the issues than the typical user) 
  confirmed the anecdotal evidence that invalid SSL certificates had no effect 
  whatsoever on users visiting a site.

  [...]

  A contributing factor in the SSL certificate problem is the fact that 
security 
  warnings presented to the user often come with no supporting context. Since 
  web browsers implicitly and invisibly trust a large number of CAs, and by 
  extension a vast number of certificates, users have no idea what a 
certificate 
  is when an error message mentioning one appears. One user survey found that 
  many users assumed that it represented some form of notice on the wall of the 
  establishment, like a health inspection notice in a restaurant or a Better 
  Business Bureau certificate, a piece of paper that indicates nothing more 
than 
  that the owner has paid for it (which is indeed the case for most SSL 
  certificates). Users were therefore dismissive of .trusted. certificates, and 
  as an extension cared equally little about .untrusted. ones.

  This user conditioning presents a somewhat difficult problem. Psychologists 
  have performed numerous studies over the years that examine people.s 
behaviour 
  once they.ve become habituated into a particular type of behaviour and found 
  that, once acquired, an (incorrect) whirr, click response is extremely 
  difficult to change, with users resisting attempts to change their behaviour 
  even in the face of overwhelming evidence that what they.re doing is wrong. 

So, as you say, high-assurance certs are solving a CA and regulation-settor 
problem, not a phishing problem.

It'll be interesting to see how things look in a years' time.

Peter.

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


Re: another feature RNGs could provide

2005-12-21 Thread Perry E. Metzger

Ben Laurie [EMAIL PROTECTED] writes:
 Jack Lloyd wrote:
 On Mon, Dec 12, 2005 at 12:20:26AM -0600, Travis H. wrote:
 2) While CTR mode with a random key is sufficient for creating a
 permutation of N-bit blocks for a fixed N, is there a general-purpose
 way to create a N-bit permutation, where N is a variable?  How about
 picking a cryptographically strong permutation on N elements, where N
 is not necessarily a power of 2?
 
 Use can use the Bear or Lion constructions to form 2^{arbitrary} bit block
 ciphers quite easily.

 Good ciphers aren't permutations, though, are they? Because if they
 were, they'd be groups, and that would be bad.

Actually, by definition, a cipher should be a permutation from the set
of plaintexts to the set of ciphertexts. It has to be 1 to 1 bijective
or it isn't an encryption algorithm.

Therefore, if you want an ergodic sequence of size 2^N, a counter
encrypted under an N bit block cipher will do it.

Perry

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