Re: dual-use digital signature vulnerability

2004-07-22 Thread Rich Salz
 attempt to address this area; rather than simple i agree/disagree
 buttons ... they put little checkmarks at places in scrolled form  you
 have to at least scroll thru the document and click on one or more
 checkmarks  before doing the i agree button. a digital signature has
 somewhat higher integrity than simple clicking on the i agree button ...

See US patent 5,995,625. The abstract:
A method of unwrapping wrapped digital data that is unusable
while wrapped, includes obtaining an acceptance phrase from a
user; deriving a cryptographic key from the acceptance phrase;
and unwrapping the package of digital data using the derived
cryptographic key. The acceptance phrase is a phrase entered
by a user in response to information provided to the user. The
information and the acceptance phrase can be in any appropriate
language. The digital data includes, alone or in combination, any
of: software, a cryptographic key, an identifying certificate,
an authorizing certificate, a data element or field of an
identifying or authorizing certificate, a data file representing
an images, data representing text, numbers, audio, and video.

Rich Salz  Chief Security Architect
DataPower Technology
XS40 XML Security Gateway
XML Security Overview

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

Re: Cryptography and the Open Source Security Debate

2004-07-22 Thread J Harper
There doesn't appear to be a discussion forum related to the Web post, so
I'll reply here.

We've gone through a similar thought process at my company.  We have a
commercial security product (MatrixSSL), but provide an open source version
for many of the good points Daniel makes.  There are a few additional
reasons that the general open-source conclusion isn't as clear cut however.

One of the benefits of having security algorithms open source is that the
code can be better trusted in terms of back doors.  So while Daniel may
trust the NSA, others may not.  Standard software typically isn't treated
with the same positive paranoia, and therefore doesn't often have the same
requirement.  Back doors in closed source networked software, for example
can be somewhat tested for through network protocol analysis and controlled
through firewalls.  Cryptography must be trusted at an algorithm level,
since protocol analysis of the resultant data (should be) very difficult.

A larger problem with the expansion from cryptographic algorithm benefits to
open source benefits in general is one of pure code size.  The number of
lines of code of both Windows and Linux distributions is 30-40 million.  The
number of developers that 1. bother reading the code, 2. can actually
understand it, 3. have the expertise and motivation to suggest/correct
problems is a very small subset of developers for either proprietary or open
source solutions.  Developers that understand the complex interactions
between software components are even fewer.  When it comes down to it, a
very small set of people becomes trusted in whatever code area they
specialize in.  Crypto algorithms are typically on the order of 1000 lines
of code, with a large portion containing static key blocks.  Experts looking
at an open crypto algorithm require a great deal of expertise, but can also
be much more focused in their analysis.

 Do you trust both the talent and moral integrity of the company you are
 getting your closed source software from so much that you think the
 products they are supplying you are superior (from a security standpoint)
 to those that can be created via peer review and attack by tens of
This question is less related to the crypto specific conclusion, so I'll
keep it short.  The power of capitalism to produce competition and better
products is underestimated here.  Market pressure is growing for closed
source to become more secure, and when money is at stake, the products will
improve.  Peer review by tens of thousands of largely unpaid, untrained
developers vs. a corporation's all important shareholder value in this
increasingly security conscious market is a much more even fight than one
might expect.  This is why we have combined both sides of the debate to
produce a dual licensed product that has the security benefits of open
source, with the market responsibility of a commercial product.

J Harper
PeerSec Networks

- Original Message - 
From: R. A. Hettinga [EMAIL PROTECTED]
Sent: Tuesday, July 20, 2004 9:46 AM
Subject: Cryptography and the Open Source Security Debate

 osViews | osOpinion

 Cryptography and the Open Source Security Debate

 Articles / Security
 Date: Jul 20, 2004 - 01:03 AM

 Contributed by: Daniel R. Miessler
  :: Open Content

 If you follow technology trends, you're probably aware of the two schools
 of thought with regard to security and/or cryptography. Does cryptography
 and security solutions become more secure as the number of eyes pouring
 over its source code increases or is a private solution which leverages
 security through obscurity provide a more secure environment?

  Daniel R. Miessler submitted the following editorial to
 which offers some compelling arguments for both scenarios. In the end, his
 well thought out opinion, comes to a universal conclusion.

  I've been reading Bruce Schneier's Book on cryptography for the last
 couple of days, and one of the main concepts in the text struck me as

  One of the points of discussion when looking at the security of a given
 algorithm is its exposure to scrutiny. Bruce explicitly states that no one
 should ever trust a proprietary algorithm. He states that with few
 exceptions, the only relatively secure algorithms are those that have
 the test of time while being poured over by thousands of cryptanalysts.

 Similar Situations

  What struck me is the similarity between this mode of thought and that of
 the open source community on the topic of security. In that debate there
 much disagreement about which is better - open or closed -, while in the
 crypto world it's considered common knowledge that open is better.
 According to the crypto paradigm, having any measure of an algorithm's
 security based on the fact that it's a secret is generally a bad thing.
 There, keys are what makes the system 

Identity theft case could be largest so far

2004-07-22 Thread R. A. Hettinga


Identity theft case could be largest so far

 Wednesday, July 21, 2004 Posted: 10:49 PM EDT (0249 GMT)

WASHINGTON (CNN) -- A Florida man was indicted Wednesday in an alleged
scheme to steal vast amounts of personal information, and the Justice
Department said it might be the largest illegal invasion and theft of
personal data to date.

The 144-count indictment against Scott Levine, 45, also includes charges of
conspiracy, fraud, money laundering and obstruction of justice, according
to the Justice Department.

Levine's alleged target was Acxiom Corp., one of the world's largest
companies managing personal, financial and corporate data, federal
authorities said.

Levine is accused of stealing vast amounts of personal information from the
company via the Internet.

Federal officials said the theft of approximately 8.2 gigabytes of data
resulted in losses of more than $7 million.

The protection of personal information stored on our nation's computer
systems is critical to public trust in those networks and to the health of
our economy, said Assistant Attorney General Christopher Wray at a news
conference in Washington.

We will aggressively pursue those who steal private information from
computer networks and make it clear that there are serious consequences for
such crimes, he said.

Levine, a resident of Boca Raton, Florida, is described in the indictment
as the controlling force in Inc., a Florida corporation
engaged in distributing advertisements via the Internet on behalf of
advertisers and brokers.

Acxiom, headquartered in Little Rock and Conway, Arkansas, stores and
processes millions of bits of data on behalf of a wide range of clients
that include IBM, GE, Microsoft and many major credit card companies.

The invasions from Snipermail were discovered during another investigation
of another intrusion at Acxiom last year, authorities said.

The FBI's regional computer forensics laboratory in Dallas, Texas, and
computer forensic experts from the FBI and the Secret Service were
unleashed on the cyber intruders.

The indictment alleges that Levine and others at the company attempted to
hide computers from investigators.

Six employees at the company agreed to cooperate with the investigation,
authorities said.

R. A. Hettinga mailto: [EMAIL PROTECTED]
The Internet Bearer Underwriting Corporation
44 Farquhar Street, Boston, MA 02131 USA
... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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

On SSL, SET, `real PKI` and real code against Phishing/Spoofing

2004-07-22 Thread Amir Herzberg
 brief comments/suggestions:
1. The whole discussion on how much eavesdropping is a threat is 
irrelevant. We all know it is a threat and the level is not important, 
as SSL/TLS provide a good, inexpensive solution. Drop this topic.

2. Stop beating the dead horse (SET). But yes, we should learn from 
mistakes... and Steve is right: SET main failure was lack of incentive 
to buyers and sellers. Such an incentive was our design assumption and I 
was assured by the CC `suits` they'll do it, but when they did, it was 
too little and much too late. And also they added so much baggage on 
this poor protocol that it became really so complex. But I am proud of 
few things in SET, especially...
 It wasn't even a real PKI ...
No, exactly, it wasn't. Because what you refer to as `real PKI` (see 
original note...) - identities, revocation etc. - are not needed for 
this application (and many others). We need to use the tool that fits 
the job.

3. Which brings us back to SSL and Ian's objection... I think Ian 
_really_ objects to the fact that the major SSL/TLS deployments 
(browsers, servers) depend on `browser PKI`. And I agree: I think the 
`browser PKI` is a sad joke (on us), with the weakly-secure, 
not-really-trusted list of over-100 CAs. We can do much better - use 
SSL, but checking certificates better; display the logo of the site 
and/or of the CA, and allow users to decide on sites they trust (and 
their logos) manually...

We have been discussing these things on this list for ages, and some 
even asked `is there a real use for crypto`. Then, with Ahmad, we 
implement and document a cute little extension to Mozilla that uses SSL 
and certificates, but probably not what some may call `real PKI`. And 
guess what? You go back to argue on SSL vs. SET and such.

Guys: give us some feedback! Ok, it's a paper, not a note, but it is 
really pretty easy reading. And if this is too much, at least look at 
the screen shot: 

And then speak up - is it the right approach? Should we change something 
before releasing (hoping in a week or two) or longer term? Can you do it 
for IE or other browser?

(for the paper, see my homepage as below...)
Best regards,
Amir Herzberg
Associate Professor, Computer Science Dept., Bar Ilan University (information and lectures in cryptography  
Mirror site:
fn:Amir  Herzberg
org:Bar Ilan University;Computer Science
adr:;;;Ramat Gan ;;52900;Israel
email;internet:[EMAIL PROTECTED]
title:Associate Professor
url: , mirror: 

Re: dual-use digital signature vulnerability

2004-07-22 Thread Amir Herzberg
Barney Wolff wrote:
Pardon a naive question, but shouldn't the signing algorithm allow the
signer to add two nonces before and after the thing to be signed, and
make the nonces part of the signature?  That would eliminate the risk
of ever signing something exactly chosen by an attacker, or at least
so it would seem.
Most (secure) signature schemes actually include the randomization as 
part of their process, so adding nonces to the text before signing is 
not necessary. OTOH, I don't see any problem in defining between the 
parties (in the `meta-contract` defining their use of public key 
signatures) that the signed documents are structured with a random field 
before and after the `actual contract`, as long as the fields are well 
Best regards,

Amir Herzberg
Associate Professor, Computer Science Dept., Bar Ilan University (information and lectures in cryptography  
Mirror site:
fn:Amir  Herzberg
org:Bar Ilan University;Computer Science
adr:;;;Ramat Gan ;;52900;Israel
email;internet:[EMAIL PROTECTED]
title:Associate Professor
url: , mirror: 

Re: RP -- Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-22 Thread Anne Lynn Wheeler
At 01:39 PM 7/21/2004, Ed Gerck wrote:
The PKI model is not tied to any legal jurisdiction and is not a
business process. What is meant then by relying-party (RP) and
RP Reliance in X.509 and PKIX? I hope the text below, from a
work in progress submitted as an IETF ID, helps clarify this issue.

the TTP (trusted third party) PKI business model typically described in the 
early 90s ... had a business exchange between a key owner and a 
certification authority ... where the key owner paid the certification 
authority for the issuing of a certificate that bound some information to 
the public key. The payment of money by the key owner to the certification 
authority created some sort of legal relationship between the key owner and 
the certification authority  with regard to the certificate.

in that environment  the key owner then digitally signed something, and 
sent the something with a digital signature and the certificate to a 
relying-party. The relying-party was frequently assumed to be making some 
sort of legal reliance and recourse on the performance of the certification 
authority. However, w/o payment of funds and/or other legal arrangement 
between the relying-party and the certification authority  there was no 
legal bases for reliance (unless mandated outside of traditional business 
context by some gov. mandate)

it appears that the GAO  working within that semantic  structural 
business context ... has taken some effort to create a legal basis for 
reliance and recourse between the relying parties and the certification 
authorities for the federal PKI . It basically has something along the 
lines of the certification authorities signing a contractual relationship 
with the GAO. Then all the relying parties also sign a contractual 
relationship with the GAO   then there is recourse for the relying 
parties on certification authority performance based on the relying parties 
contract with GAO (for certification authority performance) and the GAOs 
contract with the certification authorities (for certification authority 
performance). This is sort of trying to get around the lack of any implied 
performance and/or contractual relationship (and therefor recourse) because 
the relying parties haven't actually paid any money to the certification 

In the simple case, having any sort of legal obligation between the 
certification authority and the key-owner ... and any sort of totally 
different legal obligation between the key-owner and a relying party ... 
normally would fail to create any sort of legal obligation between (the 
traditional TTP PKI) certification authorities (described in the early 90s) 
and the set of relying parties.

some of this became mute by the mid-90s with the observation that the 
traditionally considered identity x.509 certificates represented a 
significant privacy and liability exposure ... and the retrenching by 
infrastructures to relying-party-only certificates (effectively account 
number and public key ... although even a relying-party-only SET 
certificates could represent a factor of 100-times payload bloat). the 
other issue that quickly became observed if the relying-party and the 
certification authority were the same  then the relying party would 
typically have a large superset of the information that they included in 
any relying-party-only certificate ... and that having the key-owner to 
return this small subset of information repeatedly to the relying-party 
(/certification authority) was redundant and superfluous  other than 
possibly contributing huge computational and transmission overheads for no 
useful purpose.

IETF standards tend to be descriptions of protocol and parties role in the 
protocol. Such syntactical and semantical description of the protocols has 
rarely included description of any possible syntactical and semantic 
business relationships  especially of the typical kind being proposed 
in the early 90s for TTP certification authorities.

for pkix references  see
and click on Term (term-RFC#) in the RFC's listed by section
then click on PKI in the Acronym fastpath section.
the current results:
public key infrastructure (PKI)
see also file:///D:/users/http/rfcterms.htm#t508authentication , 
file:///D:/users/http/rfcterms.htm#t600encryption , 
file:///D:/users/http/rfcterms.htm#t770public key

Re: Identity theft case could be largest so far

2004-07-22 Thread Ian Grigg
R. A. Hettinga wrote:

Identity theft case could be largest so far
From other reports, the indictment alleges that Levine
gained access ... by misusing a legitimate password and user
name while working for a company doing business with Acxiom.
I.e., not even a hack, but an insider theft.
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]