From pgut001 at cs.auckland.ac.nz  Wed Sep  1 00:02:02 2004
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Wed, 01 Sep 2004 16:02:02 +1200
Subject: Compression theory reference?
In-Reply-To: <20040831124800.GA6167@danisch.de>
Message-ID: <E1C2MJu-0005k0-00@medusa01>

Hadmut Danisch <hadmut at danisch.de> writes:

>I need a literature reference for a simple problem of encoding/compression
>theory:

comp.compression FAQ, probably question #1 given the number of times this
comes up in the newsgroup.

(I've just checked, it's question #9 in part 1.  Question #73 in part 2 may
 also be useful).

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From daw at cs.berkeley.edu  Wed Sep  1 00:10:32 2004
From: daw at cs.berkeley.edu (David Wagner)
Date: Tue, 31 Aug 2004 21:10:32 -0700 (PDT)
Subject: More problems with hash functions
Message-ID: <200409010410.i814AWqq019641@taverner.CS.Berkeley.EDU>

Jerrold Leichter  wrote:
>Joux's attack says:  Find single block messages M1 and M1' that collide on
>the "blank initial state".  Now find messages M2 amd M2' that collide with
>the (common) final state from M1 and M1'.  Then you hav four 2-block
>collisions for the cost of two:  M1|M2, M1'|M2, and so on.
>
>But even a simple XOR breaks this.  M1 and M1' have the same hash H, but the
>state being passed is now very different:  <H,M1> in one case, <H,M1'> in the
>other.  So M1|M2 and M1'|M2 are completely different:  Both started the second
>step with the compression function in state H, but the first compressed
>M1 XOR M2, and the second M1' XOR M2.

Doesn't work, alas.  A trivial adjustment to Joux's attack also defeats
your proposal.

Suppose M1 and M1' collide on the "blank initial state".  Let M2 be
arbitrary.  Then M1|M2 and M1'|M2 collide, and the final state after
processing them is <H,M2> in both cases.  Now find messages M3 and
M3' that collide if processed starting from the common state <H,M2>.
Then you have four 3-block collisions for the cost of two: M1|M2|M3,
M1'|M2|M3, etc.

With this small tweak, Joux's attack will go through.  So, your scheme
offers little or no additional resistance to Joux's attack.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From hadmut at danisch.de  Wed Sep  1 03:35:37 2004
From: hadmut at danisch.de (Hadmut Danisch)
Date: Wed, 1 Sep 2004 09:35:37 +0200
Subject: Compression theory reference?
In-Reply-To: <E1C2MJu-0005k0-00@medusa01>
References: <20040831124800.GA6167@danisch.de> <E1C2MJu-0005k0-00@medusa01>
Message-ID: <20040901073537.GA31966@danisch.de>

On Wed, Sep 01, 2004 at 04:02:02PM +1200, Peter Gutmann wrote:
> 
> comp.compression FAQ, probably question #1 given the number of times this
> comes up in the newsgroup.
> 
> (I've just checked, it's question #9 in part 1.  Question #73 in part 2 may
>  also be useful).


Thanks, that's a pretty good hint, especially because it contains 
an explicit statement, and it's an FAQ, making it easy to show, that
the university's claim is not just wrong, but silly. :-)

regards
Hadmut

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From Jdean at lsuhsc.edu  Wed Sep  1 07:46:41 2004
From: Jdean at lsuhsc.edu (Dean, James)
Date: Wed, 1 Sep 2004 06:46:41 -0500 
Subject: Compression theory reference?
Message-ID: <4DDCE8648ECDD11187910060979C535807602027@lsumcbolivar.lsumc.edu>

On Tue, Aug 31, 2004 at 02:48:00PM +0200, Hadmut Danisch wrote:

> It can be easily shown that there is no lossless
> compression method which can effectively compress every possible
> input. 

Even more simply, if such a method existed, you could recursively 
apply it to its output and compress every message as one bit.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From kelsey.j at ix.netcom.com  Wed Sep  1 10:37:10 2004
From: kelsey.j at ix.netcom.com (John Kelsey)
Date: Wed, 1 Sep 2004 10:37:10 -0400 (GMT-04:00)
Subject: ?splints for broken hash functions
Message-ID: <20385948.1094049430885.JavaMail.root@beaker.psp.pas.earthlink.net>

>From: Ivan Krstic <krstic at fas.harvard.edu>
>Sent: Aug 29, 2004 8:40 AM
>To: Metzdowd Crypto <cryptography at metzdowd.com>
>Subject: Re: ?splints for broken hash functions

>This is Schneier's and Ferguson's solution to then-known hash function 
>weaknesses in Practical Cryptography, Wiley Publishing, 2003:

>"We do not know of any literature about how to fix the hash functions, 
>but here is what we came up with when writing this book. ... Let h be 
>one of the hash functions mentioned above. Instead of m->h(m), we use 
>m->h(h(m) || m) as hash function. Effectively we put h(m) before the 
>message we are hashing. This ensures that the iterative hash 
>computations immediately depend on all the bits of the message, and no 
>partial-message or length extension attacks can work. ... 

I believe this falls to a generalization of the Joux attack, as well.  (Someone may have already noticed this.)  

a.  I build a 2^{80} multicollision on h(m) using Joux' attack, requiring 80*2^{80} work.  

b.  I now have 2^{80} different messages which are being hashed with the same IV.  I expect one pair of them to give me a collision.  

>Cheers,
>Ivan.

Comments?

--John

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From Marcel_Popescu at microbilt.com  Wed Sep  1 10:55:59 2004
From: Marcel_Popescu at microbilt.com (Marcel Popescu)
Date: Wed, 1 Sep 2004 17:55:59 +0300
Subject: "Approximate" hashes
Message-ID: <0c4601c49033$caecb9a0$726e9cd9@mark>

I am trying to build a Windows anti-spam thingy; it's supposed to "sit" in
between the mail client and the outer world, and indicate through mail
headers whether the incoming mail has a valid hashcash
http://www.hashcash.org/ "coin" (and, of course, to automatically add
hashcash to outgoing emails).

My problem is that I don't know what happens with the email in transit
(this, I believe, is an observation in the hashcash FAQ). I am worried that
some mail server might dislike ASCII characters with the high bit set, or
that a client uses some encoding which for some reason doesn't make it to
the destination unchanged.

Hence my question: is there some "approximate" hash function (which I could
use instead of SHA-1) which can verify that a text hashes "very close" to a
value? So that if I change, say, tabs into spaces, I won't get exactly the
same value, but I would get a "good enough"?

I don't know if this is possible. But if it is, I though this would be a
good place to find out about it.

Thanks,
Marcel

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From Marcel_Popescu at microbilt.com  Wed Sep  1 11:02:44 2004
From: Marcel_Popescu at microbilt.com (Marcel Popescu)
Date: Wed, 1 Sep 2004 18:02:44 +0300
Subject: "Approximate" hashes
Message-ID: <0c4c01c49034$bc1999b0$726e9cd9@mark>

From: "Marcel Popescu" <Marcel_Popescu at microbilt.com>

> Hence my question: is there some "approximate" hash function (which I
could
> use instead of SHA-1) which can verify that a text hashes "very close" to
a
> value? So that if I change, say, tabs into spaces, I won't get exactly the
> same value, but I would get a "good enough"?

I just had an idea. Would this work?

- let S be the input string, whose hash I want to verify
- make S uppercase
- remove everything but A-Z, 0-9, and common punctuation (!;:'",.?)
- calculate the SHA1 hash of the result

This should keep any insignificant changes out of the final result. Does
anyone know of a mail transformation which could upset it? Can anyone see a
way to "attack" this by letting a significantly different message collide on
the same hash? (I'm ignoring the recent discoveries - they're not that
practical, I'm only trying to fight spam, not the government.)

Thanks,
Marcel

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From mccoy at mad-scientist.com  Wed Sep  1 12:26:34 2004
From: mccoy at mad-scientist.com (Jim McCoy)
Date: Wed, 1 Sep 2004 09:26:34 -0700
Subject: Implementation choices in light of recent attacks?
Message-ID: <B0C0E07C-FC33-11D8-A6CC-000A95BD758E@mad-scientist.com>

After digesting the various bits of information and speculation on the 
recent breaks and partial attacks on various popular hash functions I 
am wondering if anyone has suggestions for implementation choices for 
someone needing a (hopefully) strong hash today, but who needs to keep 
the hash output size in the 128-192 bit range.  A cursory examination 
of Tiger seems to indicate that it uses a different methodology than 
the MDx & SHAx lines, does this mean that it does not suffer from the 
recent hash attacks?  Would a SHA256 that has its output chopped be 
sufficient?

Any suggestions would be appreciated.

Jim

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From cscott at cscott.net  Wed Sep  1 13:11:32 2004
From: cscott at cscott.net (C. Scott Ananian)
Date: Wed, 1 Sep 2004 13:11:32 -0400 (EDT)
Subject: "Approximate" hashes
In-Reply-To: <0c4601c49033$caecb9a0$726e9cd9@mark>
References: <0c4601c49033$caecb9a0$726e9cd9@mark>
Message-ID: <Pine.GSO.4.58.0409011307380.2431@catfish.csail.mit.edu>

On Wed, 1 Sep 2004, Marcel Popescu wrote:

> My problem is that I don't know what happens with the email in transit
> some mail server might dislike ASCII characters with the high bit set, or
> Hence my question: is there some "approximate" hash function (which I could

PGP has this issue with 'clear-signed' output.  An excerpt from the pgp
man page:
    If CLEARSIG is enabled, then when signing and ASCII-armoring a text
    file, PGP uses a different format that includes the plaintext in
    human-readable form.  Lines beginning with "-" are quoted with "- ".
    To cope with some of the stupider mailers in the world, lines
    beginning with "From"  are also quoted, and trailing whitespace on
    lines is stripped.  PGP will remove the quoting if you use it to
    decrypt the message, but the trailing whitespace is not recovered.
    This is still useful enough to be enabled by default.
You might find more details about typical mailer-munging from the PGP docs
or source.
 --scott

GRALLSPICE Moscow MKSEARCH affinity group KUDESK Nazi operative Clinton
   Register to vote!  http://www.yourvotematters.org/VerifiedVoting
                         ( http://cscott.net/ )

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From hal at finney.org  Wed Sep  1 13:55:39 2004
From: hal at finney.org (Hal Finney)
Date: Wed,  1 Sep 2004 10:55:39 -0700 (PDT)
Subject: ?splints for broken hash functions
Message-ID: <20040901175539.5288D57E2E@finney.org>

John Kelsey critiques the proposal from Practical Cryptography:
> >"We do not know of any literature about how to fix the hash functions, 
> >but here is what we came up with when writing this book. ... Let h be 
> >one of the hash functions mentioned above. Instead of m->h(m), we use 
> >m->h(h(m) || m) as hash function.
>
> I believe this falls to a generalization of the Joux attack, as well.  (Someone may have already noticed this.)  
>
> a.  I build a 2^{80} multicollision on h(m) using Joux' attack, requiring 80*2^{80} work.  
>
> b.  I now have 2^{80} different messages which are being hashed with the same IV.  I expect one pair of them to give me a collision.  

You did 80*2^80 work to create a collision.  But you could create a
collision without all this effort in only 2^80 work, by a conventional
birthday attack.  Just ignore the internal structure and treat it as
a 160 bit hash function and you can collide in 2^80 work.  You worked
harder than you needed to, so this is not a break.

Hal

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From bear at sonic.net  Wed Sep  1 14:12:27 2004
From: bear at sonic.net (bear)
Date: Wed, 1 Sep 2004 11:12:27 -0700 (PDT)
Subject: Compression theory reference?
In-Reply-To: <20040831220409.GA29492@danisch.de>
References: <20040831124800.GA6167@danisch.de> <4134E5F9.8040200@av8n.com>
 <20040831220409.GA29492@danisch.de>
Message-ID: <Pine.LNX.4.58.0409011105420.4934@bolt.sonic.net>



On Wed, 1 Sep 2004, Hadmut Danisch wrote:

>
>I have often heard that example and I used it myself several times.  I
>do not use it anymore, because it is not that easy. There's a major
>flaw in this example, and therefore it is not really a
>counterexample. If the faculty found that flaw I'd be in a bad
>position.
>
>You could define some reversible bizarre function f that does exactly
>that job, i.e. for a given message m you need to apply f again and
>again and after some finite number of calculations you'll find that
>f(...f(m)...) = x where x = 0 or 1

For example, loading the message into a Linear Feedback Shift
Register and iterating until it produces one of two predetermined
messages 0 or 1?

For a nontrivial message, the last star will burn out before you
get that many iterations.  Also, as you say, in order to decode
the message you have to know how many iterations you made - a
number which will, on the average, be the same length as the
message.

It hardly seems a worthwhile example.

>They say LZW and MTF. I have already given an example for LZW.
>They don't care. I've told them to take any random string taken
>from /dev/random under Linux. They don't care. The german principle is
>that a faculty is always right by definition.

That is inconsistent with the advancement of knowledge.  Any
university relying on such a principle has abandoned its duty.

				Bear

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From bear at sonic.net  Wed Sep  1 14:30:04 2004
From: bear at sonic.net (bear)
Date: Wed, 1 Sep 2004 11:30:04 -0700 (PDT)
Subject: Compression theory reference?
In-Reply-To: <413523BE.10809@av8n.com>
References: <20040831124800.GA6167@danisch.de> <4134E5F9.8040200@av8n.com>
 <273CA598-FB9A-11D8-891B-000A95A0BF96@fnal.gov> <413523BE.10809@av8n.com>
Message-ID: <Pine.LNX.4.58.0409011117230.4934@bolt.sonic.net>



On Tue, 31 Aug 2004, John Denker wrote:

> I emphasize that I am only discussing messages of length N,
> where N is some pre-chosen number.  For concreteness, let's
> choose N=10.

> I repeat my assertion that _if_ XX can compress any string,
> shortening it by one bit, and _if_ you know that the original
> messages each have exactly 10 bits, _then_ any 10-bit message
> can be compressed down to a single bit.

Actually you don't need to take it all the way to the
reductio ad absurdum here.  There are 1024 10-bit
messages.  There are 512 9-bit messages.  You need
to point out that since a one-to-one mapping between
sets of different ordinality cannot exist, it is not
possible to create something that will compress every
ten-bit message by one bit.

Or, slightly more formally, assume that a function C
can reversibly compress any ten-bit message by one bit.
Since there are 1024 distinct ten-bit messages, there
must be at least 1024 distinct nine-bit messages which,
when the reversal is applied, result in these 1024
messages.  There are exactly 512 distinct nine-bit
messages.  Therefore 512 >= 1024.

			Bear

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From bear at sonic.net  Wed Sep  1 14:43:43 2004
From: bear at sonic.net (bear)
Date: Wed, 1 Sep 2004 11:43:43 -0700 (PDT)
Subject: Implementation choices in light of recent attacks?
In-Reply-To: <B0C0E07C-FC33-11D8-A6CC-000A95BD758E@mad-scientist.com>
References: <B0C0E07C-FC33-11D8-A6CC-000A95BD758E@mad-scientist.com>
Message-ID: <Pine.LNX.4.58.0409011140420.4934@bolt.sonic.net>



On Wed, 1 Sep 2004, Jim McCoy wrote:

>After digesting the various bits of information and speculation on the
>recent breaks and partial attacks on various popular hash functions I
>am wondering if anyone has suggestions for implementation choices for
>someone needing a (hopefully) strong hash today, but who needs to keep
>the hash output size in the 128-192 bit range.  A cursory examination
>of Tiger seems to indicate that it uses a different methodology than
>the MDx & SHAx lines, does this mean that it does not suffer from the
>recent hash attacks?  Would a SHA256 that has its output chopped be
>sufficient?
>
>Any suggestions would be appreciated.

I believe that SHA256 with its output cut to 128 bits will be
effective.  The simplest construction is to just throw away
half the bits.

			Bear

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From Marcel_Popescu at microbilt.com  Wed Sep  1 14:52:40 2004
From: Marcel_Popescu at microbilt.com (Marcel Popescu)
Date: Wed, 1 Sep 2004 21:52:40 +0300
Subject: "Approximate" hashes
References: <20040901180729.ECCED57E2C@finney.org>
Message-ID: <0dcb01c49054$db2f4fa0$726e9cd9@mark>

From: ""Hal Finney"" <hal at finney.org>

> As you are probably aware, existing hashcash implementations do not base
> the stamp on the message content.  Instead they only lock the stamp to
> the receiver's email address.  Then the receiver keeps a list of the
> hashcash stamps he has seen recently, to prevent reuse.  I'm not sure
> what you hope to gain by locking the stamp to the message content.

Me dumb, sorry. I was actually thinking of some other thing I wanted to do
about spam (which involved the whole content), and haven't re-read the
hashcash site in about a week.

You are perfectly right, of course. Windows spam victims, here I come! <g>

Thanks,
Marcel

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From dahonig at cox.net  Wed Sep  1 14:45:31 2004
From: dahonig at cox.net (David Honig)
Date: Wed, 01 Sep 2004 11:45:31 -0700
Subject: "Approximate" hashes
In-Reply-To: <0c4c01c49034$bc1999b0$726e9cd9@mark>
Message-ID: <3.0.5.32.20040901114531.0099d7c0@pop.west.cox.net>

At 06:02 PM 9/1/04 +0300, Marcel Popescu wrote:
>From: "Marcel Popescu" <Marcel_Popescu at microbilt.com>
>
>> Hence my question: is there some "approximate" hash function (which I
>could
>> use instead of SHA-1) which can verify that a text hashes "very close" to
>a
>> value? So that if I change, say, tabs into spaces, I won't get exactly the
>> same value, but I would get a "good enough"?

This is completely what secure hashes are supposed to prevent.  *Any* change
in the input will flip half the hash-bits on average.  Just like a block
cipher.  There is no input "nearness" preservation.  That's part of the point
of the algorithm.


>I just had an idea. Would this work?
>
>- let S be the input string, whose hash I want to verify
>- make S uppercase
>- remove everything but A-Z, 0-9, and common punctuation (!;:'",.?)
>- calculate the SHA1 hash of the result
>
>This should keep any insignificant changes out of the final result. 

You can encode your message in some format which is not subject
to mangling, and use a hash of that encoding.  You can then
decode the encoding back into unicode or whatever funky but
net-fragile character set you like.  This is somewhat like
ascii-armoring of PGP-encrypted messages.





=================================================
36 Laurelwood Dr
Irvine CA 92620-1299

VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP

ICBM: -117.7621, 33.7275
HTTP: http://68.5.216.23:81 (back up, but not 99.999% reliable)
PGP PUBLIC KEY: by arrangement

Send plain ASCII text not HTML lest ye be misquoted

------

"Don't 'sir' me, young man, you have no idea who you're dealing with"
Tommy Lee Jones, MIB

----

No, you're not 'tripping', that is an emu ---Hank R. Hill

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From themel at iwoars.net  Wed Sep  1 14:59:28 2004
From: themel at iwoars.net (Thomas Themel)
Date: Wed, 1 Sep 2004 20:59:28 +0200
Subject: Kerberos Design
Message-ID: <20040901185928.GB31570@iwoars.net>

Hi,

I'm currently looking into implementing a single sign-on solution for
distributed services. 

The requirement profile seems to somewhat fit Kerberos, but I'm
not entirely convinced that I can use it in my scenario - which can't
simply run an off-the-shelf KDC and use UDP for communication with it.

However, years of reading various crypto resources have strongly
conditioned me against simple-minded attempts to "roll my own" as a
crypto dilletante.

I've been trying to study Kerberos' design history in the recent past
and have failed to come up with a good resource that explains why things
are built the way they are. 

Since I'm already using OpenSSL for various SSL/x.509 related things,
I'm most astonished by the almost total absence of public key
cryptography in Kerberos, and I haven't been able to find out why this
design choice was made - performance reasons, given that at its
inception public key operation cost was probably much more prohibitive?

So, I'd like to ask the audience:

- Is there a good web/book/whatever resource regarding the design
  of Kerberos? Amazon offers the O'Reilly book, which, from the 
  abstract, seems to take the cryptographic design of Kerberos as 
  a given and concentrates on its usage, and another one that also
  doesn't seem to give much detail on the issue. Something in the
  direction of EKR's SSL/TLS book would be very much appreciated.

- Is Kerberos a sane choice to adapt for such solutions today?
  Is there anything more recent that I should be aware of?

thanks,
-- 
[*Thomas  Themel*] 
[extended contact] But let your communication be, Yea, yea; Nay, nay: 
[info provided in] for whatsoever is more than these cometh of evil.
[*message header*]      - Matthew 5:37
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20040901/143cce35/attachment.pgp>

From keith at nullify.org  Wed Sep  1 15:27:43 2004
From: keith at nullify.org (Keith Ray)
Date: Wed, 1 Sep 2004 14:27:43 -0500
Subject: "Approximate" hashes
In-Reply-To: <0c4601c49033$caecb9a0$726e9cd9@mark>
Message-ID: <200409011927.i81JRhFN020024@nullify.org>

> -----Original Message-----
> From: owner-cryptography at metzdowd.com 
> [mailto:owner-cryptography at metzdowd.com] On Behalf Of Marcel Popescu
> Sent: Wednesday, September 01, 2004 9:56 AM
> To: cryptography at metzdowd.com
> Subject: "Approximate" hashes
> 
> I am trying to build a Windows anti-spam thingy; it's 
> supposed to "sit" in
> between the mail client and the outer world, and indicate through mail
> headers whether the incoming mail has a valid hashcash
> http://www.hashcash.org/ "coin" (and, of course, to automatically add
> hashcash to outgoing emails).
> 
> My problem is that I don't know what happens with the email in transit
> (this, I believe, is an observation in the hashcash FAQ). I 
> am worried that
> some mail server might dislike ASCII characters with the high 
> bit set, or
> that a client uses some encoding which for some reason 
> doesn't make it to
> the destination unchanged.
> 
> Hence my question: is there some "approximate" hash function 
> (which I could
> use instead of SHA-1) which can verify that a text hashes 
> "very close" to a
> value? So that if I change, say, tabs into spaces, I won't 
> get exactly the
> same value, but I would get a "good enough"?
> 
> I don't know if this is possible. But if it is, I though this 
> would be a
> good place to find out about it.

nilsimsa

Computes nilsimsa codes of messages and compares the codes and finds
clusters of similar messages so as to trash spam.

What's a nilsimsa code?

A nilsimsa code is something like a hash, but unlike hashes, a small change
in the message results in a small change in the nilsimsa code.

http://lexx.shinn.net/cmeclax/nilsimsa.html

 --
Keith Ray <keith at nullify.org> -- OpenPGP Key: 0x79269A12

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From daw at cs.berkeley.edu  Wed Sep  1 16:19:09 2004
From: daw at cs.berkeley.edu (David Wagner)
Date: Wed, 1 Sep 2004 13:19:09 -0700 (PDT)
Subject: ?splints for broken hash functions
Message-ID: <200409012019.i81KJ9k5024341@taverner.CS.Berkeley.EDU>

Hal Finney writes:
>[John Denker proposes:] the Bi are the input blocks:
>  (IV) -> B1 -> B2 -> B3 -> ... Bk -> H1
>  (IV) -> B2 -> B3 -> ... Bk -> B1 -> H2
>then we combine H1 and H2 nonlinearly.

This does not add any strength against Joux's attack.  One can find
collisions for this in 80*2^80 time with Joux's attack.

First, generate 2^80 collisions for the top line.  Find B1,B1* that
produce a collision, i.e., C(IV,B1)=C(IV,B1*)=V2.  Then, find B2,B2*
that produce a collision, i.e., C(V2,B2)=C(V2,B2*)=V3.  Continue to
find B3,B3*, ..., Bk,Bk*.  Note that we can combine this in any way
we like (e.g., B1, B2*, B3*, B4, .., Bk) to get 2^80 different messages
that all produce the same output in the top line (same H1).

Next, look at the bottom line.  For each of the 2^80 ways to combine
the above blocks, compute what output you get in the bottom line.
By the birthday paradox, you will find some pair that produce a
collision in the bottom line (same H2).  But that pair also produces
a collision in the top line (since all pairs collide in the top line),
so you have a collision for the whole hash (same H1,H2).

>[...] how about this simpler construction?
>  (IV1) -> B1 -> B2 -> B3 -> ... Bk -> H1
>  (IV2) -> B1 -> B2 -> B3 -> ... Bk -> H2
>and again combine H1 and H2.

The same attack applies.  This construction is not secure against
Joux's attack, either.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From jerrold.leichter at smarts.com  Wed Sep  1 18:05:24 2004
From: jerrold.leichter at smarts.com (Jerrold Leichter)
Date: Wed, 1 Sep 2004 18:05:24 -0400 (EDT)
Subject: "Approximate" hashes
In-Reply-To: <200409011927.i81JRhFN020024@nullify.org>
References: <200409011927.i81JRhFN020024@nullify.org>
Message-ID: <Pine.GSO.4.58.0409011804290.10792@frame>

| nilsimsa
| Computes nilsimsa codes of messages and compares the codes and finds
| clusters of similar messages so as to trash spam.
|
| What's a nilsimsa code?
|
| A nilsimsa code is something like a hash, but unlike hashes, a small change
| in the message results in a small change in the nilsimsa code.
|
| http://lexx.shinn.net/cmeclax/nilsimsa.html
I had a look at the code (which isn't easy to follow).  This appears to be a
new application of Bloom filters.
							-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From jsd at av8n.com  Wed Sep  1 21:24:34 2004
From: jsd at av8n.com (John Denker)
Date: Wed, 01 Sep 2004 21:24:34 -0400
Subject: ?splints for broken hash functions
In-Reply-To: <200409012019.i81KJ9k5024341@taverner.CS.Berkeley.EDU>
References: <200409012019.i81KJ9k5024341@taverner.CS.Berkeley.EDU>
Message-ID: <41367652.5070400@av8n.com>

I wrote
 >> the Bi are the input blocks:
 >> (IV) -> B1 -> B2 -> B3 -> ... Bk -> H1
 >> (IV) -> B2 -> B3 -> ... Bk -> B1 -> H2
 >>then we combine H1 and H2 nonlinearly.

   (Note that I have since proposed a couple of improvements,
    but I don't think they are relevant to the present remarks.)



David Wagner wrote:

> This does not add any strength against Joux's attack.  One can find
> collisions for this in 80*2^80 time with Joux's attack.
> 
> First, generate 2^80 collisions for the top line.  Find B1,B1* that
> produce a collision, i.e., C(IV,B1)=C(IV,B1*)=V2.  Then, find B2,B2*
> that produce a collision, i.e., C(V2,B2)=C(V2,B2*)=V3.  Continue to
> find B3,B3*, ..., Bk,Bk*.  Note that we can combine this in any way
> we like (e.g., B1, B2*, B3*, B4, .., Bk) to get 2^80 different messages
> that all produce the same output in the top line (same H1).

OK so far.  I think this assumes a sufficiently long input string,
but I'm willing to make that assumption.

> Next, look at the bottom line.  For each of the 2^80 ways to combine
> the above blocks, compute what output you get in the bottom line.

OK so far.

> By the birthday paradox,

Whoa, lost me there.

I thought H1 was fixed, namely the ordinarly has of the original
message.  Two questions:

   1) If H1 is fixed, I don't understand how birthday arguments apply.
    Why will trying the bottom line 2^80 times find me H@ equal to a
    particular fixed H1?  There are a whooooole lot more that 2^80
    	possibilities.

   2) If H1 is not fixed, then this seems to be an unnecessarily
    difficult way of saying that a 160-bit hash can be broken using
    2^80 work.  But we knew that already.  We didn't need Joux or
    anybody else to tell us that.

    A proposal that uses 80*2^80 work is particularly confusing, if
    H1 is not fixed.

> you will find some pair that produce a
> collision in the bottom line (same H2).  But that pair also produces
> a collision in the top line (since all pairs collide in the top line),
> so you have a collision for the whole hash (same H1,H2).

Still lost, for the same reasons.  Please explain.  Also if possible
please address the improved version, with different IVs and long-range
permutation of a partial block.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From bear at sonic.net  Wed Sep  1 23:30:09 2004
From: bear at sonic.net (bear)
Date: Wed, 1 Sep 2004 20:30:09 -0700 (PDT)
Subject: ?splints for broken hash functions
In-Reply-To: <200409012019.i81KJ9k5024341@taverner.CS.Berkeley.EDU>
References: <200409012019.i81KJ9k5024341@taverner.CS.Berkeley.EDU>
Message-ID: <Pine.LNX.4.58.0409012027280.592@bolt.sonic.net>



On Wed, 1 Sep 2004, David Wagner wrote:

>Hal Finney writes:
>>[John Denker proposes:] the Bi are the input blocks:
>>  (IV) -> B1 -> B2 -> B3 -> ... Bk -> H1
>>  (IV) -> B2 -> B3 -> ... Bk -> B1 -> H2
>>then we combine H1 and H2 nonlinearly.
>
>This does not add any strength against Joux's attack.  One can find
>collisions for this in 80*2^80 time with Joux's attack.
>
>First, generate 2^80 collisions for the top line.  Find B1,B1* that
>produce a collision, i.e., C(IV,B1)=C(IV,B1*)=V2.  Then, find B2,B2*
>that produce a collision, i.e., C(V2,B2)=C(V2,B2*)=V3.  Continue to
>find B3,B3*, ..., Bk,Bk*.  Note that we can combine this in any way
>we like (e.g., B1, B2*, B3*, B4, .., Bk) to get 2^80 different messages
>that all produce the same output in the top line (same H1).
>
>Next, look at the bottom line.  For each of the 2^80 ways to combine
>the above blocks, compute what output you get in the bottom line.
>By the birthday paradox, you will find some pair that produce a
>collision in the bottom line (same H2).  But that pair also produces
>a collision in the top line (since all pairs collide in the top line),
>so you have a collision for the whole hash (same H1,H2).

The birthday paradox does not apply in this case because H1 is fixed.
The above construction is in fact secure against the Joux attack as
stated.  2^80 work will find, on average, one collision.

				Bear

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From bill.stewart at pobox.com  Thu Sep  2 03:54:55 2004
From: bill.stewart at pobox.com (Bill Stewart)
Date: Thu, 02 Sep 2004 00:54:55 -0700
Subject: ?splints for broken hash functions
In-Reply-To: <41321F89.4090908@av8n.com>
References: <20040829165012.E9DD357E2D@finney.org>
 <41321F89.4090908@av8n.com>
Message-ID: <20040902075509.88279F28C@red.metdow.com>


>>how about this simpler construction?
>>   (IV1) -> B1 -> B2 -> B3 -> ... Bk -> H1
>>   (IV2) -> B1 -> B2 -> B3 -> ... Bk -> H2

This approach and the "cache Block 1 until the end" approach
are both special-case versions of "maintain more state" attacks.

This special case maintains 2*(size of hash output) bits of state.
The "cache block 1" case maintains
         (size of hash output) + (size of block 1) bits of state,
but doesn't change the (size of block 1) bits between cycles.
         (Also, if you're going to do that, could you maintain
         (hash(Block1)) bits between cycles instead of the raw bits?)

They both have some obvious simplicity to them,
but I'm not convinced that simplicity actually helps,
compared to other ways of getting more state.

Perhaps the effective state of the 2-IV version is
twice the size of the basic hash, perhaps it's less.
My intuition is that more mixing might be better,
and probably isn't worse, but I could easily be wrong.






---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From jon at callas.org  Thu Sep  2 04:26:45 2004
From: jon at callas.org (Jon Callas)
Date: Thu, 2 Sep 2004 01:26:45 -0700
Subject: "Approximate" hashes
In-Reply-To: <0c4601c49033$caecb9a0$726e9cd9@mark>
References: <0c4601c49033$caecb9a0$726e9cd9@mark>
Message-ID: <D35DD8BD-FCB9-11D8-AE21-000A9568596C@callas.org>

> Hence my question: is there some "approximate" hash function (which I 
> could
> use instead of SHA-1) which can verify that a text hashes "very close" 
> to a
> value? So that if I change, say, tabs into spaces, I won't get exactly 
> the
> same value, but I would get a "good enough"?
>

What you want is what's called a canonicalization function. You want to 
hash not T, but F(T), and F can de-tabify, and so on.

As has been mentioned, OpenPGP has a canonicalization for text and 
cleartext signatures (and we debate what it should be, even). XML 
Digital Signatures has one.

The major other issue you have to deal with is whether the 
canonicalization is an interpretation, a conversion, or an assurance.

If it's an interpretation, then you are hashing F(T), and there's 
always some slim chance that there's a collision between two texts that 
canonicalize to different values, but hash to the same. I wouldn't 
worry about it, myself. Much. (Assuming a decent canonicalizer, of 
course.)

If it's a conversion, then you're replacing the text with the 
canonicalized text. This puts the canonicalization in the face of the 
users, but removes the problems handwaved at above.

If it's an assurance, then if the text is not canonicalized, then it's 
not a valid message if it doesn't meet the requirements. A message with 
a tab, for example, just isn't a valid message. Don't even hash it, 
return an error. Or alert that it was an invalid message.

	Jon

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From bill.stewart at pobox.com  Thu Sep  2 04:36:04 2004
From: bill.stewart at pobox.com (Bill Stewart)
Date: Thu, 02 Sep 2004 01:36:04 -0700
Subject: Compression theory reference?
In-Reply-To: <Pine.LNX.4.58.0409011117230.4934@bolt.sonic.net>
References: <20040831124800.GA6167@danisch.de>
 <4134E5F9.8040200@av8n.com>
 <273CA598-FB9A-11D8-891B-000A95A0BF96@fnal.gov>
 <413523BE.10809@av8n.com>
 <Pine.LNX.4.58.0409011117230.4934@bolt.sonic.net>
Message-ID: <20040902083633.57410F28A@red.metdow.com>

It's a sad situation when you have to get a non-technical
judge to resolve academic conflicts like this,
but it's your head that you're banging against the wall, not mine.
If you want to appeal to authority, there's the FAQ,
which of course requires explaining the Usenet FAQ traditions;
perhaps you can find Lempel, Ziv, or Welch?

In reality, you could show an algorithm for which any input
gets at most _one_ bit longer, rather than arbitrarily longer.
And of course most of the compression algorithms work because
real data almost always has structure which reduces the entropy.
My information theory books from grad school have
long vanished into some closet, and were written
just about the time LZ came out so they mainly discuss
Huffman coding in the discrete-message sections,
but you should be able to find a modern book on the topic.

Matt Crawford's inductive argument is very strong -
it gives you a constructive way to say that
"for any integer N, I can give a proof for that N",
starting at 1 and working your way up,
showing that if there's a lossless coding that doesn't make
any messages of length N any longer, then it doesn't make any any shorter,
so it's not a compression method, just a permutation.

The "You could compress any message down to 1 bit"
argument is a great throwaway line, but it isn't rigorously valid.
(And if it were, you might as well compress down to zero bits while you're 
at it.)
The problem is that for most lossless compression algorithms,
some strings will get shorter (maybe even much shorter),
but some will stay the same length,
so even if you had a hypothetical "never gets longer"
compression algorithm, you can't guarantee that your
starting message would be one that got shorter as opposed to staying the same,
so you can't say that all messages would compress to zero.

If your judge doesn't like inductions that count up,
or your academic opponents insist on examining methods that count down,
Bear's argument gets you most of the way there,
by emphasizing the 1-1 mapping aspect, but you could easily get tangled.
(To do this properly, you need to do n and 2**n, but I'll use 10 for 
concreteness.)

There are 1024 10-bit messages, and only 512 9-bit messages,
so something obviously happened to the >=512 that didn't compress to 9 bits.
Maybe 512 of them didn't compress further and stayed as 10-bit;
almost certainly some of them became 8 bits or shorter.
At least one message didn't get shorter, because
         (2**10 - 1) = 2**9 + 2**8 + 2**7 ... + 2**1
So if you want to recurse downwards through repeated compression,
you need to be sure your mapping keeps track of the ones that
didn't compress the first time (maybe they'll compress the second time?),
the ones that compressed by one bit,
and the ones that compressed by more than one bit,
and avoid wandering around in a maze of twisty little passages.

So working your way up is probably cleaner.


At 11:30 AM 9/1/2004, bear wrote:
>Actually you don't need to take it all the way to the
>reductio ad absurdum here.  There are 1024 10-bit
>messages.  There are 512 9-bit messages.  You need
>to point out that since a one-to-one mapping between
>sets of different ordinality cannot exist, it is not
>possible to create something that will compress every
>ten-bit message by one bit.
>
>Or, slightly more formally, assume that a function C
>can reversibly compress any ten-bit message by one bit.
>Since there are 1024 distinct ten-bit messages, there
>must be at least 1024 distinct nine-bit messages which,
>when the reversal is applied, result in these 1024
>messages.  There are exactly 512 distinct nine-bit
>messages.  Therefore 512 >= 1024.
>
>                         Bear
>
>---------------------------------------------------------------------
>The Cryptography Mailing List
>Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

----
Bill Stewart  bill.stewart at pobox.com 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From bill.stewart at pobox.com  Thu Sep  2 04:50:44 2004
From: bill.stewart at pobox.com (Bill Stewart)
Date: Thu, 02 Sep 2004 01:50:44 -0700
Subject: "Approximate" hashes
In-Reply-To: <200409011927.i81JRhFN020024@nullify.org>
References: <0c4601c49033$caecb9a0$726e9cd9@mark>
 <200409011927.i81JRhFN020024@nullify.org>
Message-ID: <20040902085102.68C26F28A@red.metdow.com>


> > On Behalf Of Marcel Popescu
>...
> > My problem is that I don't know what happens with the email in transit
> > (this, I believe, is an observation in the hashcash FAQ). I
> > am worried that some mail server might dislike ASCII characters with ....
> >
> > Hence my question: is there some "approximate" hash function
> > (which I could > use instead of SHA-1) which can verify that a
> > text hashes  "very close" to a value?

At 12:27 PM 9/1/2004, Keith Ray wrote:
>nilsimsa
>Computes nilsimsa codes of messages and compares the codes and finds
>clusters of similar messages so as to trash spam.

Check out Vipul's Razor, which uses an approach similar to this.
You'll find information at Cloudmark and on Sourceforge.

There are several different kinds of differences to work around -
- damage in transit, as noted, though it's the least of your worries
         in spite of Unicode, MS Codesets, and 8-bit-uncleanness
- different mail headers getting added or subtracted or mimed
         (Some people include relevant parts in their message indexes, some 
don't.)
- deliberate differences introduced in the message to discourage detection,
         ranging from the simple "Dear Alice"/"Dear Bob" to
         removal addresses than encode each spam victim's info,
         to different random word-scramble that's also there to
         discourage Bayesian spam-detectors.
         This one's really common these days, especially as mail systems
         have decreased the number of users they'll send to
         in a given SMTP session / envelope because of spamming -
         if you can only spam 5-10 recipients per TCP session,
         might as well make each session somewhat different
         so you only get hit by local detectors, not global indexers.

Vipul's Razor and related approaches try to calculate a unique id
for each message so that if a human detects that a message is spam,
the id can be published so everybody else trashes it.
This usually needs more than one human rating something as spam
to prevent abuse, and there's some tuning, but it's a good start.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From Carlos.Cid at rhul.ac.uk  Thu Sep  2 05:06:53 2004
From: Carlos.Cid at rhul.ac.uk (Cid Carlos)
Date: Thu, 2 Sep 2004 10:06:53 +0100 
Subject: Kerberos Design
Message-ID: <0580F806F396E546B6505E66431AB1430331671D@exch7.rhul.ac.uk>

Hi,

You may want to have a look at these:

- Designing an Authentication System: a Dialogue in Four Scenes
(http://web.mit.edu/kerberos/www/dialogue.html)
- Limitations of the Kerberos Authentication System, Steven M. Bellovin, and
Michael Merrit, 1991 
(http://www.cybersafe.ltd.uk/docs_other/Limitations%20of%20the%20Kerberos%20
Authentication%20System.pdf)

Carlos

==================


Hi,

I'm currently looking into implementing a single sign-on solution for
distributed services. 

The requirement profile seems to somewhat fit Kerberos, but I'm not entirely
convinced that I can use it in my scenario - which can't simply run an
off-the-shelf KDC and use UDP for communication with it.

However, years of reading various crypto resources have strongly conditioned
me against simple-minded attempts to "roll my own" as a crypto dilletante.

I've been trying to study Kerberos' design history in the recent past and
have failed to come up with a good resource that explains why things are
built the way they are. 

Since I'm already using OpenSSL for various SSL/x.509 related things, I'm
most astonished by the almost total absence of public key cryptography in
Kerberos, and I haven't been able to find out why this design choice was
made - performance reasons, given that at its inception public key operation
cost was probably much more prohibitive?

So, I'd like to ask the audience:

- Is there a good web/book/whatever resource regarding the design
  of Kerberos? Amazon offers the O'Reilly book, which, from the 
  abstract, seems to take the cryptographic design of Kerberos as 
  a given and concentrates on its usage, and another one that also
  doesn't seem to give much detail on the issue. Something in the
  direction of EKR's SSL/TLS book would be very much appreciated.

- Is Kerberos a sane choice to adapt for such solutions today?
  Is there anything more recent that I should be aware of?

thanks,
-- 
[*Thomas  Themel*] 
[extended contact] But let your communication be, Yea, yea; Nay, nay: 
[info provided in] for whatsoever is more than these cometh of evil.
[*message header*]      - Matthew 5:37

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From crypto at ovillatx.sytes.net  Thu Sep  2 10:11:53 2004
From: crypto at ovillatx.sytes.net (lrk)
Date: Thu, 2 Sep 2004 09:11:53 -0500
Subject: How thorough are the hash breaks, anyway?
In-Reply-To: <30F37C4533D8564FB1D58BFDAF6687C1EA7942@ohthree.jjj-i.com>
References: <30F37C4533D8564FB1D58BFDAF6687C1EA7942@ohthree.jjj-i.com>
Message-ID: <20040902141153.GA243@ovillatx.sytes.net>

On Tue, Aug 31, 2004 at 02:45:29PM -0400, Whyte, William wrote:
>
> My understanding is that once you've used trial division to
> get rid of all the extremely short divisors, a random number 
> of length n is about as hard to factor as an RSA modulus of
> the same length. I don't think there are a lot of easy-to-factor 
> moduli around.

One would think that the more one knows about the factors, the easier
factoring would be. Since we know an RSA modulus contains exactly two
primes, usually each half the length of the modulus, factoring an RSA
modulus should be easier than factoring a random number of about the same
size. This depends, of course, on being able to use a method which takes
advantage of the additional information.

The simple case for factoring easy RSA modulii occurs when the primes 
are too close together rather than being small.

Other easy cases are based on other accidental characteristics.


-- 
crypto at ovillatx.sytes.net

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From jsd at av8n.com  Thu Sep  2 13:26:41 2004
From: jsd at av8n.com (John Denker)
Date: Thu, 02 Sep 2004 13:26:41 -0400
Subject: Compression theory reference?
In-Reply-To: <20040831222319.GC29492@danisch.de>
References: <20040831124800.GA6167@danisch.de> <4134E5F9.8040200@av8n.com> <273CA598-FB9A-11D8-891B-000A95A0BF96@fnal.gov> <20040831222319.GC29492@danisch.de>
Message-ID: <413757D1.6080208@av8n.com>

Matt Crawford wrote:

 >>Plus a string of log(N) bits telling you how many times to apply the
 >>decompression function!
 >>Uh-oh, now goes over the judge's head ...

Hadmut Danisch wrote:

> The problem is that if you ask for a string of log(N) bits, then 
> someone else could take this as a proof that this actually works, 
> because a string of log(N) bits is obviously shorter than the 
> message of N bits, thus the compression scheme is working. Hooray!

That misses the point of the construction that was the subject of
Matt's remark.  The point was (and remains) that the compressed
output (whether it be 1 bit, or 1+log(N) bits, or 1+log^*(N) bits)
is ridiculous because it is manifestly undecodeable.  It is far, far
too good to be true.

The only question is whether the construction is simple enough
for the judge to understand.

There is no question whether the construction is a valid _reductio
ad absurdum_.

   While we are on the subject, I recommend the clean and elegant
   argument submitted by Victor Duchovni (08/31/2004 03:50 PM) and
   also in more detail by Matt Crawford (08/31/2004 06:04 PM).  It
   uses mathematical induction rather than proof-by-contradiction.
   It is a less showy argument, but probably it is understandable
   by a wider audience.  It proves a less-spectacular point, but it
   is quite sufficient to show that the we-can-compress-anything
   claim is false.  (Although with either approach, at least *some*
   mathematical sophistication is required.  Neither PbC nor MI will
   give you any traction with ten-year-olds.)

   So it appears we have many different ways of approaching things:

    1) The pigeon-hole argument.  (This disproves the claim that all
     N-bit strings are compressible ... even if the claim is restricted
     to a particular fixed N.)

    2) The mathematical induction argument.  (Requires the claimed
     algorithm to be non-expansive for a range of N.)

    3) The proof-by-contradiction.  (Requires the claimed algorithm
     to be compressive -- not just non-expansive -- for a range of N.)

    4) Readily-demonstrable failure of *any* particular claimed example,
     including Lempel-Ziv and all the rest.

    *) Others?

   Harumph.  That really ought to be enough.  Indeed *one* disproof
   should have been enough.

> The problem is, that the number of iterations is not in the order of 
> N, but in the order of 2^N, so it takes log2(around 2^N) = around N bits to
> store the number of iterations.

I don't see why the number of iterations should be exponential in
the length (N) of the input string.  A compression function is
supposed to decrease N.  It is not supposed to decrement the
number represented by some N-bit numeral .... after all, the string
might not represent a number at all.

Also I repeat that there exist special cases (e.g. inputs of
known fixed length) for which no extra bits need be represented,
as I explained previously.

> The recursion convertes a message of 
> N bit recursively into a message of 1 or zero bit length (to your
> taste), *and* a number which takes around N bit to be stored. 
> Nothing is won. But proof that. 

I disagree, for the reasons given above.

In the worst case, you need log^*(N) extra bits, not N bits.  In
special cases, you don't need any extra bits at all.  The "win"
is very substantial.  The "win" is extreme.

> This recursion game is far more complicated than it appears to be. 

Maybe.  But there's no need to make it more complicated than it
really is.

> Note also that storing a number takes in reality more than log(N)
> bits. Why? Because you don't know N in advance. We don't have any
> limit for the message length. 

For general N, that's true.

 > So you'r counting register needs
> theoretically inifinte many bits. 

Maybe.  For many practical purposes, the required number of bits
is considerably less than infinity.

 > When you're finished you know
> how many bits your number took. But storing your number needs an 
> end symbol or a tristate-bit (0,1,void). That's a common mistake. 

We agree that there are many common mistakes.  We agree that
it is a mistake to have undelimited strings.  But it is also a
mistake to think that you need to reserve a special symbol to
mark the end of the string.  Yes, that is one option, but from a
data-compression point of view it is an inefficient option.

Anybody who is interested in this stuff reeeally ought to read
Chaitin's work.  He makes a big fuss about the existence of
self-delimiting strings and self-delimiting programs.  There
are many examples of such:
  -- The codewords of many commonly-used compression algorithms
   are self-delimiting.  This is related to the property of being
   "instantaneously decodable".
  -- As Chaitin points out, you can set up a dialect of Lisp such
   that Lisp programs are self-delimiting.
  -- If you want to be able to represent M, where M is *any* N-bit
   number, you need more than log(M) bits (i.e. more than N bits).
   That's because you need to specify how many bits are used to
   represent log(M), which adds another log(log(M)) bits.  On top
   of that, you need to specify how many bits are used to specify
   log(log(M)), which adds another ..... you get the idea.
   Fortunately the series converges verrry fast.  This series
   defines a new function, named log^*(), pronounced log-star.
   Constructive examples are known of representation schemes
   that give a self-delimiting representation of *any* integer,
   no matter how large.  These are called 'universal' representations.
-- etc. etc. etc.

I'm not suggesting that the judge needs to understand the log^*
function ... just that it is a mistake to assume that a special
end-marker is needed.  Also I'm suggesting that if you give
examples of the encoding/decoding process, make sure you
indicate whatever metadata (if any!) is required to make the
input and output words properly delimited.  (You will notice
that in the example I posted of diagramming the pigeon-hole
argument, all my words were instantaneously decodable and
therefore self-delimiting.  No metadata required.  No reserved
end-symbol required.)  You don't need to make a big fuss about
it, just make sure the requirements are met, in case anybody
decides to check.  In most cases you can duck the issue entirely
by saying that you are compressing "objects".  It is often not
necessary to specify which part of the object is considered
metadata and which part is considered payload.

> When determining the compression rate for a file people often 
> forget, that some information is not stored in the file itself, but in
> the file system, e.g. the file length (telling where the compressed
> data stops) and the file name (telling you, that the file was
> compressed). That's basically the same problem.

Yes, it's the same problem, or at least a closely-related problem.

In any case it is a solvable problem.

Note that the *filesystem* itself must be self-delimiting.  So it
must have a self-delimiting way of representing the name of the file
and the length of the file, et cetera.  In many cases the filesystem
wimps out and places artificial (perhaps huge) limits on the filesize,
but one could readily fix things up to use a universal representation.

When comparing compressors, IMHO the only fair thing to do is to
consider this metadata in the filesystem to be part of the *object*
to be compressed.  Theoretically this is more-or-less tantamount to
restricting the discussion to inputs and outputs that are
self-delimiting.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From eugen at leitl.org  Fri Sep  3 04:44:15 2004
From: eugen at leitl.org (Eugen Leitl)
Date: Fri, 3 Sep 2004 10:44:15 +0200
Subject: [wearables] CFP: Workshop on Pervasive Computing and Communication Security (fwd from tech-wearables@bobmayo.com)
Message-ID: <20040903084415.GM1458@leitl.org>

From: Bob Mayo <tech-wearables at bobmayo.com>
Subject: [wearables] CFP: Workshop on Pervasive Computing and Communication Security
To: wearables at cc.gatech.edu
Date: Thu, 2 Sep 2004 16:36:15 -0700 (PDT)
Reply-To: tech-wearables at bobmayo.com




                            CALL FOR PAPERS

                              PerSec 2005

     Second IEEE International Workshop on Pervasive Computing and
                         Communication Security

               Held in conjunction with IEEE PerCom 2005

                8 March 2005, Kauai island, Hawaii, USA

                  http://www.cl.cam.ac.uk/persec-2005/


Research in pervasive computing continues to gain momentum. The importance of
security and privacy in a pervasive computing environment cannot be
underestimated. PerSec 2005 will bring together the world's experts on this
topic and provide an international forum to stimulate and disseminate original
research ideas and results in this field.

Contributions are solicited in all aspects of security and privacy in pervasive
computing, including:

Models for access control, authentication and privacy management.

Incorporation of contextual information into security and privacy models, and
mechanisms.

Management of tradeoffs between security, usability, performance, power
consumption and other attributes.

Architectures and engineering approaches to fit security and privacy features
into mobile and wearable devices.

Biometric methods for pervasive computing.

Descriptions of pilot programs, case studies, applications, and experiments
integrating security into pervasive computing.

Auditing and forensic information management in pervasive settings.

Protocols for trust management in networks for pervasive computing.

Incorporation of security into communication protocols, computing architectures
and user interface designs for pervasive computing.

Impact of security and privacy in relation to the social, legal, educational
and economic implications of pervasive computing.



INSTRUCTIONS FOR AUTHORS
========================

Papers must be sent to persec-2005 at cl.cam.ac.uk as file attachments in Adobe
PDF format.

Papers must have authors' affiliation and contact information on the first
page.

Papers must be unpublished and not being considered elsewhere for publication.
In particular, papers submitted to PerSec must not be concurrently submitted to
PerCom in identical or modified form.

Papers must be formatted in strict accordance with the IEEE Computer Society
author guidelines published at
ftp://pubftp.computer.org/Press/Outgoing/proceedings/INSTRUCT.HTM. For your
convenience, templates are available at
ftp://pubftp.computer.org/Press/Outgoing/proceedings/. LaTeX is recommended.

Papers are limited to 5 pages in IEEE 8.5x11 conference
format. Excessively long papers will be returned without review.

Papers selected for presentation will be published in the Workshop Proceedings
of PerCom 2005 by IEEE Press.


IMPORTANT DATES
===============

Paper submission: 13 September 2004

Acceptance Notification: 15 November 2004

Camera-ready manuscripts: 29 November 2004

PerSec Workshop: 8 March 2005 (first day of PerCom, which runs until the 
12th)


PROGRAM CO-CHAIRS
=================

     * Frank Stajano, University of Cambridge, UK
     * Roshan Thomas, McAfee Research, USA


SECRETARY
=========

     * Boris Dragovic, University of Cambridge, UK

Contact email (goes to co-chairs and secretary): persec-2005 at 
cl.cam.ac.uk


STEERING COMMITTEE CHAIR
========================

     * Ravi Sandhu, George Mason University, USA


PROGRAM COMMITTEE
=================

     * Tuomas Aura, Microsoft Research, UK
     * Mark Corner, UMass, USA
     * Srini Devadas, MIT, USA
     * Boris Dragovic, University of Cambridge, UK
     * Naranker Dulay, Imperial College, UK
     * Kris Gaj, George Mason University, USA
     * Robert Grimm, NYU, USA
     * Dieter Hutter, DFKI, Germany
     * Ari Juels, RSA Laboratories, USA
     * Tim Kindberg, HP Labs Bristol, UK
     * Cetin Kaya Koc, Oregon State University, USA
     * Marc Langheinrich, ETH Zurich, Switzerland
     * Mark Lomas, BIICL, UK
     * Robert N. Mayo, HP Labs Palo Alto, USA
     * Refik Molva, Eurecom, France
     * Kai Rannenberg, University of Frankfurt, Germany
     * Stephen Weis, MIT

----------

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20040903/9be7e9e0/attachment.pgp>

From rabbi at abditum.com  Fri Sep  3 09:04:20 2004
From: rabbi at abditum.com (Len Sassaman)
Date: Fri, 3 Sep 2004 06:04:20 -0700 (PDT)
Subject: "Approximate" hashes
In-Reply-To: <0c4601c49033$caecb9a0$726e9cd9@mark>
References: <0c4601c49033$caecb9a0$726e9cd9@mark>
Message-ID: <Pine.LNX.4.58.0409030558310.8598@thetis.deor.org>

On Wed, 1 Sep 2004, Marcel Popescu wrote:

> Hence my question: is there some "approximate" hash function (which I could
> use instead of SHA-1) which can verify that a text hashes "very close" to a
> value? So that if I change, say, tabs into spaces, I won't get exactly the
> same value, but I would get a "good enough"?

Hi Marcel,

You may wish to look at Cmeclax's nilsimsa. It has been used to detect
slightly-modified message floods in anonymous remailer systems, and was
also used in Spamassassin at some point.

http://lexx.shinn.net/cmeclax/nilsimsa.html



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From kelsey.j at ix.netcom.com  Fri Sep  3 09:36:49 2004
From: kelsey.j at ix.netcom.com (John Kelsey)
Date: Fri, 3 Sep 2004 09:36:49 -0400 (GMT-04:00)
Subject: ?splints for broken hash functions
Message-ID: <16557184.1094218609720.JavaMail.root@bert.psp.pas.earthlink.net>

>From: "\"Hal Finney\"" <hal at finney.org>
>Sent: Sep 1, 2004 1:55 PM
>To: cryptography at metzdowd.com, kelsey.j at ix.netcom.com
>Subject: Re: ?splints for broken hash functions

>John Kelsey critiques the proposal from Practical Cryptography: 
...
> I believe this falls to a generalization of the Joux attack, as
>well.  (Someone may have already noticed this.)

> a.  I build a 2^{80} multicollision on h(m) using Joux' attack,
>requiring 80*2^{80} work.

> b.  I now have 2^{80} different messages which are being hashed with
>the same IV.  I expect one pair of them to give me a collision.

>You did 80*2^80 work to create a collision.  But you could create a
>collision without all this effort in only 2^80 work, by a conventional
>birthday attack.  Just ignore the internal structure and treat it as
>a 160 bit hash function and you can collide in 2^80 work.  You worked
>harder than you needed to, so this is not a break.

Ah, good point.  I honestly was just trying to see if this
construction gave inherent resistance to the Joux attack, and it
doesn't.  That means you still have to do 2^{80} work to get your
first collision, but you can get multicollisions a lot more cheaply
than you'd expect.  

Let's consider a slightly simpler version of the Practical
Cryptography scheme, and I'll show how to get K-collisions on it for
about lg(K)^2 2^{80} work, as opposed to lg(K) 2^{80} work for a
standard hash function.  I'll call this variant the "two pass hash:"

hash'(x) = hash( x || x )

a.  I produce a message with 80 * 80 = 6400 blocks, in which each
message block is a collision pair.  I thus do about 2^{93} work, in
order to use Joux' attack to find a 2^{6400}-collision on hash(x).

b.  I now break the message into superblocks of 80 blocks, which I'll
call B[0],B[1],...,B[79].  Note that for each of the 2^{80} possible
values for a superblock, the result of hash(x) is identical.  (In
practice, I'll probably need a few extra blocks in each superblock to
deal with the collision search taking longer than expected sometimes.)  

c.  For each superblock, I try as many of the 2^{80} possible
sequences of message blocks as I need (which all collide for hash(x)),
until I find one that causes a collision in the second pass, as well.

The total work is dominated by the 6400*2^{80} search at the
beginning, and so we get a set of 2^{80} messages with the same result
from the two-pass hash using this variant of Joux' attack, for about
2^{93} work total.  Is there a better way to mount this kind of attack
on this scheme?  Unless I'm missing something, we can iterate this
attack for more passes in a pretty straightforward way: for P passes
of the hash over the message, when we want a K-collision, we need
lg(K) distinct pieces of the message which are 2^{n/2} collisions for
the P-1 pass hash. 

Now, applying this to the Practical Cryptography scheme is complicated
a bit by the fact that the message handled by the second pass doesn't
break into blocks in quite the same way (it's offset by the number of
bits in the hash output).  However, this doesn't prevent the attack,
it just restricts which bits of the message blocks you can play with
when finding collisions.  

For concreteness, think of SHA1, with 5-word hash output blocks and
16-word message blocks.  Now, each of our superblocks from the first
pass of hashing are offset five words into the next superblock.  That
means that the last colliding message block in each superblock needs
to have no changed bits in its last 5 words.

So, what this means is that you can still find multicollisions on
these variant ways of hashing (the two-pass and Practical Cryptography
constructions) much more quickly than you'd expect from an ideal hash
function.  You can extend the result to convince yourself that you
can't get much more than 80 bits of collision resistance from
constructions like:

hash(X) = SHA1(X) || RIPE-MD160(SHA1(X)||X)

Comments?  

>Hal

--John Kelsey

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From kelsey.j at ix.netcom.com  Fri Sep  3 09:51:06 2004
From: kelsey.j at ix.netcom.com (John Kelsey)
Date: Fri, 3 Sep 2004 09:51:06 -0400 (GMT-04:00)
Subject: Implementation choices in light of recent attacks?
Message-ID: <13999005.1094219466923.JavaMail.root@bert.psp.pas.earthlink.net>

>From: bear <bear at sonic.net>
>Sent: Sep 1, 2004 2:43 PM
>To: Jim McCoy <mccoy at mad-scientist.com>
>Cc: cryptography at metzdowd.com
>Subject: Re: Implementation choices in light of recent attacks?

>On Wed, 1 Sep 2004, Jim McCoy wrote:

>>After digesting the various bits of information and speculation on the
>>recent breaks and partial attacks on various popular hash functions I
>>am wondering if anyone has suggestions for implementation choices for
>>someone needing a (hopefully) strong hash today, but who needs to keep
>>the hash output size in the 128-192 bit range.  A cursory examination
>>of Tiger seems to indicate that it uses a different methodology than
>>the MDx & SHAx lines, does this mean that it does not suffer from the
>>recent hash attacks?  Would a SHA256 that has its output chopped be
>>sufficient?
>>Any suggestions would be appreciated.

>I believe that SHA256 with its output cut to 128 bits will be
>effective.  The simplest construction is to just throw away
>half the bits.

Yes, but it does depend a little on what you're trying to defend against, right?  I mean, if you're worried about not having a strong hash function with a 128-bit output anymore, then it seems like you should always be able to truncate a stronger hash.  

If I had a way to force the low 128 bits of SHA1 to collide much faster than 2^{64}, while randomizing the remaining 32 bits, I could use it to find full SHA1 collisions faster than 2^{80}work.  This doesn't work if my trick for getting collisions in 128 bits requires that the remaining 32 bits not collide, however.  (This can happen if you have a truncated differential through the whole hash function whose output value is (x,0,0,0,0), e.g., it forces a nonzero difference into the first word of output.  I believe this came up in Biham and Chen's SHA0 near collisions, requiring running the differential across two or more compression functions.  The same basic problem came up in Biham and Shamir's N-HASH results, many years ago.  So you can't get a simple reduction proof here, but maybe someone better at proofs can do a more complicated one....

If you're worried about cryptanalysis of existing MD5-like functions, then there's probably some benefit to looking at alternative designs that look radically different, like Whirlpool or Tiger.  But I'm not sure how much analysis either has seen, so I'd be reluctant to feel like I really understood their security yet.  It's clear from recent events that "designed by smart people" isn't enough by itself to give you lots of confidence in hash functions, any more than in block ciphers.  

Finally, if you want to use truncation on hashes, make sure it's never possible to get the two sides confused about which hash is to be used.  There are a lot of places, such as KDFs, where you can get some really nasty attacks if you can get Alice to use SHA256 and Bob to use SHA256 with the output truncated to 224 bits.  (Yes, this is the reason SHA224 has a different starting IV than SHA256.) 

>			Bear

--John Kelsey

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From hal at finney.org  Fri Sep  3 13:20:22 2004
From: hal at finney.org (Hal Finney)
Date: Fri,  3 Sep 2004 10:20:22 -0700 (PDT)
Subject: ?splints for broken hash functions
Message-ID: <20040903172022.E827457E2A@finney.org>

John Kelsey writes:
> So, what this means is that you can still find multicollisions on
> these variant ways of hashing (the two-pass and Practical Cryptography
> constructions) much more quickly than you'd expect from an ideal hash
> function.  You can extend the result to convince yourself that you
> can't get much more than 80 bits of collision resistance from
> constructions like:
>
> hash(X) = SHA1(X) || RIPE-MD160(SHA1(X)||X)

Hi, John, yes, I see that works.  That's a very strong result.
David Wagner suggested almost exactly the same attack to me in private
email, with regard to the construction of running two parallel hashes.
I hope it will appear soon on the cryptography list.  He also used super
blocks and applied the Joux attack at both the small and large level.
You could call it the mega-Joux attack :-).

I believe that it also applies to John Denker's construction of rotating
some bits from the front to the back of one of the two parallel hashes,
working along the lines you suggest for dealing with offset block
boundaries.

These various constructions may still have a certain amount of practical
value in terms of raising the bar for attackers who are using stable bit
techniques to create these shortcut collisions.  But for the ultimate
goal of creating a hash which mimics a random function, it seems another
approach is needed.

At this point the only one I know is to create a k-bit hash function
by using internal paths of 2k bits and compression functions with 2k
bits of strength.  I am still convinced that this construction resists
the Joux multicollision attack, because to even take the first step of
finding a block collision will require 2^k work, and you have already
lost if you are trying to break a k-bit hash function and your attack
takes 2^k work.  A concrete example would be SHA-512 derated to 256 bits,
at least if you believe that the SHA-512 compression function really
has 512 bits of strength.

Hal

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Fri Sep  3 14:04:17 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Fri, 3 Sep 2004 12:04:17 -0600
Subject: PGP Identity Management: Secure Authentication and Authorization
 over the Internet
Message-ID: <p0611040dbd5e6166c91c@[4.240.87.121]>

<http://www.pgp.com/resources/ctocorner/identitymgmt.html>


Click for illustrations, etc...

Cheers,
RAH
--------

PGP Corporation - Resources - CTO Corner

United States | International?


  


  Resources > CTO Corner > Guest Contributors > PGP Identity Management
 Welcome CTO Corner
Data Sheets
Flash Government Regulations Webcasts White Papers



PGP Identity Management:
 Secure Authentication and Authorization over the Internet

 By Vinnie Moscaritolo,
 PGP Cryptographic Engineer

3 September 2004
Abstract
Access to computer services has conventionally been managed by means of
secret passwords and centralized authentication databases. This method
dates back to early timeshare systems. Now that applications have shifted
to the Internet, it has become clear that the use of passwords is not
scalable or secure enough for this medium. As an alternative, this paper
discusses ways to implement federated identity management using strong
cryptography and the same PGP key infrastructure that is widely deployed on
the Internet today.

Beyond Passwords
 The inherent security weakness and management  complexities of
password-based authentication and centralized authorization  databases make
such systems inadequate for the real-world requirements  of today's public
networks. However, by applying the same proven cryptographic technology
used today for securing email, we can construct a robust authentication
system with the following goals in mind:
	* 	 Provide a single sign-on experience in which users only need to
remember one password, yet make it less vulnerable to "cracking" (hacking)
attempts.
	* 	 Employ strong user authentication, extendable to multi-factor
methods such as tokens or smart cards. The only copy of the authenticating
(secret) material is in the possession of the user.
	* 	 Design such a system so it does not depend on any trusted
servers and so that the compromise of any server does not affect the
security of other servers or users.
	* 	 Build on existing and well-accepted infrastructures that scale
to fit a very large base of users and servers.
	* 	 Enable users to sign on to the networks of more than one
enterprise securely to conduct transactions.

 Authentication with Cryptographic Signatures
Email communications  via the Internet face a security challenge similar to
network user authentication.  Messages traveling through public networks
can be eavesdropped or counterfeited  without much effort. Yet we have been
able to successfully mitigate  these risks by using public key cryptography
to digitally sign and authenticate  email messages.

 With public key cryptography, each user generates a pair of mathematically
related cryptographic keys. These keys are created in such a way that it is
computationally infeasible to derive one key from the other. One of the
keys is made publicly available to anyone who wishes to communicate with
that user. The other key is kept private and never revealed to anyone else.
This private key can be further secured by either placing it in a hardware
token, encrypting it to a passphrase, or sometimes both. The holder uses
the private key to digitally sign data. This digital signature can later be
checked with the matching public key to ensure the data has not been
tampered with and that it originated from the holder of the private key.

 Because the holder of the private key is the only entity that can create a
digital signature that verifies with the corresponding public key, there is
a strong association between a user's identity and the ability to sign with
that private key. Thus, a digital signature is strong testimony to the
authenticity of the sender.

Cryptographic Challenge-Response
 Because the public key functions  as a user's identity in cyberspace, we
can apply digital signatures  to strongly authenticate users of network
services. One way to do this  is to challenge the user to sign a randomly
generated message from the  server. The server then verifies the identity
of the user with the public  key. This process is illustrated below.

	1.  	The user initiates network service access.
	2.  	The server looks up the user's public key in its authentication
database. The server then generates a random challenge string and sends the
challenge to the client.
	3.  	The client digitally signs the challenge string and returns the
cryptographic signature to the server. The client also sends a
counter-challenge string, which is used to verify the server's authenticity.
	4.  	The server then checks the client's signature, and if successful,
grants access. It also signs and returns the client's counter-challenge.

 The use of such cryptographic user authentication offers a number of
advantages over password-based systems. For example, if we employ the same
key used to sign email, user authentication becomes as strong as the
applied cryptographic digital signature algorithm. This approach reduces
the need for users to periodically change the password, yet means they only
need to remember one passphrase for all servers using this system. In
addition, because the user maintains the only secret material in the
system, compromising a server's user database results in only limited
damage. All this can be accomplished without the risks associated with
passphrase caches or key chains.

 PGPuam - Proof of Concept
A public key login system was originally  prototyped by the author as
PGPuam and later distributed as sample code  by Apple Computer in 1998
[PGPUAM]. Consisting of an AppleShare-IP client  and server plugin, the
system enabled a user to perform two-way strongly  authenticated logins to
an AppleShare-IP server from a Mac OS client.  The cryptographic routines
were provided by the PGP Software Development  Kit (SDK) shipped with PGP
6.0. The user interface was an extension  of the existing AppleShare login
and is illustrated below.
Although entirely functional, the PGPuam sample was never intended to be a
shipping product. Rather, it was meant to be a practical demonstration of
why public key cryptography should be treated as a core operating system
component. Unfortunately in the late 1990s, cryptography was mired in both
commercial and political constraints and widespread public key
infrastructure (PKI) was slow to solidify. Nevertheless, PGPuam was
successful in demonstrating that cryptography could be used for more than
encrypting email. (Note that AppleShare-IP was just a convenient test
platform. This concept is portable to file servers that support plugin
authentication modules such as Apache modules or Windows GINA
Authentication DLL.)

Authentication vs. Authorization
 Although the PGPuam authentication  effectively addresses most password
management and single sign-on issues,  it does nothing for user
authorization. File servers still have to maintain  some form of user-file
access control database. Managing and maintaining  these user authorization
databases securely quickly become cumbersome  for server administrators
when more than a handful of servers are involved.

 Consider, for example, what happens when a new user wishes to gain access
to a server. The system administrator must create an account and add the
user's name and access information to the appropriate server database. If
the user wishes to access a number of servers, this process must be
duplicated and kept synchronized on each server. This process is further
exacerbated when the servers are owned by different organizations.
Conversely, when a user departs from an organization, each of the servers
must then be updated to reflect this change. Often, removed users are
overlooked and left active on servers managed by different departments,
thus creating a security risk.

Although have been a number of attempts to create automated systems to
replicate or centralize the authorization databases, such as Kerberos, they
all seem to share the following drawbacks:
	* 	 The authorization server itself must be physically secure and is
a critical link in the security chain.
	* 	 Each server must be in communication with the authorization
server to verify user identity and authorizations. This could be an
unreasonable requirement for remote sites or devices such as a door badge
reader, for example.
	* 	 The authorization server is an ideal target for
denial-of-service attacks because they affect all the servers managed by it.

 PGPticket - Secure Federated User Authorization
A number of papers  have described ingenious alternatives for distributing
network service  authorization [BFL] [SPKI]. In particular, the Simple
Public Key Infrastructure  (SPKI) model introduces a change in how
authorization is performed for  network services. Instead of maintaining a
per-server database of users'  names, passwords, and their corresponding
access rights, we can apply  digital-signature technology to create an
authorization certificate.  Think of this certificate as a digital
"permission slip," valid  only for a specific user's key over a certain
period of time. The authorization certificate is signed by the organization
or a proxy that owns the  server and presented by the user upon accessing a
restricted service.

 One way to encapsulate these certificates is in the form of an OpenPGP
standalone signature packet [OPENPGP]. These packets, known as PGPtickets ,
form the basis of a lightweight but very secure federated authorization
protocol [PGPTICKET]. Each PGPticket contains the following fields:
	* 	 The ISSUER who generates and signs the certificate, represented
by a PGP Key-ID.
	* 	 The SUBJECT, the principal or set of principals to which the
certificate grants its authorization. A combination of KeyID, algorithm ID
and key fingerprint is used to represent the subject.
	* 	 VALIDITY is some combination of dates or online tests specifying
the validity period/conditions of the certificate-typically, a creation and
expiration date. This field might be useful for a school that wants to
allow access to facilities for a limited period such as a term.
	* 	 AUTHORIZATION is a structured field expressing the authorization
this certificate grants to the subject. This data could be represented as
SAML or some form of XML.
	* 	 DELEGATION is a flag that indicates if the subject is allowed to
delegate the specified authorization further.

 PGPtickets can be issued in or out of band and are uniquely identified by
the hash of the ticket packet, known as its Ticket-ID. The issuer verifies
the subject's key information through standard practice, such as key
fingerprint. Unless there is a specific requirement to encrypt the signed
tickets, they can be returned via cleartext email or even placed on a
public website and accessed by the Ticket-ID. The subject can even store
the ticket in a database, smart card, or token.
 The following illustrates the process of accessing a service with a PGPticket:

	1.  	The user requests server access from the system admin. The user
provides either a copy of his/her public key or makes the key available on
a keyserver. The issuer verifies the validity of this key.
	2.  	 The administrator generates the PGPticket with appropriate
authorizations and validity information, signing the ticket with the server
admin key. The ticket is either posted in a public place or sent by email
to the user.
	3.  	 The user retrieves the PGPticket and stores it in a local ticket
database.
	4.  	When the user attempts to access a network service, the client
searches its ticket database for the appropriate ticket and sends a copy of
it along with the access request.
	5.  	 The server checks the validity of the ticket by verifying the
admin signature and expiration date of the ticket. The server then
generates a random challenge string and sends the challenge to the client,
requesting that the key specified in the ticket sign it.
	6.  	 The client signs and returns the challenge, which is checked by
the server and, if successful, access is granted with the authorizations
specified in the ticket.

 The server only requires a copy of the root issuer's public key. It does
not need to store copies of the subject's public keys because the key
fingerprint is signed into the ticket body. The subject public key can be
provided by request from the client and cached for later use. The same is
true for delegated tickets. There is no specific requirement for a
certifying authority, although its use is certainly not precluded and would
make PGPtickets usable for small sites as well as enterprises.

 One of the more interesting features of this design is that it enables the
servers to function without access to a keyserver, independent of outside
influences and resilient to denial-of-service attacks. This approach allows
the use of PGPtickets for standalone devices where no network connection is
practical, which opens a number of possibilities. PGPtickets can be
transported in a token or Bluetooth device, and not only used for such
things as Web Service or VPN access but also for restricted door access. In
essence, PGPtickets could extend the usefulness of the PGP PKI to the
physical world.

PGPcoupon - Building on XML Web Services
 Other interesting possibilities  occur when you consider that PGPticket
piggybacks on the flexibility  of the PGP key infrastructure. Consider a
system that produced tickets  automatically through some pay-per-use
service and combine that with  anonymous keys. Or what about using the
key-splitting features to create  a ticket that needs a certain amount of
shares for service access?

 Another possibility is to mix the technologies of PGPticket and XML object
Web Services. A client could post a Web request for a proposal whereby
vendors could reply with a PGP-signed coupon that would be honored by
various distributors for a given period.

 For example, imagine a school wants to purchase a number of books; various
vendors compete for the order and send replies. In the replies is a 20% off
PGPcoupon that Amazon or BN.com would honor. The client could then present
this coupon upon purchase and have the transaction processed automatically.

 Conclusion
 I have outlined a number of alternate uses for PGP  technology that go far
past email encryption. Most of these designs  have been around for a number
of years, but were untapped because of  political or commercial restraints
and, at times, lack of vision. Fortunately,  the environment has changed
and cryptographic technology can be used  to solve a number of real-world
identity management problems today.

References
 [OPENPGP]
 Callas, J., Donnerhacke, L., Finney, H., Thayer, R. "OpenPGP  Message
Format." RFC 2440, November 1998

[SPKI]
 Ellison, C. "SPKI Requirements." RFC 2692, September 1999

Ellison, C., Frantz, B., Lampson, B., Rivest, R. "SPKI Certificate Theory."
RFC 2693, September 1999

[BFL]
 Blaze, M., Feigenbaum, J., and Lacy, J. "Decentralized Trust Management."
Proceedings 1996 IEEE Symposium on Security and Privacy.

 [PGPTICKET]
 Moscaritolo, V. "PGPticket - A Secure Authorization Protocol." Mac-Crypto
Workshop, October 1998

Moscaritolo, V., Mione, A. draft-ietf-pgpticket-moscaritolo-mione-02.txt

 [PGPUAM]
 Moscaritolo, V. "PGPuam - Public Key Authentication for AppleShare-IP."
Mac-Crypto Workshop, October 1998

"Now that applications have shifted to the Internet, the use of secret
passwords is not scalable or secure enough. Instead, there are ways to
implement federated identity management using strong cryptography and same
PGP key infrastructure that is widely deployed on the Internet today."

 - Vinnie Moscaritolo, PGP Cryptographic Engineer

Related Links
	* 	Expert  advice from Jon Callas: "Encryption 101 - Triple DES
Explained"
	* 	Video:  HNS interview with Jon Callas
	* 	 Summary:  HNS interview with Jon Callas
Company | Privacy Statement | Legal Notices | Site Map ?2002-2004 PGP
Corporation. All Rights Reserved.


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From ashwood at msn.com  Fri Sep  3 19:23:58 2004
From: ashwood at msn.com (Joseph Ashwood)
Date: Fri, 3 Sep 2004 16:23:58 -0700
Subject: Kerberos Design
References: <20040901185928.GB31570@iwoars.net>
Message-ID: <00e701c49211$01252f50$6401a8c0@JOSEPHAS>

> I'm currently looking into implementing a single sign-on solution for
> distributed services.

Be brave, there's more convolutions and trappings there than almost anywhere
else.

> Since I'm already using OpenSSL for various SSL/x.509 related things,
> I'm most astonished by the almost total absence of public key
> cryptography in Kerberos, and I haven't been able to find out why this
> design choice was made - performance reasons, given that at its
> inception public key operation cost was probably much more prohibitive?

Actually the primary reason Iv'e heard had more to do with the licensing
costs (at the time they were not free) than with anything else. You will
however find PKI extensions to Kerberos, don't remember the RFC off-hand.

> - Is there a good web/book/whatever resource regarding the design
>   of Kerberos? Amazon offers the O'Reilly book, which, from the
>   abstract, seems to take the cryptographic design of Kerberos as
>   a given and concentrates on its usage, and another one that also
>   doesn't seem to give much detail on the issue. Something in the
>   direction of EKR's SSL/TLS book would be very much appreciated.

>From my understanding Kerberos was originally thrown together at MIT, then
it was broken, and patched, and broken and patched, until it was relatively
recently qualified to be implemented in Windows, so you're not likely to
find much in the way of well thought-out arguments governing the little
details. In fact many of the decisions seem to be based on "My pet project
is . . . ."

> - Is Kerberos a sane choice to adapt for such solutions today?
>   Is there anything more recent that I should be aware of?

Kerberos is a very sane choice, it may not be the cleanest design ever but
it has withstood a great deal of analysis. Actually, I was a member of a
group that was working on a replacement for Kerberos because of it's age and
potential issues in the future, but we fell into substantial disarray, and
eventually it collapsed. Given this, I can confidently say that it is 
unlikely that you will find something in the Kerberos vein taht is newer.
                Joe


Trust Laboratories
Changing Software Development
http://www.trustlaboratories.com 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From foo.o.matic at gmail.com  Sat Sep  4 12:06:48 2004
From: foo.o.matic at gmail.com (Foo-O-Matic)
Date: Sat, 4 Sep 2004 18:06:48 +0200
Subject: Which book for a newbie to cryptography?
Message-ID: <d56b214404090409067961bd42@mail.gmail.com>

Hi, first im new to this list and to cryptography. :)
I've read the first lesson from this 24 crypto lessons:
http://www.und.nodak.edu/org/crypto/crypto/lanaki.crypt.class/lessons/
and found it really interesting. I want to start learning cryptography
from a book, and I have access to these 3 books from the library in
the college near me:

- Handbook of applied cryptography / Alfred J. Menezes, Paul C. van
Oorschot, Scott A. Vanstone / 1996
- Cryptography : theory and practice 2nd ed. / Douglas R. Stinson / 2002

What I want to know is which one is recommended for someone which is
new to cryptography?

Thanks in advance,
Foo-o-Matic

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Sat Sep  4 13:52:19 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Sat, 4 Sep 2004 11:52:19 -0600
Subject: States Continue to Debate Merits of Paper Trail For E-Voting
 Machines
Message-ID: <p06110402bd5fadadfeac@[4.240.87.121]>

<http://online.wsj.com/article_print/0,,SB109407788036007336,00.html>

The Wall Street Journal


 September 2, 2004

 DIGITS



States Continue to Debate
 Merits of Paper Trail
 For E-Voting Machines
September 2, 2004; Page B4

Paper or Plastic?

In the race to use electronic-voting machines that produce a paper copy of
the ballots cast, Nevada has become the front-runner in this presidential
election year. For the past two weeks, new touch-screen machines with
printers attached have been used by more then 50,000 Nevadans in early
voting for the state's Sept. 7 primary for in-state offices. Come November,
the state will be the first to roll out such a system for a presidential
election. "A lot of people didn't think we could pull it off in time," says
Steve George, spokesman for Secretary of State Dean Heller, who in December
mandated the new systems from Sequoia Voting Systems, a unit of De La Rue
PLC. "It certainly seems like a very wise choice when you look at some of
the problems the electronic systems have had."

Those problems -- faulty software, security glitches and human errors --
are certain to get even more scrutiny as the latest presidential contest
goes down to the wire. Several swing states, including Pennsylvania,
Florida, New Mexico and Tennessee, will use electronic systems with no
paper trail. But Ohio's secretary of state has barred the purchase of new
electronic-voting machines beyond the five counties where they are already
installed. New regulations in California mandate that every voter have an
option to use a paper ballot, providing the so-called paper-or-plastic
choice.

Such moves have hampered the adoption of touch-screen voting machines.
After the 2000 presidential election imbroglio, experts predicted 50% of
voters would use this year. Now it appears less than 30% will do so. "We've
slowed the train down," says Kim Alexander, president of the California
Voter Foundation, an election watchdog.

The existence of a paper trail raises as many questions as it answers. In
Nevada, many voters in Clark County, which includes Las Vegas, will cast
ballots on older electronic machines without printers, meaning there won't
be a complete paper record of the state's votes. And the paper read-outs
don't yet conform to the state's legal format, meaning they can't be used
in an official recount without court approval. Mr. George says that won't
be a problem if a dispute arises over Nevada's five electoral votes.

"If it's a choice between hitting the button again for the electronic total
and the paper record, it stands to reason the court would choose to go with
the paper record," he says.

Vintage 6.0

No wine is fine before its time. And the same could be true for Wine.com1,
an online wine site that certainly has had a long shelf life.

Since its launch in the late 1990s, the online retailer has morphed from an
earlier version of the Wine.com site, as well as from start-up enterprises
called WineShopper and eVineyard. Together the start-ups have raised about
$150 million in venture capital, according to President and Chief Executive
George Garrick. This week the company is announcing it has raised more: Its
sixth, "Series F" financing to the tune of $20 million. The money comes
from a syndicate led by Baker Capital in New York. The company said it will
use it to retire debt, to upgrade the Web site and for marketing.

So what's new this time? The latest vintage basically is the eVineyard
enterprise that was restarted in 2002, after the company bought the
Wine.com name and customer list. But, says Mr. Garrick, "We've taken a very
by-the-numbers, conservative approach" -- much more sensible and lean. He
adds that the company go to great effort to comply with the complex,
interstate laws that regulate the shipping of alcohol. The San
Francisco-based retailer can legally ship to 26 states. Those states
"account for 75% of wine consumption," Mr. Garrick says.

Tech Tracker?

If the Webby Awards are a barometer for the tech industry, the bust may
officially be over.

The Webbys, which honor outstanding Web sites run by reviewers, cultural
institutions and schools, among others, is more than doubling the number of
its prize categories, to 65 from 30. The reason: to include categories for
new online phenomena such as blogs and social networking. Other new prize
categories include sites devoted to getting a job or finding real estate
and those run by nonprofits.

The expansion of the award categories parallels the growth of the Internet,
says Tiffany Shlain, founder of the online awards. "The Web has changed
dramatically since we started it," she says.

The Webbys, usually held in San Francisco, were dubbed the Oscars of the
Internet industry when they started in 1996. But during the past two years,
organizers opted against holding a live awards show, in response to the
weak economy, the Iraq war and the SARS outbreak of last summer.

Now, the mood has changed, Ms. Shlain says, pointing to the recent Google
IPO and the heavy use of the Internet in this year's presidential campaign.
The Webbys will again be presented live next year, with a ramped-up
marketing and advertising effort, along with the addition of the categories.

Grand Old Phone

Talk about wired.

For this week's Republican National Convention in New York City, Verizon
Communications supplied 40,000 miles of cabling, two central offices,
12,000 phone lines and 300 high-speed data connections -- not to mention
300 technicians. Verizon, the incumbent phone company in New York, also
installed 140 TV circuits for the event, providing video transmission from
several spots around the convention to national and international TV
networks including al-Jazeera -- making it the largest video transmission
project the company has ever set up.

The data network is capable of downloading the entire content of
Encyclopedia Britannica in roughly one minute and eight seconds, according
to Verizon. The company also handled much of the Democratic National
Convention's communications in Boston, though it installed far fewer video
transmission lines there.


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From rsalz at datapower.com  Sat Sep  4 18:46:50 2004
From: rsalz at datapower.com (Rich Salz)
Date: Sat, 04 Sep 2004 18:46:50 -0400
Subject: Kerberos Design
In-Reply-To: <20040901185928.GB31570@iwoars.net>
References: <20040901185928.GB31570@iwoars.net>
Message-ID: <413A45DA.3060907@datapower.com>

> I've been trying to study Kerberos' design history in the recent past
> and have failed to come up with a good resource that explains why things
> are built the way they are. 

http://web.mit.edu/kerberos/www/dialogue.html

	/r$

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Mon Sep  6 13:52:03 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Mon, 6 Sep 2004 11:52:03 -0600
Subject: Spam Spotlight on Reputation
Message-ID: <p06110416bd6252da2a82@[4.240.162.204]>

<http://www.eweek.com/print_article/0,1761,a=134748,00.asp>

EWeek

 Spam Spotlight on Reputation


Spam Spotlight on Reputation

September 6, 2004
 By   Dennis Callaghan



As enterprises continue to register Sender Protection Framework records,
hoping to thwart spam and phishing attacks, spammers are upping the ante in
the war on spam and registering their own SPF records.

E-mail security company MX Logic Inc. will report this week that 10 percent
of all spam includes such SPF records, which are used to authenticate IP
addresses of e-mail senders and stop spammers from forging return e-mail
addresses. As a result, enterprises will need to increase their reliance on
a form of white-listing called reputation analysis as a chief method of
blocking spam.

E-mail security appliance developer CipherTrust Inc., of Alpharetta, Ga.,
also last week released a study indicating that spammers are supporting SPF
faster than legitimate e-mail senders, with 38 percent more spam messages
registering SPF records than legitimate e-mail.

The embrace of SPF by spammers means enterprises' adoption of the framework
alone will not stop spam, which developers of the framework have long
maintained.

Enter reputation analysis. With the technology, authenticated spammers
whose messages get through content filters would have reputation scores
assigned to them based on the messages they send. Only senders with
established reputations would be allowed to send mail to a user's in-box.
Many anti-spam software developers already provide such automated
reputation analysis services. MX Logic announced last week support for such
services.

"There's no question SPF is being deployed by spammers," said Dave
Anderson, CEO of messaging technology developer Sendmail Inc., in
Emeryville, Calif.

"Companies have to stop making decisions about what to filter out and start
making decisions about what to filter in based on who sent it," Anderson
said.

The success of reputation lists in organizations will ultimately depend on
end users' reporting senders as spammers, Anderson said. "In the system
we're building, the end user has the ultimate control," he said.

Scott Chasin, chief technology officer of MX Logic, cautioned that
authentication combined with reputation analysis services still won't be
enough to stop spam. Chasin said anti-spam software vendors need to work
together to form a reputation clearinghouse of good sending IP addresses,
including those that have paid to be accredited as such.

"There is no central clearinghouse at this point to pull all the data that
anti-spam vendors have together," said Chasin in Denver. "We're moving
toward this central clearinghouse but have to get through authentication
first."

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From hadmut at danisch.de  Mon Sep  6 18:15:33 2004
From: hadmut at danisch.de (Hadmut Danisch)
Date: Tue, 7 Sep 2004 00:15:33 +0200
Subject: Spam Spotlight on Reputation
In-Reply-To: <p06110416bd6252da2a82@[4.240.162.204]>
References: <p06110416bd6252da2a82@[4.240.162.204]>
Message-ID: <20040906221533.GA29063@danisch.de>

On Mon, Sep 06, 2004 at 11:52:03AM -0600, R. A. Hettinga wrote:
> 
> E-mail security company MX Logic Inc. will report this week that 10 percent
> of all spam includes such SPF records,

I have mentioned this problem more than a year ago in context of 
my RMX draft (SPF, CallerID and SenderID are based on RMX).
Interestingly, nobody really cared about this major security problem.

All RMX-derivatives block forged messages (more or less).  But what
happens if the attacker doesn't forge? That's a hard problem.  And a
problem known from the very beginning of the sender verifikation
discussion.


The last 17 month of work in ASRG (Anti Spam Research
Group, IRTF) and MARID (Mail authorization records in DNS, IETF) are
an excellent example of how to not design security protocols. 

This was all about marketing, commercial interests, patent claims,
giving interviews, spreading wrong informations, underminding
development, propaganda. It completely lacked proper protocol design,
a precise specification of the attack to defend against, engineering
of security mechanisms. It was a kind of religious war. And while 
people were busy with religious wars, spammers silently realized that 
this is not a real threat to spam. Actually, it sometimes was quite
the opposite: I was told of some cases where MTAs were configured to 
run every mail through spam assassin. Spam assassin assigns a message
a higher score if the sender had a valid SPF record. Since most
senders with valid recors were the spammers, spam received a higher
score than plain mail, which is obviously the opposite of security. 
People spent more time in marketing and public relations than 
in problem analysis and verifikation of the solution. That's the 
result.

What can we learn from this?

Designing security protocols requires a certain level of 
security skills and discipline in what you want to achieve. 

Although RMX/SPF/CallerID/SenderID does not make use of cryptography,
similar problems can be sometimes found in context of cryptography.
Knowing security primitives is not enough, you need to know how to
assemble them to a security mechanism.  Good lectures are given about
the mathematical aspects of cryptography. But are there lectures about
designing security protocols?  I don't know of any yet.

And there is a new kind of attack: Security protocols themselves 
can be hijacked and raped by patent claims. 


regards
Hadmut













---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Mon Sep  6 22:52:39 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Mon, 6 Sep 2004 20:52:39 -0600
Subject: Maths holy grail could bring disaster for internet
Message-ID: <p06110402bd62d2bbbd51@[4.240.162.155]>

<http://www.guardian.co.uk/print/0,3858,5009766-103690,00.html>

The Guardian

Maths holy grail could bring disaster for internet

Two of the seven million dollar challenges that have baffled for more than
a century may be close to being solved
Tim Radford, science editor
Tuesday September 7, 2004

The Guardian
Mathematicians could be on the verge of solving two separate million dollar
problems. If they are right - still a big if - and somebody really has
cracked the so-called Riemann hypothesis, financial disaster might follow.
Suddenly all cryptic codes could be breakable. No internet transaction
would be safe.

 On the other hand, if somebody has already sorted out the so-called
Poincar? conjecture, then scientists will understand something profound
about the nature of spacetime, experts told the British Association science
festival in Exeter yesterday.

 Both problems have stood for a century or more. Each is almost dizzyingly
arcane: the problems themselves are beyond simple explanation, and the
candidate answers published on the internet are so intractable that they
could baffle the biggest brains in the business for many months.

 They are two of the seven "millennium problems" and four years ago the
Clay Mathematics Institute in the US offered $1m (?563,000) to anyone who
could solve even one of these seven. The hypothesis formulated by Georg
Friedrich Bernhard Riemann in 1859, according to Marcus du Sautoy of Oxford
University, is the holy grail of mathematics. "Most mathematicians would
trade their soul with Mephistopheles for a proof," he said.

 The Riemann hypothesis would explain the apparently random pattern of
prime numbers - numbers such as 3, 17 and 31, for instance, are all prime
numbers: they are divisible only by themselves and one. Prime numbers are
the atoms of arithmetic. They are also the key to internet cryptography: in
effect they keep banks safe and credit cards secure.

 This year Louis de Branges, a French-born mathematician now at Purdue
University in the US, claimed a proof of the Riemann hypothesis. So far,
his colleagues are not convinced. They were not convinced, years ago, when
de Branges produced an answer to another famous mathematical challenge, but
in time they accepted his reasoning. This time, the mathematical community
remains even more sceptical.

 "The proof he has announced is rather incomprehensible. Now mathematicians
are less sure that the million has been won," Prof du Sautoy said.

 "The whole of e-commerce depends on prime numbers. I have described the
primes as atoms: what mathematicians are missing is a kind of mathematical
prime spectrometer. Chemists have a machine that, if you give it a
molecule, will tell you the atoms that it is built from. Mathematicians
haven't invented a mathematical version of this. That is what we are after.
If the Riemann hypothesis is true, it won't produce a prime number
spectrometer. But the proof should give us more understanding of how the
primes work, and therefore the proof might be translated into something
that might produce this prime spectrometer. If it does, it will bring the
whole of e-commerce to its knees, overnight. So there are very big
implications."

 The Poincar? conjecture depends on the almost mind-numbing problem of
understanding the shapes of spaces: mathematicians call it topology.
Bernhard Riemann and other 19th century scholars wrapped up the
mathematical problems of two-dimensional surfaces of three dimensional
objects - the leather around a football, for instance, or the distortions
of a rubber sheet. But Henri Poincar? raised the awkward question of
objects with three dimensions, existing in the fourth dimension of time. He
had already done groundbreaking work in optics, thermodynamics, celestial
mechanics, quantum theory and even special relativity and he almost
anticipated Einstein. And then in 1904 he asked the most fundamental
question of all: what is the shape of the space in which we live? It turned
out to be possible to prove the Poincar? conjecture in unimaginable worlds,
where objects have four or five or more dimensions, but not with three.

 "The one case that is really of interest because it connects with physics,
is the one case where the Poincar? conjecture hasn't been solved," said
Keith Devlin, of Stanford University in California.

 In 2002 a Russian mathematician called Grigori Perelman posted the first
of a series of internet papers. He had worked in the US, and was known to
American mathematicians before he returned to St Petersburg. His proof - he
called it only a sketch of a proof - was very similar in some ways to that
of Fermat's last theorem, cracked by the Briton Andrew Wiles in the last
decade.

 Like Wiles, Perelman is claiming to have proved a much more complicated
general problem and in the course of it may have solved a special one that
has tantalised mathematicians for a century. But his papers made not a
single reference to Poincar? or his conjecture. Even so, mathematicians the
world over understood that he tackled the essential challenge. Once again
the jury is still out: this time, however, his fellow mathematicians
believe he may be onto something big.

 The plus: the multidimensional topology of space in three dimensions will
seem simple at last and a million dollar reward will be there for the
asking. The minus: the solver does not claim to have found a solution, he
doesn't want the reward, and he certainly doesn't want to talk to the media.

 "There is good reason to think the kind of approach Perelman is taking is
correct. However there are some problems. He is very reclusive, won't talk
to the press, has shown no indication of publishing this as a paper, which
you would have to do if you wanted to get the prize from the Clay
Institute, and has shown no interest in the prize whatsoever," Dr Devlin
said.

 "Has it been proved? We don't know. We have good reason to assume it has
been and within the next 12 months, in the inner core of experts in
differential geometry, which is the field we are speaking about, people
will start to say, yes, OK, this looks right. But there is not going to be
a golden moment."

 The implications of a proof of the Poincar? conjecture would be enormous,
but like the problem itself, very difficult to explain, he said. "It can't
fail to have huge ramifications: not only the result, but the methods as
well. At that level of abstraction, that level of connection, so much can
follow. Differential geometry is the subject that is really underneath
understanding everything about space and spacetime."

 Seven baffling pillars of wisdom

1 Birch and Swinnerton-Dyer conjecture Euclid geometry for the 21st
century, involving things called abelian points and zeta functions and both
finite and infinite answers to algebraic equations

2 Poincar? conjecture The surface of an apple is simply connected. But the
surface of a doughnut is not. How do you start from the idea of simple
connectivity and then characterise space in three dimensions?

 3 Navier-Stokes equation The answers to wave and breeze turbulence lie
somewhere in the solutions to these equations

 4 P vs NP problem Some problems are just too big: you can quickly check if
an answer is right, but it might take the lifetime of a universe to solve
it from scratch. Can you prove which questions are truly hard, which not?

 5 Riemann hypothesis Involving zeta functions, and an assertion that all
"interesting" solutions to an equation lie on a straight line. It seems to
be true for the first 1,500 million solutions, but does that mean it is
true for them all?

 6 Hodge conjecture At the frontier of algebra and geometry, involving the
technical problems of building shapes by "gluing" geometric blocks together

 7 Yang-Mills and Mass gap A problem that involves quantum mechanics and
elementary particles. Physicists know it, computers have simulated it but
nobody has found a theory to explain it

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From foo.o.matic at gmail.com  Tue Sep  7 07:19:18 2004
From: foo.o.matic at gmail.com (Foo-o-Matic)
Date: Tue, 7 Sep 2004 13:19:18 +0200
Subject: Some additional info about "Which book for a newbie to cryptography?"
In-Reply-To: <d56b214404090409067961bd42@mail.gmail.com>
References: <d56b214404090409067961bd42@mail.gmail.com>
Message-ID: <d56b2144040907041925fcac54@mail.gmail.com>

Hi, it's me again.
first, thank you for all the answers. second, im sorry for the lack of
details, I should have added some info, which is:
1. I'm a 2nd year student of BA in Computer Science, I finished 5
courses, 3 in Programming (Intoduction A to Computer Science,
Introduction B to Computer Science, and Software Development in UNIX
[in all of them we were writing codes in C] ) and 2 courses in math
(Discrete Math 1 and Discrete Math 2). so basically that is my
mathematical knowledge. also now im about to start the courses
Differential and Integral math, and Linear math.

2. I went to the online Library Catalog and searched for the keyword
"Cryptography", and these were the results:

~~~~~~~~~~~~~~
- Cryptography : theory and practice: 2nd ed. / Douglas R. Stinson
- Defending your digital assets against hackers, crackers, spies and
thieves / Randall K. Nichols, Daniel J. Ryan, Julie J. C. H. Ryan
- Cryptography and network security : principles and practice /
William Stallings
- Handbook of applied cryptography / Alfred J. Menezes, Paul C. van
Oorschot, Scott A. Vanstone
- Practical cryptography for data internetworks / William Stallings
- Disappearing cryptography : being and nothingness on the Net / Peter Wayner
- Protect your privacy : the PGP user's guide / William Stallings
- Cryptography : theory and practice: 1st ed. / Douglas R. Stinson
~~~~~~~~~~~~~~

As you can see, no Schneier here.
That's it, I think that's all what I wanted to add.
So now what book do you recommend?
Thanks alot in advance,
Foo-o-Matic

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Tue Sep  7 09:41:52 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Tue, 7 Sep 2004 07:41:52 -0600
Subject: Digital content spurs micropayments resurgence
Message-ID: <p06110405bd636a6c4cb1@[4.240.162.155]>

<http://zdnet.com.com/2102-1104_2-5347513.html?tag=printthis>



Digital content spurs micropayments resurgence
 By  Matt Hines
 CNET News.com
 September 7, 2004, 4:00 AM PT
 URL:  http://zdnet.com.com/2100-1104-5347513.html

 Think small.

 With its meteoric rise to success, Apple Computer's iTunes digital music
service not only changed perceptions about whether consumers were willing
to pay for online content, but it also highlighted the rising promise of
micropayments.

 On Tuesday, 2-year-old BitPass, a payment company in Palo Alto, Calif., is
expected to announce $11.75 million in venture capital, along with the news
that former American Express Chairman James Robinson III will join its
board of directors. Robinson is also a partner in one of the firms
investing in BitPass, New York-based RRE Ventures.
 News.context

What's new:
 The success of digital music sales has purveyors of micropayment services
humming a happy tune.

 Bottom line:Micropayments have failed to become a macro-business, but the
increasing popularity of digital content could bring a cloudburst of
pennies from heaven.

More stories on micropayments

While credit card companies and online transaction specialists like PayPal
are ringing up bigger sales online, business models aimed at helping
e-commerce vendors facilitate smaller deals, or micropayments, are getting
a boost from digital content sales.

 If this sounds familiar, it should. But the so-called Internet currency
vendors of the dot-com era, companies including Beenz, Flooz and DigiCash,
failed to generate enough business fostering micropayments to survive.
Fast-forward a few years, and news that iTunes topped 125 million downloads
last week is more evidence that digital content may hold the key to
unlocking the low end of e-commerce.

 Micropayments are typified by the 99 cents that iTunes charges to download
a song or the $2.99 users might see on their Cingular Wireless phone bills
after buying a custom ring tone.

 According to recent research published by TowerGroup, the total market for
Internet and wireless micropayments, led by demand for digital content,
will increase by 23 percent annually over the next five years to reach
$11.5 billion by 2009. TowerGroup, based in Needham, Mass., charted the
micropayments market at just over $2 billion in 2003.

 Bruce Cundiff, an analyst with Jupiter Research, thinks the e-commerce
market is in its third or fourth wave of development of micropayment
technologies. The success of iTunes, coupled with continued growth of
broadband, will make digital content the catalyst that pushes the sector
forward rapidly, Cundiff said.

 "What it comes down to is that there simply must be a viable transaction
model for smaller-cost products to make a dollar off e-commerce sales, but
I think with what we've seen already in digital media, it's clear that
people are figuring out how to make it work," Cundiff said.

 Tuning up for takeoff
 Web shoppers have historically preferred to pay with credit cards. But
because credit card companies typically charges fees for processing and
customer service on every transaction, credit cards can be an extremely
inefficient way of making a small purchase, with the fees often eating most
of the profit margin.

Still consumers have begun to get used to the idea of buying small items
over the Net.

 Growth of the digital content market seems almost a certainty, based on
the projected expansion of segments including music services, Internet
publishing, and applications for mobile devices, such as custom ring tones
or games. Cambridge, Mass., analyst firm Forrester Research has predicted
that music downloads alone will become a $1.4 billion business by 2006,
accounting for nearly 10 percent of annual music sales in the United States.

 Jupiter Research estimates that revenue from online content will reach
$3.1 billion by 2009, driven by an increasing number of broadband-ready
homes spending money on Web-based music services, games and e-books, among
other things. Industry experts agree that iTunes deserves a lot of the
credit for opening consumers' eyes to the option of buying online in
micro-size increments, and most seem to feel that digital content will
continue to dominate the market for small Web-based transactions.

 "Micropayments don't just represent buying low-priced items. They can also
can be used to get people to test new products, or try out a service that
charges a lot more for a subscription."
 --analyst Nick Holland, Mercator Advisory Group

 According to Nick Holland, an analyst with Shrewsbury, Mass.-based
Mercator Advisory Group, growth of the micropayments market will be almost
completely dependent on music, ring tones and games, specifically, at least
for the next several years. The analyst estimates that such content will
constitute a $2.3 billion market in the United States this year alone, and
while Holland said subscriptions will remain consumers' favorite method of
payment for digital content, wider use of micropayments will increase
opportunities for vendors to lure new customers.

 "Micropayments don't just represent buying low-priced items," Holland
said. "They can also be used to get people to test new products, or try out
a service that charges a lot more for a subscription. There's certainly
demand for downloads, ring tones and pay-as-you-go gaming, but it remains
to be seen how profitable this market can be using micropayments."

 For officials at eBay's online transaction subsidiary, PayPal--who say the
company is already handling millions of low-dollar transactions--it is
clear that digital content represents the most promising opportunity for
immediate growth in micropayments. Peter Ashley, director of business
development for San Jose, Calif.-based PayPal, believes that with iTunes,
Apple drew up a template that many other companies will try to emulate.

 "Once there is ability for more companies to facilitate smaller charges,
going as far down as pennies, nickels and dimes, without incurring the same
sort of credit card transaction fees you see today, new businesses will
open that simply could not exist in the past," Ashley said.

 The executive envisions transaction systems soon allowing e-commerce
companies to process any transaction, no matter how small, letting people
creating new kinds of digital content, such as games or ring tones, to more
profitably market their wares. Ashley said that PayPal's role as an
established leader in online transaction processing will give it the
ability to watch other firms test the waters with different micropayment
systems before it begins more actively pursuing the market.

 PayPal parent eBay is already piloting a program that lets a select group
of people auction digital music via its site, a test which could illustrate
how profitable it can be for individuals or smaller companies to execute
the smaller deals inherent to digital music sales.

 "We've already had to develop a unique product for the music pilot, and
we're excited about seeing other areas of the market develop," said Ashley.
"The opportunity is huge, say, if you consider how many wireless customers
there are out there. You get an idea of how significant the demand for
content like ring tones or screen savers could become."

How the deal is won
 The biggest question facing the micropayments market is just what method
of transaction will appeal to consumers while allowing vendors to slice out
enough profit to keep small-ticket sales lucrative.

Apple has admitted that iTunes is not a major source of revenue. It works
primarily as a sales tool for its iPod digital music players. Apple does a
majority of its business with credit cards but also offers payments methods
ranging from stored-value accounts to gift certificates. But smaller
companies looking to build their core businesses around marketing digital
content must have alternatives to credit cards--including subscriptions,
prepaid accounts, merchant charge aggregation and direct-to-bill.

 In the wireless sector, direct-to-bill is expected to continue to lead.
Mobile-service providers encourage customers to download content onto their
devices, with the cost added to their wireless bills. Subscriptions remain
preferable for content providers in other areas because they allow
companies to more easily digest credit card transaction fees, because
monthly or annual fees are typically larger transactions.

 "Subscriptions are what every vendor wants to sell, but you have to start
somewhere with the consumer, and the other types of micropayments can allow
companies to do get in the door with buyers," said Mercator's Holland. "A
lot of content companies are going to look at micropayments as a stepping
stone to future subscriptions."

 ""That first wave of payment technologies, the currency companies
especially, were too early in the development of e-commerce to succeed."
 --BitPass CEO Michael O'Donnell

 Among the vendors vying for a place on the micropayments landscape with
alternative payment technologies are firms including BitPass and
Peppercoin, which are taking markedly different approaches to the sector.
Peppercoin serves as a micropayment transaction aggregator that helps
vendors save money on credit card charges, while BitPass markets
stored-credit accounts and transaction processing to help facilitate both
buyers and sellers.

 BitPass' system works much like the prepaid calling cards you can buy at
many convenience stores. Customers put money into debit accounts and can
use the funds at any site affiliated with the company. Vendors can begin
accepting the BitPass cards simply by downloading a free software client
provided by the company.

 "That first wave of payment technologies, the currency companies
especially, were too early in the development of e-commerce to succeed, and
the content companies weren't ready to handle it either," said Michael
O'Donnell, chief executive of BitPass. "We're seeing an online payment
evolution moving from free content, to subscriptions, and now per-item
sales, with the options for vendors and consumers growing quickly."

 At Peppercoin, the emphasis is placed squarely on e-commerce vendors. The
Waltham, Mass., company acts as a proxy between vendors and credit card
companies, allowing its users to aggregate their small-value transactions
into larger bills to cut down on the fees charged them by the credit card
companies themselves.

 Peppercoin signed a deal with the Smithsonian Institute last year to help
the organization begin marketing music files stored in its archives on a
per-song basis. The organization had previously struggled to do so, based
on the percentage of its income that was in turn headed back out to the
credit companies in the form of transaction fees.

 According to Rob Carney, vice president of marketing at Peppercoin,
increased demand for digital content is driving short-term growth of
micropayments, but the potential for the market is far greater.

 "Online digital content sales, specifically for music, are generating more
attention for micropayments than ever before, but it makes sense, because
what are you going to sell for dollars online that you have to pay to
ship?" Carney said. "Digital content is leading the way, but it's really
just the thin edge of the wedge when you consider the possibilities in the
physical world as well."


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From crawdad at fnal.gov  Tue Sep  7 10:29:49 2004
From: crawdad at fnal.gov (Matt Crawford)
Date: Tue, 07 Sep 2004 09:29:49 -0500
Subject: Maths holy grail could bring disaster for internet
In-Reply-To: <p06110402bd62d2bbbd51@[4.240.162.155]>
References: <p06110402bd62d2bbbd51@[4.240.162.155]>
Message-ID: <601F1C0F-00DA-11D9-8C23-000A95A0BF96@fnal.gov>


On Sep 6, 2004, at 21:52, R. A. Hettinga wrote:

> But the proof should give us more understanding of how the
> primes work, and therefore the proof might be translated into something
> that might produce this prime spectrometer. If it does, it will bring 
> the
> whole of e-commerce to its knees, overnight. So there are very big
> implications."

This would be a good thing.  Because to rebuild the infrastructure 
based on symmetric crypto would bring the trusted third party 
(currently the CA) out of the shadows and into the light.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From bear at sonic.net  Tue Sep  7 11:14:51 2004
From: bear at sonic.net (bear)
Date: Tue, 7 Sep 2004 08:14:51 -0700 (PDT)
Subject: Spam Spotlight on Reputation
In-Reply-To: <20040906221533.GA29063@danisch.de>
References: <p06110416bd6252da2a82@[4.240.162.204]> <20040906221533.GA29063@danisch.de>
Message-ID: <Pine.LNX.4.58.0409070731140.7800@bolt.sonic.net>



On Tue, 7 Sep 2004, Hadmut Danisch wrote:

> The last 17 month of work in ASRG (Anti Spam Research
> Group, IRTF) and MARID (Mail authorization records in DNS, IETF) are
> an excellent example of how to not design security protocols.
>
> This was all about marketing, commercial interests, patent claims,
> giving interviews, spreading wrong informations, underminding
> development, propaganda. It completely lacked proper protocol design,
> a precise specification of the attack to defend against, engineering
> of security mechanisms. It was a kind of religious war. And while
> people were busy with religious wars, spammers silently realized that
> this is not a real threat to spam.


For what it's worth, do you remember a device that was marketed on
American television called the "Ronco Pocket Fisherman?"  It was
a sort of folding fishing rod with a built-in, tiny, tacklebox,
and the idea was that here was a complete fishing rig that you
could toss into a suitcase and still have room for all your
clothes and stuff.

The fact is, as fishing gear, it was astonishingly bad.  But, as
the owner of a bait shop once explained to me after someone who
had come in with one tossed it in the trash and walked out with
a real fishing rod, "It's not made to catch fish.  It's made to
catch fishermen."

Similarly, the current generation of anti-spam technology isn't
made to catch spammers; it's made to catch ISP's and software
companies and get them to part with their money.  Alas, unlike
the Ronco Pocket Fisherman, there is no proven technology that
people can go back to after getting fed up with it not working.

It has been clear from the outset that all the solutions to spam
consisting of "building a fence around the internet and keeping
the spammers out" aren't going to work, any more than the old
anarchist-cypherpunk dream of "building a fence around our
cryptographic networks and keeping the government out" was going
to to work.  The problem in both cases is that if the information
needed to join the network is available to members of your
intended in group, it's also available to members of your
intended excluded group.

I have two patents in natural language, and a fair amount of
experience engineering in the field.  But that's a fairly recondite
skill, and these days most folks are looking for engineers for much
more prosaic tasks like interfacing their middleware with their
databases.  In the last year, I have been unemployed.  I've
turned down two job offers, though -- from software companies
with "bulk mail products", looking for natural-language guys
to build "paraphrase engines" to bypass spam filters or "copy check"
functions to estimate the likelihood of a particular message body
being filtered.  That's the level of commitment these guys are
showing.  They're actually willing to hire engineers at specialist
salaries to build new ways to bypass filters.

We should not be at all surprised, when we offer a way to
"auto-whitelist" email and therefore bypass filters at a lower
cost than hiring engineers, that they're leaping onto it at
a much higher rate than legit senders.

>From a cryptographic perspective, there are a lot of systems out
there that are solving some trivialized version of the problem or
some not-very-crucial aspect of the problem.  There are a lot of
systems that have a threat model that's very peculiar, and which
can be solved, however meaninglessly, while their customers still
get lots of UCE.  Indeed, there are a lot of systems out there
that don't have any published threat model.  These are failures
of protocol design, though not necessarily failures of
marketability.  But to the extent that they allow bypassing
filters, the spammers are the biggest customers.

				Bear



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From Victor.Duchovni at MorganStanley.com  Tue Sep  7 12:42:31 2004
From: Victor.Duchovni at MorganStanley.com (Victor Duchovni)
Date: Tue, 7 Sep 2004 12:42:31 -0400
Subject: Maths holy grail could bring disaster for internet
In-Reply-To: <p06110402bd62d2bbbd51@[4.240.162.155]>
References: <p06110402bd62d2bbbd51@[4.240.162.155]>
Message-ID: <20040907164231.GS20604@piias899.ms.com>

On Mon, Sep 06, 2004 at 08:52:39PM -0600, R. A. Hettinga wrote:

>  "The whole of e-commerce depends on prime numbers. I have described the
> primes as atoms: what mathematicians are missing is a kind of mathematical
> prime spectrometer. Chemists have a machine that, if you give it a
> molecule, will tell you the atoms that it is built from. Mathematicians
> haven't invented a mathematical version of this. That is what we are after.
> If the Riemann hypothesis is true, it won't produce a prime number
> spectrometer. But the proof should give us more understanding of how the
> primes work, and therefore the proof might be translated into something
> that might produce this prime spectrometer. If it does, it will bring the
> whole of e-commerce to its knees, overnight. So there are very big
> implications."
> 

I bet the reporter had to scrape the bottom of the barrel to find someone
willing to make this claim. Nice for making a sensational article, but
otherwise entirely worthless.

Whether the proof is complete/correct or not, the gist of it seems to be
a construction of a Hilbert-space of entire functions in whose context
the zeta function, suitably transformed so that the critical line is
mapped onto the reals, becomes a self-adjoint operator. To go from
this to the reported claim is at least premature and likely ludicrous.

-- 

 /"\ ASCII RIBBON                  NOTICE: If received in error,
 \ / CAMPAIGN     Victor Duchovni  please destroy and notify
  X AGAINST       IT Security,     sender. Sender does not waive
 / \ HTML MAIL    Morgan Stanley   confidentiality or privilege,
                                   and use is prohibited.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From ghicks at cadence.com  Tue Sep  7 13:24:09 2004
From: ghicks at cadence.com (Gregory Hicks)
Date: Tue, 7 Sep 2004 10:24:09 -0700 (PDT)
Subject: [IP] Looking for one good paper that surveys US laws
Message-ID: <200409071724.i87HO9Y27003@metis.cadence.com>


------------- Begin Forwarded Message -------------

To: Ip <ip at v2.listbox.com>
From: David Farber <dave at farber.net>
Subject: [IP] Looking for one good paper that surveys US laws
Date: Tue, 7 Sep 2004 13:13:27 -0400

about cryptography and computer security related topics at a 
legal/policy level

Any suggestions

Dave

-------------------------------------
[...snip...]
Archives at: http://www.interesting-people.org/archives/interesting-people/

------------- End Forwarded Message -------------


-------------------------------------------------------------------

I am perfectly capable of learning from my mistakes.  I will surely
learn a great deal today.

"A democracy is a sheep and two wolves deciding on what to have for
lunch.  Freedom is a well armed sheep contesting the results of the
decision." - Benjamin Franklin

"The best we can hope for concerning the people at large is that they
be properly armed." --Alexander Hamilton



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From Victor.Duchovni at MorganStanley.com  Tue Sep  7 15:37:53 2004
From: Victor.Duchovni at MorganStanley.com (Victor Duchovni)
Date: Tue, 7 Sep 2004 15:37:53 -0400
Subject: Maths holy grail could bring disaster for internet
In-Reply-To: <601F1C0F-00DA-11D9-8C23-000A95A0BF96@fnal.gov>
References: <p06110402bd62d2bbbd51@[4.240.162.155]> <601F1C0F-00DA-11D9-8C23-000A95A0BF96@fnal.gov>
Message-ID: <20040907193753.GX20604@piias899.ms.com>

On Tue, Sep 07, 2004 at 09:29:49AM -0500, Matt Crawford wrote:

> 
> On Sep 6, 2004, at 21:52, R. A. Hettinga wrote:
> 
> >But the proof should give us more understanding of how the
> >primes work, and therefore the proof might be translated into something
> >that might produce this prime spectrometer. If it does, it will bring 
> >the
> >whole of e-commerce to its knees, overnight. So there are very big
> >implications."
> 
> This would be a good thing.  Because to rebuild the infrastructure 
> based on symmetric crypto would bring the trusted third party 
> (currently the CA) out of the shadows and into the light.
> 

RSA is useful for more than X.509... and of course the reporter is prone
to flights of fancy...

-- 

 /"\ ASCII RIBBON
 \ / CAMPAIGN     Victor Duchovni
  X AGAINST       IT Security,
 / \ HTML MAIL    Morgan Stanley

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From adam at cypherspace.org  Tue Sep  7 16:13:13 2004
From: adam at cypherspace.org (Adam Back)
Date: Tue, 7 Sep 2004 16:13:13 -0400
Subject: will spammers early adopt hashcash? (Re: Spam Spotlight on Reputation)
In-Reply-To: <Pine.LNX.4.58.0409070731140.7800@bolt.sonic.net>
References: <p06110416bd6252da2a82@[4.240.162.204]> <20040906221533.GA29063@danisch.de> <Pine.LNX.4.58.0409070731140.7800@bolt.sonic.net>
Message-ID: <20040907201313.GA10870@bitchcake.off.net>

On Tue, Sep 07, 2004 at 08:14:51AM -0700, bear wrote:
> I've turned down two job offers, though -- from software companies
> with "bulk mail products", looking for natural-language guys to
> build "paraphrase engines" to bypass spam filters [...] They're
> actually willing to hire engineers at specialist salaries to build
> new ways to bypass filters.

It is just market-led research into showing that the bayesian
anti-spam systems are fatally flawed, someone needs to do it :-).
Only when both sides are fully optimized will we see the true picture
of how spam can be stopped.

(Eg. this is why hashcash has been optimized to death in processor
specific assembly code ... spammers will do it so we must not kid
ourselves).

> We should not be at all surprised, when we offer a way to
> "auto-whitelist" email and therefore bypass filters at a lower
> cost than hiring engineers, that they're leaping onto it at
> a much higher rate than legit senders.

The higher than average SPF adoption rate by spammers confirms they
are early adopters.  I'd like to see them try to early-adopt hashcash
though ;-)

(There are similar incentives to SPF, maybe higher incentives as of
spamassassin 3.0.)

Well we'll see.  If they have lots of CPU from zombies and can get and
maintain more with limited effort maybe even they can, and CAMRAM's
higher cost stamp on introductions only will prevail as the preferred
method.

Adam

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From adam at homeport.org  Tue Sep  7 16:56:40 2004
From: adam at homeport.org (Adam Shostack)
Date: Tue, 7 Sep 2004 16:56:40 -0400
Subject: will spammers early adopt hashcash? (Re: Spam Spotlight on Reputation)
In-Reply-To: <20040907201313.GA10870@bitchcake.off.net>
References: <p06110416bd6252da2a82@[4.240.162.204]> <20040906221533.GA29063@danisch.de> <Pine.LNX.4.58.0409070731140.7800@bolt.sonic.net> <20040907201313.GA10870@bitchcake.off.net>
Message-ID: <20040907205640.GD9530@lightship.internal.homeport.org>

On Tue, Sep 07, 2004 at 04:13:13PM -0400, Adam Back wrote:

| Well we'll see.  If they have lots of CPU from zombies and can get and
| maintain more with limited effort maybe even they can, and CAMRAM's
| higher cost stamp on introductions only will prevail as the preferred
| method.

Adam,

	You've thought about this more than me.  What do you see as
equilibrium postal rates if the spammers have 10k, 100k, or a million
nodes to send?

        Will spammers run under nice?  Use your graphics card as a
co-processor?  Is the rate of new vulns high enough to keep their CPU
pools filled?

Adam

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From adam at homeport.org  Tue Sep  7 17:29:28 2004
From: adam at homeport.org (Adam Shostack)
Date: Tue, 7 Sep 2004 17:29:28 -0400
Subject: will spammers early adopt hashcash? (Re: Spam Spotlight on Reputation)
In-Reply-To: <p06110410bd63d43e5e6a@[4.240.162.155]>
References: <p06110416bd6252da2a82@[4.240.162.204]> <20040906221533.GA29063@danisch.de> <Pine.LNX.4.58.0409070731140.7800@bolt.sonic.net> <20040907201313.GA10870@bitchcake.off.net> <20040907205640.GD9530@lightship.internal.homeport.org> <p06110410bd63d43e5e6a@[4.240.162.155]>
Message-ID: <20040907212928.GG9530@lightship.internal.homeport.org>

On Tue, Sep 07, 2004 at 03:16:21PM -0600, R. A. Hettinga wrote:
| Apropos of nothing (specific) here...
| 
| At 4:56 PM -0400 9/7/04, Adam Shostack wrote:
| >What do you see as
| >equilibrium postal rates
| 
| Remember, boys and girls, prices are *discovered*, not calculated. Heck,
| you probably can't even *estimate* something like this with a straight
| face. Nobody should even try.
|
| Like any other security -- and hashcash *is* a security, a bearer
| certificate "reserved" by the sender's processor time -- we probably won't
| know what the equilibrium prices will be until they're issued, auctioned,
| if you will, by senders, and "bought" by receivers of mail...

So you can do some trivial calculations of how large a collision can
be found in the tcp_wait states on a zombie, and predict that a price
2x that requires that the spammers send half that much spam.  You can
certainly calculate a floor here, below which it is not worth
metering, and you can calculate a ceiling, above which its too
annoying to use.

Adam

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From jason at lunkwill.org  Tue Sep  7 19:41:43 2004
From: jason at lunkwill.org (Jason Holt)
Date: Tue, 7 Sep 2004 23:41:43 +0000 (UTC)
Subject: MD2 is not one way (!?)
Message-ID: <Pine.LNX.4.44.0409072341270.11477-100000@potato.zayda.com>


The list of accepted papers for AsiaCrypt:

http://www.iris.re.kr/ac04/

Includes one titled "The MD2 Hash Function is Not One-Way".  That's the first
I've heard about MD2; the other breaks were for md4 and md5.  Anyone know
details?

					-J


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From hal at finney.org  Tue Sep  7 20:52:38 2004
From: hal at finney.org (Hal Finney)
Date: Tue,  7 Sep 2004 17:52:38 -0700 (PDT)
Subject: Seth Schoen's Hard to Verify Signatures
Message-ID: <20040908005238.F218C57E2B@finney.org>

Seth Schoen of the EFF proposed an interesting cryptographic primitive
called a "hard to verify signature" in his blog at
http://vitanuova.loyalty.org/weblog/nb.cgi/view/vitanuova/2004/09/02 .
The idea is to have a signature which is fast to make but slow to verify,
with the verification speed under the signer's control.  He proposes
that this could be useful with trusted computing to discourage certain
objectionable applications.

The method Seth describes is to include a random value in the signature
but not to include it in the message.  He shows a sample signature
with 3 decimal digits hidden.  The only way to verify it is to try all
possibilities for the random values.  By controlling how much data is
hidden in this way, the signer can control how long it will take to
verify the signature.

This idea is nice and simple, but one disadvantage is that it is
probabilistic.  It works on average, but occasionally someone might
choose an n digit value which happens to be low (assuming the values are
chosen at random).  Then they don't get as much protection.  They could
fix this by eliminating too-low values, but then verifiers might exploit
that by doing low values last in their testing.

Another problem is that this method is inherently parallelizable, so
that someone with N computers could solve it N times faster, by having
each computer test a subset of the values.

An alternative is based on the paper, "Time-lock puzzles and
timed release Crypto", by Rivest, Shamir and Wagner, from 1996,
http://theory.lcs.mit.edu/~rivest/RivestShamirWagner-timelock.pdf or .ps.
They are looking more at the problem of encrypting data such that it can
be decrypted only after a chosen amount of computing time, but many of
their techniques are applicable to signatures.

The first solution they consider is essentially the same as Seth's,
doing an encryption where n bits of the encryption key are unknown, and
letting people search for the decryption key.  They identify the problems
I noted above (which I stole from their paper).  They also point out BTW
that this concept was used by Ralph Merkle in his paper which basically
foreshadowed the invention of public key cryptography.  Merkle had to
fight for years to get his paper published, otherwise he would be known
as the father of the field rather than just a pioneer or co-inventor.

The next method they describe can be put into signature terms as follows.
Choose the number of modular squarings, t, that you want the verifier
to have to perform.  Suppose you choose t = 1 billion.  Now you will
sign your value using an RSA key whose exponent e = 2^t + 1.  (You also
need to make sure that this value is relatively prime to p-1 and q-1,
but that is easily arranged, for example by letting p and q be strong
primes.)  The way you sign, even using such a large e, is to compute
phi = (p-1)*(q-1) and to compute e' = e mod phi, which can be done using
about 30 squarings of 2 mod phi.  You then compute the secret exponent
d as the multiplicative inverse mod phi of e', in the standard way that
is done for RSA keys.  Using this method you can sign about as quickly
as for regular RSA keys.

However, the verifier has a much harder problem.  He does not know phi,
hence cannot reduce e.  To verify, he has to raise the signature to
the e power as in any RSA signature, which for the exponent I described
will require t = 1 billion modular squaring operations.  This will be a
slow process, and the signer can control it by changing the size of t,
without changing his own work factor materially.

The authors also point out that modular squaring is an intrinsically
sequential process which cannot benefit from applying multiple computers.
So the only speed variations relevant will be those between individual
computers.

Another idea I had for a use of hard to verify signatures would be if
you published something anonymously but did not want to be known as
the author of it until far in the future, perhaps after your death.
Then you could create a HTV signature on it, perhaps not identifying
the key, just the signature value.  Only in the future when computing
power is cheap would it be possible to try verifying the signature under
different keys and see which one worked.

Hal Finney

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From astiglic at okiok.com  Tue Sep  7 23:06:39 2004
From: astiglic at okiok.com (Anton Stiglic)
Date: Tue, 7 Sep 2004 23:06:39 -0400
Subject: Maths holy grail could bring disaster for internet
In-Reply-To: <p06110402bd62d2bbbd51@[4.240.162.155]>
Message-ID: <20040908030641.885B1B407E@mail.okiok.com>

>Mathematicians could be on the verge of solving two separate million dollar
>problems. If they are right - still a big if - and somebody really has
>cracked the so-called Riemann hypothesis, financial disaster might follow.
>Suddenly all cryptic codes could be breakable. No internet transaction
>would be safe.

Looks like they are saying that if one can disprove the Riemann hypothesis,
then one could break (presumably) public key crypto, (presumably) by
factoring or computing DL.  But I am not aware of any factoring or DL
algorithm that can be drastically sped up if Riemann hypothesis is proven to
be false?

Here the author quotes the mathematician:


 "The whole of e-commerce depends on prime numbers. I have described the
primes as atoms: what mathematicians are missing is a kind of mathematical
prime spectrometer. Chemists have a machine that, if you give it a
molecule, will tell you the atoms that it is built from. Mathematicians
haven't invented a mathematical version of this. That is what we are after.
If the Riemann hypothesis is true, it won't produce a prime number
spectrometer. But the proof should give us more understanding of how the
primes work, and therefore the proof might be translated into something
                                     *****
that might produce this prime spectrometer. If it does, it will bring the
     *****
whole of e-commerce to its knees, overnight. So there are very big
implications."


This wording, with the word *might*, is more accurate, and not at all
equivalent to the assertion the author makes at the beginning.

Another bad article.

--Anton

 


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From smb at research.att.com  Tue Sep  7 23:12:03 2004
From: smb at research.att.com (Steve Bellovin)
Date: Tue, 07 Sep 2004 23:12:03 -0400
Subject: references on traffic analysis?
Message-ID: <20040908031203.5295E1AE89@berkshire.research.att.com>

What are some of the classic, must-read, references on traffic analysis?
(I'm familiar with the Zendian problem, of course.)


		--Steve Bellovin, http://www.research.att.com/~smb



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From hal at finney.org  Wed Sep  8 03:08:01 2004
From: hal at finney.org (Hal Finney)
Date: Wed,  8 Sep 2004 00:08:01 -0700 (PDT)
Subject: Joux attack against multipreimages
Message-ID: <20040908070801.7526757E2C@finney.org>

I was looking at Joux's paper again and I noticed that he also had
some comments regarding preimage resistance.  I believe these imply a
weakness even in the construction I proposed of using a double width
hash and then collapsing the output down to single width at the end.

My argument was that if the hash output size was n bits, so the internal
width is 2n, then it would take 2^n work to find a collision on an
internal block, but that was more work than it would take to break the
hash function by brute force, hence it was not an attack.  However I
forgot that there are some problems which an n-bit hash should resist
with even stronger than 2^n force.

Specifically, the problem of finding multiple preimages, say 2^k preimages
of some fixed value, should take about 2^k * 2^n work for an ideal hash
function.  There is no shortcut beyond trying random values and seeing
if you get lucky, and for each value the chance of success is 1 in 2^n.

However, Joux shows how to do better than this.  He uses his trick
of setting up k blocks and finding a collision in each.  Even with my
double width construction that takes k*2^n work.  This gives us a 2^k
multicollision.  Now comes the new idea.  Add one more block.  Do an
exhaustive search on that block to map the output from the multicollision
to the desired hash function output, the one we are trying to find
preimages of.  That should take about 2^n work because the chance of
success for any input is 1 in 2^n, since the actual hash output size is
n bits after folding.

Now this gives us 2^k preimages.  For each of the 2^k possible choices
in the multicollision, the extra block maps us to the desired output.
We did (k+1)*2^n work and got 2^k preimages, but it should have taken
us 2^k * 2^n work.

This means that even the double-width hash construction is not as secure
as an ideal hash.  It is safe against multicollisions but not against
multipreimages.

Hal Finney

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Wed Sep  8 13:28:49 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Wed, 8 Sep 2004 11:28:49 -0600
Subject: FSTC Issues Call for Participation for Two New Projects
Message-ID: <p0611042ebd64f1536f44@[4.240.162.155]>

The Financial Services Technology Consortium wants to assist banks in
providing an "authentication service to government agencies"...

Cheers,
RAH

--- begin forwarded text


Date: Wed, 08 Sep 2004 11:39:05 -0400
From: Jim Salters <jim.salters at fstc.org>
Subject: FSTC Issues Call for Participation for Two New Projects
To: members at ls.fstc.org
Thread-Index: AcSVufg77617vLQBRSC14LCgFisSUw==
List-Post: <mailto:members at ls.fstc.org>
List-Subscribe: <http://ls.fstc.org/subscribe>,
 <mailto:members-request at ls.fstc.org?body=subscribe>
List-Archive: <http://ls.fstc.org/archives/members/>
List-Help: <http://ls.fstc.org/elists/admin.shtml>,
 <mailto:members-request at ls.fstc.org?body=help>
List-Id: <members.ls.fstc.org>

To: FSTC Members and Friends
From: Jim Salters, Director of Tech Initiatives and Project Development

We are pleased to announce a "call for participation" for two new FSTC
projects.  Each has a committed core group of member institutions and
vendors who solicit further participation from fellow members:

1.  FSTC e-Authentication Initiative: Business and Technology
Proof-of-Concept
2.  Business Continuity: Compliance and Status Reporting Project
____________________

1.  FSTC e-Authentication Initiative: Business and Technology
Proof-of-Concept

Prospectus: http://fstc.org/projects/new.cfm#eauth

This 5-month project will assess the viability of the potential business
opportunity that exists for financial institutions to leverage their online
customer relationships and provide an authentication service to government
agencies, and to integrate these services into their own online
applications.  FSTC, jointly with the GSA's E-Authentication Initiative
Project Management Office (EAI PMO), propose to launch a three-track project
to ascertain the business model, legal framework, and technical viability of
using FIs' identity credentials to permit consumers and businesses to access
secure online government applications.

The GSA is funding the business track of the initiative.  There is no cost
to financial institutions, and a $5,000 fee for associate members.   In
addition, a resource commitment is required for all participants, as
outlined in the prospectus.  Participation commitments are requested by Sept
24th, and the target kickoff is the week of October 4th.

An informational conference call has been scheduled for:

Wednesday Sept 15th, 2pm EDT
512-225-3050, 71782#
__________________

2.  Business Continuity: Compliance and Status Reporting Project

Prospectus: http://fstc.org/projects/new.cfm#compliance

The FSTC Business Continuity Standing Committee proposes an initiative to
assist the financial industry in coming to a common understanding on the
meaning of continuity regulation, prioritization of compliance related
activities, and creating efficiencies in documenting regulatory compliance
status.    To establish a clear understanding of the regulatory environment,
a list of continuity related guidance will be pulled together along with the
name of the agency responsible.   Each regulation will be reviewed and a
clearly worded summary of the continuity requirements will be developed.
Where possible the regulatory agencies will be contacted for clarification
on specific points.  Common themes and requirements will be documented and
prioritized.

>From this list of common themes and prioritized requirements a questionnaire
will be developed which will allow a FI to provide or collect continuity
compliance status.  The project will focus on providing straight forward
interpretations of what is needed for an FI to comply with current
regulations.

The final product will provide:

.	A comprehensive list of all current regulatory guidance related to
business continuity, an overview of the requirements of the key components
and the agency that produced it.
.	Prioritized summary of the key continuity requirements that FIs must
address and the timing for implementing them.
.	Standardized questionnaire that FIs can utilize to collect or
provide status of compliance with continuity regulatory requirements.
.	An ongoing forum for discussion on regulatory direction and for
sharing feedback/experiences other FIs have had with regulators.
.	A documented process that can be utilized to allow FSTC and its
members to maintain the regulatory summary and questionnaire.

Project Fees:
---------------

Financial Institutions:
$15,000  Assets over $100 billion (including affiliates)
$12,000  Assets from $50 billion to $99 billion (including affiliates)
$9,000    Assets from $20 billion to $49 billion (including affiliates)
$3,300    Assets under $19 billion (including affiliates)

Technology Companies:
$15,000  Revenue/funding over $100 million (including affiliates)
$12,000  Revenue/funding  from $50 million to $99 million (including
affiliates)
$9,000    Revenue/funding from $20 million to $49 million (including
affiliates)
$3,300    Revenue/funding under $19 million (including affiliates)


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://ls.fstc.org/subscriber>

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From rah at shipwright.com  Wed Sep  8 13:55:53 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Wed, 8 Sep 2004 11:55:53 -0600
Subject: Wireless security remains as main threat to mobility
Message-ID: <p06110432bd64f76adcc4@[4.240.162.155]>

<http://www.ottawabusinessjournal.com/283824489528668.php>

Ottawa Business Journal - News

Wireless security remains as main threat to mobility
By Ottawa Business Journal Staff
Mon, Sep 6, 2004 12:00 AM EST



 The wireless industry needs a lasting solution to one of its biggest
threats: outside intrusion.

 According to Victor Shevchenko, director of business development for the
Global Mobile Enterprise 2004 Conference, wireless security will be a main
discussion point at the conference, Sept. 14 to 16 at the Brookstreet Hotel.

 "Mainly, we're talking about the protection of electronic data transported
and received by Palm Pilots, mobile phones and computers connected through
wireless networks," said Mr. Shevchenko, who organized the conference with
Zora Arnautovic, director of the organizing committee.

 "The general trend is to get people mobile when they're offsite, but the
key challenges are: how can we ensure that the communication is secure,
that no data is compromised and that access to corporate networks through
secure wireless channels is safe?" said Mr. Shevchenko. "Protecting the
access and integrity of data being sent back and forth is the real
challenge."

 There is no universal standard acknowledged by the wireless industry as
the safest, he added. Virtual private networks (VPNs) are one way a company
can improve its wireless security, he said, adding new-generation
standards, such as WiMAX, are another.

 "One of the main purposes of our conference will be to determine what the
most promising (standard) is" so the industry can move forward, he said.

 Mark Zimmerman, vice-president of sales at Toronto-based Nextair Corp.,
said there is no "one-size-fits-all solution" to the issue of standards.
Mr. Zimmerman will attend the conference with Nextair CEO Ron Close, who
will lead a discussion on wireless applications.

 "There have been a number of hiccups along the way when securing
information that's being delivered over the air (between two wireless
devices)," said Mr. Zimmerman, describing the early wireless fidelity
standards as "not very good from a security perspective".

 In the past, officials from the federal government's Communications
Security Establishment (CSE) warned that cellphones, for example, should
not be relied on for transmitting sensitive data.

 "(They) could very easily be compromised," said Richard MacLean, a CSE
communications security engineer, at a May conference on wireless security.

 In a bid to ensure the encryption capability of public sector cellphones
is up to date, the CSE is testing global system for mobile phones equipped
to handle top-secret voice data.

 "Now we're approaching a level where (wireless standards) are secure for
many applications, if not for all," said Mr. Zimmerman. The one thing not
talked about is securing wireless devices themselves, he added.

 "When you look at PDAs that leave a (company's) building, they often have
the corporate crown jewels on them. In most cases, we do have the
technology, but we need to spend more time educating the marketplace and
our customers about using that technology and building it into products,
rather than turning to security as an afterthought."

 Mr. MacLean's advice is to use approved cryptography solutions, strong
passwords that are changed often and anti-virus software on PDAs and PCs
that can be updated frequently.

 The threat of outside intrusion is "very viable" because of ample hardware
and software capable of compromising wireless connectivity, said Mr.
Shevchenko.

 Such equipment can have "serious implications" for corporate productivity,
revenue and data, he added.

 While BlackBerries and other handheld e-mail devices are widely used by
businesspeople, users should know that, without private keys that can
encrypt the data, sensitive information can easily be poached, said Mr.
MacLean.

 The medical and financial fields have led by example when it comes to
wireless security, said Mr. Zimmerman, mostly because it's critical
security failures are avoided in these fields.

 Currently, new medical standards are being worked on to ensure there is no
electromagnetic interference with other pieces of medical equipment.

 In the transport industry, wireless security has become paramount, as
airports adopt wireless baggage handling systems.

 To protect its wireless system, Toronto's Pearson International Airport,
for example, uses additional software that encrypts and protects all
baggage-related transmissions to ensure no one from the outside can
manipulate the information in any way, according to Gary Long, general
manager of information technology at the Greater Toronto Airport Authority.

 The transport industry will be the subject of a wireless case study at the
conference, said Mr. Shevchenko.

 "We want to see where this is going and how it can be ensured. In all
honesty, I'm as eager as anyone to get some answers to some of these
questions."



-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From rah at shipwright.com  Wed Sep  8 13:55:24 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Wed, 8 Sep 2004 11:55:24 -0600
Subject: Polymer serves up single photons
Message-ID: <p06110433bd64f76ddd55@[4.240.162.155]>

<http://www.trnmag.com/Stories/2004/090804/Polymer_serves_up_single_photons_090804.html>

TRN 090804

 Polymer serves up single photons

September 8/15, 2004

By Eric Smalley, Technology Research News

Quantum cryptography in theory allows someone to send a secret key and know
for sure that the key has not been seen by anyone but the intended
recipient. Each bit of information in the key is represented by attributes
of a photon, which makes it impossible for an eavesdropper to both read and
replace all the photons in a string.

 Although commercial quantum cryptography systems exist, they use photon
sources that sometimes represent information using a single photon and
sometimes a few photons. Sources that reliably emit just a single photon at
a time are needed to ensure perfect security. The goal is a reliable,
inexpensive device that emits single photons on demand at room temperature.

 Researchers from the Georgia Institute of Technology, the University of
Tennessee, and Oak Ridge National Laboratory have made a room-temperature,
single-photon source using polymer molecules.

 The device consists of precisely oriented single molecules of a
semiconducting polymer that are applied to a surface using a simple
spray-on technique, said Tae-Hee Lee, now a researcher at Stanford
University. "We proved that [a] simple, one-step polymer processing
technique can generate strong and stable single-photon sources," said Lee.
The method is an inexpensive way of generating single photons, he said.

 The single-photon source could be used in quantum cryptography devices and
eventually for quantum computing, said Lee.

 The polymer is similar to materials used to make new types of organic
light-emitting diodes. The researchers' prototype contains
10-nanometer-long single-chain molecules oriented perpendicular to a glass
surface. This orientation allows them to emit photons, and because they are
individual molecules, they emit one photon at a time.

 The researchers produced the device by making a solution of the polymer
polyethylene vinylene in toluene and spraying it through a
5-micron-diameter nozzle. This resulted in an aerosol of 5- to 10-micron
droplets, which rapidly evaporated, leaving the polymer molecules on the
glass surface.

 Researchers have made single-photon sources from fluorescent molecules,
but these tend to fade in a matter of minutes. The researchers' polymer
molecules last several hours.

 The most important application for the researchers device is quantum
cryptography. The ability to cheaply produce room-temperature single-photon
sources is also step forward for quantum computers. Quantum computers,
which manipulate information stored in the attributes of particles like
atoms and photons, have the potential to solve certain very large problems
much more quickly than conventional computers.

 Researchers generally agree that practical quantum computers are one to
two decades from realization.

 The researchers are working to make the material more stable, said Lee.
The researchers' prototype emits photons after being energized with lasers.
For practical applications, single-photon sources will need to be
stimulated electrically.

 Lee's research colleagues were Pradeep Kumar from the University of
Tennessee, Adosh Mehta and Michael D. Barnes from Oak Ridge National
Laboratory, and Kewei Xu and Robert M. Dixon from the Georgia Institute of
Technology. The work appeared in the July 5, 2004 issue of Applied Physics
Letters. The research was funded by the Advanced Research and Development
Activity (ARDA), the National Science Foundation (NSF), the Alfred P. Sloan
Foundation and Henry and Camilla Dreyfus Foundation.

Timeline:   unknown; 10-20 years
 Funding:   Government, Private
 TRN Categories:  Materials Science and Engineering; Quantum Computing and
Communications
 Story Type:   News
 Related Elements:  Technical paper, "Oriented Semiconducting Polymer
Nanostructures as on-Demand Room-Temperature Single-Photon Sources,"
Applied Physics Letters, July 5, 2004



-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From foo.o.matic at gmail.com  Wed Sep  8 13:55:50 2004
From: foo.o.matic at gmail.com (Foo-o-Matic)
Date: Wed, 8 Sep 2004 20:55:50 +0300
Subject: Some additional info about "Which book for a newbie to cryptography?"
In-Reply-To: <20040907152927.A21238@pull.privacy.nb.ca>
References: <d56b214404090409067961bd42@mail.gmail.com>
	 <d56b2144040907041925fcac54@mail.gmail.com>
	 <20040907152927.A21238@pull.privacy.nb.ca>
Message-ID: <d56b214404090810553407d31@mail.gmail.com>

Ok, I have read both yours and Sandy Harris's replies, and looked
again at my previous message, and the opinions are kinda ambiguous.
I think I will go to the library and pick one of them.
anyway, I don't feel I need a book that gets very or too deep, because
I really don't have much time for that. I just need a good book which
will teach me the main and important things, and won't be too much
mathy (altho I passes the Discrete Math 1 and 2 courses, I don't
really like it, maybe except combinatorics and that theory with P Q's,
and T(), F()'s (I don't know its name in english, it isn't my native
language).
well thanks for the help so far, you have all been very helpful.


On Tue, 7 Sep 2004 15:29:27 +0100, M Taylor <mctylr at privacy.nb.ca> wrote:
> On Tue, Sep 07, 2004 at 01:19:18PM +0200, Foo-o-Matic wrote:
> > 1. I'm a 2nd year student of BA in Computer Science, I finished 5
> >
> > - Cryptography : theory and practice: 2nd ed. / Douglas R. Stinson
> > - Handbook of applied cryptography / Alfred J. Menezes, Paul C. van
> > Oorschot, Scott A. Vanstone
>  
> The first is a textbook aimed at senior undergrad students or first
> year graduate students, and one of the more frequently used textbooks
> at university. Either it or A Course in Number Theory and Cryptography
> by Neil Koblitz are good places to start.
> 
> The Handbook of Applied Cryptography is a very useful reference,
> although since it predates AES it does show its age a bit. Still,
> it is IMHO better than Schneier's Applied Cryptography for going into
> details.
> 
> For an historic overview and practical examples of "unbreakable
> encryption" failing look for either The Code Book by Simon Singh
> and/or The Codebreakers by David Kahn (ISBN 0684831309). I really
> recommend you spend some time reading at least one of these.
> 
> > As you can see, no Schneier here.
> 
> Applied Cryptography is overrated as a "bible" IMHO, though when combined
> with Practial Cryptography the misleading dictum of "sprinkling a little
> bit of crypto over things will make it secure" is tempered.
> 
> Read <http://www.counterpane.com/whycrypto.html>,
>  <http://www.cl.cam.ac.uk/users/rja14/wcf.html>, and
>  <http://www.counterpane.com/pitfalls.html>.
> 
> Good luck.
> 
>

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From adam at homeport.org  Wed Sep  8 16:21:53 2004
From: adam at homeport.org (Adam Shostack)
Date: Wed, 8 Sep 2004 16:21:53 -0400
Subject: references on traffic analysis?
In-Reply-To: <20040908031203.5295E1AE89@berkshire.research.att.com>
References: <20040908031203.5295E1AE89@berkshire.research.att.com>
Message-ID: <20040908202153.GF33460@lightship.internal.homeport.org>

On Tue, Sep 07, 2004 at 11:12:03PM -0400, Steve Bellovin wrote:
| What are some of the classic, must-read, references on traffic analysis?
| (I'm familiar with the Zendian problem, of course.)

A. Back, U. Muller, and A. Stiglic, Traffic Analysis Attacks and
Trade-Offs in Anonymity Providing Systems, Proceedings of the 4th
Information Hiding Workshop (IHW2001), Springer-Verlag, LNCS v. 2137,
pp. 243-254. http://crypto.cs.mcgill.ca/~stiglic/Papers/traffic.pdf

There have been some good papers in the PET Workshop series, if you
care about analysis of MIX type networks.  http://petworkshop.org/

Adam


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From mads at opencs.com.br  Wed Sep  8 16:29:27 2004
From: mads at opencs.com.br (Mads Rasmussen)
Date: Wed, 08 Sep 2004 17:29:27 -0300
Subject: MD2 is not one way (!?)
In-Reply-To: <Pine.LNX.4.44.0409072341270.11477-100000@potato.zayda.com>
References: <Pine.LNX.4.44.0409072341270.11477-100000@potato.zayda.com>
Message-ID: <413F6BA7.3030002@opencs.com.br>

Jason Holt wrote:
> Includes one titled "The MD2 Hash Function is Not One-Way".  That's the first
> I've heard about MD2; the other breaks were for md4 and md5.  Anyone know
> details?

Actually there was a paper analysing the MD2 algorithms back in 1997: N. 
Rogier and P Chauvaud, "MD2 is not secure without the Checksum Byte", 
Design, codes and Cryptography, 12(3):245-251 - an early version was 
presented at SAC 1995

The abstract of the new paper by Fr?d?ric Muller describing a pre-image 
attack, more theoretical than practical although very interesting,

"MD2 is an early hash function developed by Ron Rivest for RSA Security, 
that produces message digests of 128 bits. In this paper, we show that 
MD2 does not reach the ideal security level of 2^128 . We
describe preimage attacks against the underlying compression function,
the best of which has complexity of 2^73 . As a result, the full MD2 
hash can be attacked in preimage with complexity of 2^104"

-- 
Mads Rasmussen
Open Communications Security
+55 11 3345 2525
http://www.opencs.com.br

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From daw at cs.berkeley.edu  Wed Sep  8 16:37:22 2004
From: daw at cs.berkeley.edu (David Wagner)
Date: Wed, 8 Sep 2004 13:37:22 -0700 (PDT)
Subject: Seth Schoen's Hard to Verify Signatures
Message-ID: <200409082037.i88KbM69029777@taverner.CS.Berkeley.EDU>

Hal Finney wrote:
>[...] "hard to verify signature" [...]
>Choose the number of modular squarings, t, that you want the verifier
>to have to perform.  Suppose you choose t = 1 billion.  Now you will
>sign your value using an RSA key whose exponent e = 2^t + 1.
>The way you sign, even using such a large e, is to compute
>phi = (p-1)*(q-1) and to compute e' = e mod phi, which can be done using
>about 30 squarings of 2 mod phi.  You then compute the secret exponent
>d as the multiplicative inverse mod phi of e', in the standard way that
>is done for RSA keys.  Using this method you can sign about as quickly
>as for regular RSA keys.
>
>However, the verifier has a much harder problem. [...] To verify [...]
>will require t = 1 billion modular squaring operations.

This signature scheme has an interesting property: once you've done
the lengthy computation, you can quickly prove to someone else that
the signature is valid.  In particular, there is a short and easy to
prove that the signature is valid, based on listing x, x^2, x^4, x^16,
x^256, x^65536, ..., x^e and giving a zero knowledge proof that your
list is correct.  The details can be found here (see esp. Section 3):
  D. Boneh, M. Naor, "Timed Commitments", CRYPTO 2000.
  http://crypto.stanford.edu/~dabo/abstracts/timedcommit.html
The signer can also create a proof like this if he wants.  Note that
Boneh and Naor consider a somewhat similar but not equivalent notion of
timed signatures, which may also be of interest.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From adam at cypherspace.org  Wed Sep  8 17:30:51 2004
From: adam at cypherspace.org (Adam Back)
Date: Wed, 8 Sep 2004 17:30:51 -0400
Subject: Seth Schoen's Hard to Verify Signatures
In-Reply-To: <20040908005238.F218C57E2B@finney.org>
References: <20040908005238.F218C57E2B@finney.org>
Message-ID: <20040908213051.GA29246@bitchcake.off.net>

Hi

I proposed a related algorithm based on time-lock puzzles as a step
towards non-parallelizable, fixed-minting-cost stamps in section 6.1
of [1], also Dingledine et al observe the same in [2].

The non-parallelizable minting function is in fact the reverse: sender
encrypts (expensively) and the verifier encrypts again (but more
cheaply) and compares, but I think the relationship is quite analogous
to the symmetry between RSA encryption and RSA signatures.

I think maybe you have observed an additional simplification.  In my
case I use sender chooses x randomly (actually hash output of random
value and resource string), and computes y = x^{x^w} mod n as the work
function (expensive operation); and z = x^w mod phi(n), y =?  x^z mod
n as the cheap operation (verification).

I think your approach could be applied on the encryption side too
resulting in simpler, faster verification.  Instead it would be:

x is random, compute y = x^{2^t+1} mod n; verify x =? y^d mod n

I'll add a note about that when I get around to updating it next.

Adam

[1] Hashcash - Amortizable Publicly Auditable Cost-Functions
http://www.hashcash.org/papers/amortizable.pdf

[2] Andy Oram, editor.  Peer-to-Peer: Harnessing the Power of
Disruptive Technologies. O'Reilly and Associates, 2001.  Chapter 16
also available as
http://freehaven.net/doc/oreilly/accountability-ch16.html.

On Wed, Sep 08, 2004 at 11:48:02AM -0700, "Hal Finney" wrote:
> Seth Schoen of the EFF proposed an interesting cryptographic primitive
> called a "hard to verify signature" in his blog at
>
> An alternative is based on the paper, "Time-lock puzzles and
> timed release Crypto", by Rivest, Shamir and Wagner, from 1996,
> [...]
> Choose the number of modular squarings, t, that you want the
> verifier to have to perform.  [...] you will sign your value using
> an RSA key whose exponent e = 2^t + 1.  > The way you sign, even
> using such a large e, is to compute phi = (p-1)*(q-1) and to compute
> e' = e mod phi, which can be done using about 30 squarings of 2 mod
> phi.  You then compute the secret exponent d as the multiplicative
> inverse mod phi of e', in the standard way that is done for RSA
> keys.  Using this method you can sign about as quickly as for
> regular RSA keys.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From hal at finney.org  Wed Sep  8 18:08:00 2004
From: hal at finney.org (Hal Finney)
Date: Wed,  8 Sep 2004 15:08:00 -0700 (PDT)
Subject: Seth Schoen's Hard to Verify Signatures
Message-ID: <20040908220800.0E0BF57E2C@finney.org>

Hi, Adam - Yes, that's interesting.  Seth Schoen's posting and
subsequent blog entries do compare his goals with hashcash and similar
stamp minting systems; where hashcash wants to make minting expensive
and verification easy, Seth's HTV signatures aim to make signing easy
and verifying expensive.

> I think maybe you have observed an additional simplification.  In my
> case I use sender chooses x randomly (actually hash output of random
> value and resource string), and computes y = x^{x^w} mod n as the work
> function (expensive operation); and z = x^w mod phi(n), y =?  x^z mod
> n as the cheap operation (verification).
>
> I think your approach could be applied on the encryption side too
> resulting in simpler, faster verification.  Instead it would be:
>
> x is random, compute y = x^{2^t+1} mod n; verify x =? y^d mod n

The main advantage here I think is that d can be precomputed.  However you
could do the same by using y = x^{2^w} instead of x^{x^w}.  Then you could
precompute z = 2^w mod phi and you would have a single exponentiation
to verify just like in my scheme.  The RSW time-lock-puzzle paper does
it this way, they use 2^w as the exponent where w is the work factor.

Hal

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Wed Sep  8 19:01:31 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Wed, 8 Sep 2004 17:01:31 -0600
Subject: potential new IETF WG on anonymous IPSec
Message-ID: <p0611043dbd653fb5b9fc@[4.240.162.155]>


--- begin forwarded text


From: Paul Syverson <syverson at itd.nrl.navy.mil>
To: nymip-res-group at nymip.org
Cc: Paul Syverson <syverson at itd.nrl.navy.mil>
Subject: potential new IETF WG on anonymous IPSec
User-Agent: Mutt/1.4.1i
Sender: nymip-res-group-admin at nymip.org
List-Id: Primary NymIP discussion list <nymip-res-group.nymip.org>
List-Post: <mailto:nymip-res-group at nymip.org>
List-Help: <mailto:nymip-res-group-request at nymip.org?subject=help>
List-Subscribe: <http://www.nymip.org/mailman/listinfo/nymip-res-group>,
	<mailto:nymip-res-group-request at nymip.org?subject=subscribe>
List-Archive: <http://www.nymip.org/pipermail/nymip-res-group/>
Date: Wed, 8 Sep 2004 15:24:53 -0400

From: Catherine Meadows <meadows at itd.nrl.navy.mil>
Date: Tue, 7 Sep 2004 11:29:56 -0400


Paul:

The IETF has been discussing setting up a working group
for anonymous IPSec.  They will have a BOF at the next IETF
in DC in November.  They're also setting up a mailing list you
might be interested in if you haven't heard about it already.
Information is below.

At 10:08 PM -0700 9/6/04, Joe Touch wrote:
>Hi, all,
>
>To follow-up on related presentations at both SAAG and TCPM, we've
>created a mailing list for discussions of anonymous security.
>
>Further information on the list and how to join it, as well as
>pointers to related resources can be found at:
>
>	http://www.postel.org/anonsec
>
>The mailing list address is:	anonsec at postel.org
>
>Joe
>


Cathy

----------


_______________________________________________
NymIP-res-group mailing list
NymIP-res-group at nymip.org
http://www.nymip.org/mailman/listinfo/nymip-res-group

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From daw at cs.berkeley.edu  Thu Sep  9 03:11:17 2004
From: daw at cs.berkeley.edu (David Wagner)
Date: Thu, 9 Sep 2004 00:11:17 -0700 (PDT)
Subject: Seth Schoen's Hard to Verify Signatures
In-Reply-To: <20040909063514.EB03D57E2B@finney.org> from "Hal Finney" at Sep 08, 2004 11:35:14 PM
Message-ID: <200409090711.i897BHka001081@taverner.CS.Berkeley.EDU>

> Hi, David - I had thought about that short-validity-proof but I don't
> believe it works.  It works for the signer but not for the verifier.

Ahh, yes, I see.  You're absolutely right.  I was too quick to jump
to conclusions, but your argument convinces me.  I withdraw my claim
about the verifier being able to convince others of the validity of
the signature -- sorry about that.  Thanks.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From hal at finney.org  Thu Sep  9 02:35:14 2004
From: hal at finney.org (Hal Finney)
Date: Wed,  8 Sep 2004 23:35:14 -0700 (PDT)
Subject: Seth Schoen's Hard to Verify Signatures
Message-ID: <20040909063514.EB03D57E2B@finney.org>

Hi, David - I had thought about that short-validity-proof but I don't
believe it works.  It works for the signer but not for the verifier.

> This signature scheme has an interesting property: once you've done
> the lengthy computation, you can quickly prove to someone else that
> the signature is valid.  In particular, there is a short and easy to
> prove that the signature is valid, based on listing x, x^2, x^4, x^16,
> x^256, x^65536, ..., x^e and giving a zero knowledge proof that your
> list is correct.  The details can be found here (see esp. Section 3):
>   D. Boneh, M. Naor, "Timed Commitments", CRYPTO 2000.
>   http://crypto.stanford.edu/~dabo/abstracts/timedcommit.html
> The signer can also create a proof like this if he wants.  Note that
> Boneh and Naor consider a somewhat similar but not equivalent notion of
> timed signatures, which may also be of interest.

The timeline proof is based on the standard ZK proof of two equal
discrete logs.  In this case we have (x, x^(2^(2^n))) as one pair and
(x^(2^(2^n)), x^(2^(2^(n+1)))) as the other.  In each case the 2nd number
is the first number raised to the 2^(2^n) power.

The standard ZK proof for dual discrete logs works as follows.
We have y=g^u and z=h^u and want to prove that we know such a u.
We choose a random k and commit with v=g^k and w=h^k.  We then create
a challenge c by hashing various relevant values; at a minimum
c = hash(v,w).  Then we create a response r=c*u+k.  The verification is
g^r==y^c*v and h^r==z^c*w.

This works fine for the signer as all the values can be less than phi.
But for the verifier who does not know phi, the problem is that the
values are too big.  u in this case is 2^(2^n) from my example above,
where 2^n will be the number of squarings the verifier must do, no doubt
a billion or more likely billions of billions, as we get to the last
step in the timeline.  And further, r will be of the same order as u.
Then running the verification requires computing g^r and h^r, which
will take approximately 2^n squarings.  But that is how many squarings
it took to compute these timeline elements in the first place.  So the
2nd verifier cannot verify the ZK proof created by the first verifier
in much less time than the first verifier took to compute the values
the slow way.

I think the paper you pointed to by Boneh and Naor actually has a
different approach which works better.  The recipient gets a value
which, once he does the long work of decryption, will turn into a valid
signature.  And the timeline provides a ZK proof that it will work out
that way.  Then you'd want to make the ZK proof be designated verifier
so that the recipient can't show it around.  This way the recipient
is assured that if he does the work he will get the sig; and once he
gets the sig he can show it; but until he does the work he doesn't have
anything he can show.

I haven't read the paper for a few years so I'm not sure I'm remembering
it right; these extensions might be in a subsequent paper.  I think in
particular the ability to recover a vanilla signature was follow-on work.
But the basic idea is in the Boneh and Naor paper.

Hal

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From hughejp at mac.com  Thu Sep  9 09:21:01 2004
From: hughejp at mac.com (james hughes)
Date: Thu, 9 Sep 2004 09:21:01 -0400
Subject: references on traffic analysis?
In-Reply-To: <20040908031203.5295E1AE89@berkshire.research.att.com>
References: <20040908031203.5295E1AE89@berkshire.research.att.com>
Message-ID: <184D31B2-0263-11D9-B1D5-000A95A27482@mac.com>


On Sep 7, 2004, at 11:12 PM, Steve Bellovin wrote:
> What are some of the classic, must-read, references on traffic 
> analysis?
> (I'm familiar with the Zendian problem, of course.)

In looking through my library, I came across two references (I would 
not say 'must read' though).

"Code Breakers" (David Kahn) has several short real world examples. It 
is not a treatise per-se, but is interesting.

"The Hut Six Story, Breaking the Enigma Codes" (Gordon Welchman) 
describes many of the aspects of traffic analysis as a precursor to an 
actual cryptanalysis attack.

I don't know any study texts on this subject.

Thanks

jim

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From hal at finney.org  Thu Sep  9 15:57:29 2004
From: hal at finney.org (Hal Finney)
Date: Thu,  9 Sep 2004 12:57:29 -0700 (PDT)
Subject: potential new IETF WG on anonymous IPSec
Message-ID: <20040909195729.4798957E2B@finney.org>

> The IETF has been discussing setting up a working group
> for anonymous IPSec.  They will have a BOF at the next IETF
> in DC in November.  They're also setting up a mailing list you
> might be interested in if you haven't heard about it already.
> ...
> 	http://www.postel.org/anonsec

To clarify, this is not really "anonymous" in the usual sense.  Rather it
is a proposal to an extension to IPsec to allow for unauthenticated
connections.  Presently IPsec relies on either pre-shared secrets or a
trusted third party CA to authenticate the connection.  The new proposal
would let connections go forward using a straight Diffie-Hellman type
exchange without authentication.  It also proposes less authentication
of IP message packets, covering smaller subsets, as an option.

The point has nothing to do with anonymity; rather it is an attempt
to secure against weaknesses in TCP which have begun to be exploited.
Sequence number guessing attacks are more successful today because of
increasing bandwidth, and there have been several instances where they
have caused disruption on the net.  While workarounds are in place, a
better solution is desirable.

This new effort is Joe Touch's proposal to weaken IPsec so that it uses
less resources and is easier to deploy.  He calls the weaker version
AnonSec.  But it is not anonymous, all the parties know the addresses
of their counterparts.  Rather, it allows for a degree of security on
connections between communicators who don't share any secrets or CAs.
I don't think "anonymous" is the right word for this, and I hope the
IETF comes up with a better one as they go forward.

Hal Finney

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Thu Sep  9 21:43:44 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Thu, 9 Sep 2004 21:43:44 -0400
Subject: Web security firm Certicom cuts Q1 loss to US$1.2M from US$1.6M
Message-ID: <p06110408bd66b7317d35@[66.149.49.5]>

<http://www.canada.com/components/printstory/printstory4.aspx?id=4282a128-836f-49c7-ad9b-4c8db6b888c7>
 

Web security firm Certicom cuts Q1 loss to US$1.2M from US$1.6M

 

Canadian Press

Thursday, September 09, 2004



 MISSISSAUGA, Ont. (CP) - Certicom Corp., a specialist in Internet security
software, has cut its first-quarter loss to $1.2 million US from $1.4
million US a year ago.

 For the quarter ended July 31, the per-share loss was three cents,
compared with five cents a year earlier, the Mississauga-based firm
(TSX:CIC) reported Thursday.

 Revenue rose to $2.9 million from $2.2 million US. The firm reports in
U.S. dollars.

 Highlights in the quarter included a $3.5-million-US contract with
Research In Motion (TSX:RIM) that expands use of Certicom security in
BlackBerry communication devices.

 "We are pleased with our results for the first quarter as we continue to
see increased adoption of elliptic curve cryptography, or ECC, in the
market," CEO Ian McKinnon said in a release.

 "This will be the long-term growth driver for our product and intellectual
property licensing business."

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From ray at unipay.nl  Fri Sep 10 03:56:37 2004
From: ray at unipay.nl (R. Hirschfeld)
Date: Fri, 10 Sep 2004 09:56:37 +0200
Subject: [Andrew.Patrick@nrc-cnrc.gc.ca: [fc-announce] FC'05: PAPER SUBMISSION DEADLINE EXTENDED TO SEPT. 17]
Message-ID: <200409100756.i8A7ubAK009327@home.unipay.nl>

From: Andrew Patrick <Andrew.Patrick at nrc-cnrc.gc.ca>
Subject: [fc-announce] FC'05: PAPER SUBMISSION DEADLINE EXTENDED TO SEPT. 17
To: fc-announce at ifca.ai
Date: Wed, 08 Sep 2004 18:22:51 -0400
Organization: National Research Council of Canada

   *** NOTE: PAPER SUBMISSION DEADLINE EXTENDED TO SEPT. 17 ***

                          Call for Papers
          FC'05: Financial Cryptography and Data Security
                     http://www.ifca.ai/fc05/

                  Ninth International Conference
                    February 28 - March 3, 2005
               Roseau, The Commonwealth Of Dominica

             Submissions Due Date: September 17, 2004

     Program Chairs: Andrew Patrick (NRC Canada) and Moti Yung
                       (Columbia University)
       General Chair: Stuart Schechter (Harvard University)

Financial Cryptography and Data Security (FC'05) is the premier
international forum for research, advanced development,
education, exploration, and debate regarding security in the
context of finance and commerce. We have augmented our conference
title and expanded our scope to cover all aspects of securing
transactions and systems. These aspects include a range of
technical areas such as: cryptography, payment systems, secure
transaction architectures, software systems and tools, user and
operator interfaces, fraud prevention, secure IT infrastructure,
and analysis methodologies. Our focus will also encompass legal,
financial, business and policy aspects. Material both on
theoretical (fundamental) aspects of securing systems and on
secure applications and real-world deployments will be
considered.

The conference goal is to bring together top cryptographers,
data-security specialists, and scientists with economists,
bankers, implementers, and policy makers. Intimate and colorful
by tradition, the FC'05 program will feature invited talks,
academic presentations, technical demonstrations, and panel
discussions. This conference is organized annually by the
International Financial Cryptography Association (IFCA).

Original papers and presentations on all aspects of financial and
commerce security are invited. Submissions must have a visible
bearing on financial and commerce security issues, but can be
interdisciplinary in nature and need not be exclusively concerned
with cryptography or security. Possible topics for submission to
the various sessions include, but are not limited to:

* Anonymity and Privacy
* Auctions
* Audit and Auditability
* Authentication and Identification, including Biometrics
* Certification and Authorization
* Commercial Cryptographic Applications
* Commercial Transactions and Contracts
* Digital Cash and Payment Systems
* Digital Incentive and Loyalty Systems
* Digital Rights Management
* Financial Regulation and Reporting
* Fraud Detection
* Game Theoretic Approaches to Security
* Infrastructure Design
* Legal and Regulatory Issues
* Microfinance and Micropayments
* Monitoring, Management and Operations
* Reputation Systems
* RFID-Based and Contactless Payment Systems
* Risk Assessment and Management
* Secure Banking
* Secure Financial Web Services
* Securing Emerging Computational Paradigms
* Security and Risk Perceptions and Judgments
* Security Economics
* Smart Cards and Secure Tokens
* Trust Management
* Trustability and Trustworthiness
* Underground-Market Economics
* Usability and Acceptance of Security Systems
* User and Operator Interfaces


                      Submission Instructions

Submission Categories
FC'05 is inviting submissions in three categories: (1) research
papers, (2) systems and applications presentations, (3) panel
sessions. For all accepted submissions, at least one author must
attend the conference and present the work.

Research Papers
Research papers should describe novel scientific contributions to
the field, and they will be subject to vigorous peer review.
Papers can be a maximum of 15 pages in length (including
references and appendices), and accepted submissions will be
published in full in the conference proceedings.

Systems and Application Presentations
Submissions in this category should describe novel or successful
systems with an emphasis on secure digital commerce applications.
Presentations may concern commercial systems, academic
prototypes, or open-source projects for any of the topics listed
above. Where appropriate, software or hardware demonstrations are
encouraged as part of the presentations in these sessions.
Submissions in this category should consist of a short summary of
the work (1-6 pages in length) to be reviewed by the Program
Committee, along with a short biography of the presenters.
Accepted submissions will be presented at the conference (25
minutes per presentation), and a one-page abstract will be
published in the conference proceedings.

Panel Sessions
Proposals for panel sessions are also solicited, and should
include a brief description of the panel as well as prospective
participants. Accepted panel sessions will be presented at the
conference, and each participant will contribute a one-page
abstract to be published in the conference proceedings.

Program Committee:
    Colin Boyd              Queensland University of Technology
    Liqun Chen              HP Labs
    Lynne Coventry          NCR
    Yvo Desmedt             University College London
    Giovanni Di Crescenzo   Telcordia Technologies
    Roger Dingledine        Moria Research Labs
    Scott Flinn             National Research Council of Canada
    Juan Garay              Bell Labs, Lucent Technologies
    Dan Geer                Geer Risk Services
    Craig Gentry            DoCoMo Labs USA
    Mike Just               Treasury Board of Canada
    Aggelos Kiayias         U Connecticut
    Helger Lipmaa           Helsinki U Technology
    David M'Raihi           Verisign
    Kobbi Nissim            Microsoft
    Satoshi Obana           Columbia U and NEC
    Andrew Odlyzko          U Minnesota
    Pascal Paillier         Gemplus
    David Pointcheval       Ecole Normale Sup?rieure
    Bart Preneel            Katholieke Universiteit Leuven
    Angela Sasse            University College London
    Berry Schoenmakers      Technische Universiteit Eindhoven
    Sean Smith              Dartmouth College
    Jessica Staddon         Palo Alto Research Center (PARC)
    Michael Szydlo          RSA Laboratories
    Jacques Traore          France Telecom
    Gene Tsudik             U California, Irvine
    Alma Whitten            Google
    Adam Young              Cigital
    Bill Yurcik             NCSA

- -- 
Andrew Patrick, Ph.D.
Senior Scientist
Information Security Group, Institute for Information Technology
National Research Council (NRC), Ottawa, Canada
E-mail: Andrew.Patrick at nrc-cnrc.gc.ca
WWW - NRC:  http://iit-iti.nrc-cnrc.gc.ca
WWW - Personal: http://www.andrewpatrick.ca
Phone: (613) 991-3374   Fax: (613) 952-7151  Cell/SMS: (613) 277-9211
_______________________________________________
fc-announce mailing list
fc-announce at ifca.ai
http://mail.ifca.ai/mailman/listinfo/fc-announce
----------

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Fri Sep 10 08:23:06 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Fri, 10 Sep 2004 08:23:06 -0400
Subject: Perplexing proof
Message-ID: <p0611045fbd674a95097e@[66.149.49.5]>

<http://www.vnunet.com/print/1157970>



 Perplexing proof

E-commerce is only one mathematical breakthrough away from disaster
Robert Valpuesta, IT Week 09 Sep 2004

The fact that even experts often do not fully understand how IT systems
work was underlined by recent reports that the Riemann hypothesis,
established in 1859, may finally have been proved.

It seems the hypothesis would explain the apparently random pattern of
prime numbers that form the basis for much internet cryptography, used for
e-commerce and online banking to guard accounts and credit card details.

Louis de Branges, a renowned mathematician at Purdue University in the US,
has claimed he can prove the hypothesis. But the maths is so complicated
that no one has yet been able to say whether his solution is right.

"[The suggested proof] is rather incomprehensible," professor Marcus du
Sautoy of Oxford University told The Guardian, adding that if correct it
could lead to the creation of a "prime spectrometer" that would bring "the
whole of e-commerce to its knees overnight".

Unfortunately, most managers have no way of telling whether the proof is
right or its implications are indeed as stated. This could be an
embarrassment if they are asked to assess risks for corporate governance
reports, since they clearly now have a duty to own up and admit that
business could be threatened by a theoretical prime spectrometer.

Alternatively they might accept that security is a matter of faith, declare
that nothing can truly be "known", and add that the way of Zen shows that
security is probably an illusion anyway.

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From zooko at zooko.com  Fri Sep 10 11:55:04 2004
From: zooko at zooko.com (Zooko O'Whielcronx)
Date: 10 Sep 2004 12:55:04 -0300
Subject: potential new IETF WG on anonymous IPSec
In-Reply-To: <20040909195729.4798957E2B@finney.org>
References: <20040909195729.4798957E2B@finney.org>
Message-ID: <C7C59F09-0341-11D9-BE07-000A95E2A184@zooko.com>

On 2004, Sep 09, , at 16:57, Hal Finney wrote:

> To clarify, this is not really "anonymous" in the usual sense.  Rather 
> it
> is a proposal to an extension to IPsec to allow for unauthenticated
> connections.  Presently IPsec relies on either pre-shared secrets or a
> trusted third party CA to authenticate the connection.  The new 
> proposal
> would let connections go forward using a straight Diffie-Hellman type
> exchange without authentication.
...
> I don't think "anonymous" is the right word for this, and I hope the
> IETF comes up with a better one as they go forward.

I believe that in the context of e-mail [1, 2, 3, 4] and FreeSWAN this 
is called "opportunistic encryption".

Regards,

Zooko

[1] http://www.templetons.com/brad/crypt.html
[2] http://bitconjurer.org/envelope.html
[3] http://pps.sourceforge.net/
[4] http://www.advogato.org/article/391.html

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From Victor.Duchovni at MorganStanley.com  Fri Sep 10 11:40:08 2004
From: Victor.Duchovni at MorganStanley.com (Victor Duchovni)
Date: Fri, 10 Sep 2004 11:40:08 -0400
Subject: Perplexing proof
In-Reply-To: <p0611045fbd674a95097e@[66.149.49.5]>
References: <p0611045fbd674a95097e@[66.149.49.5]>
Message-ID: <20040910154007.GO9840@piias899.ms.com>

On Fri, Sep 10, 2004 at 08:23:06AM -0400, R. A. Hettinga wrote:

> "[The suggested proof] is rather incomprehensible," professor Marcus du
> Sautoy of Oxford University told The Guardian, adding that if correct it
> could lead to the creation of a "prime spectrometer" that would bring "the
> whole of e-commerce to its knees overnight".

http://www.maths.ox.ac.uk/~dusautoy/flash/1hard/listpub.htm

So at least now we have a named source, even one who works on generalized
zeta functions. The out of the blue "prime spectrometer" claim is still
rather puzzling... Does anyone know why Du Sautoy is making this claim
(if it is indeed reported correctly).

-- 

 /"\ ASCII RIBBON                  NOTICE: If received in error,
 \ / CAMPAIGN     Victor Duchovni  please destroy and notify
  X AGAINST       IT Security,     sender. Sender does not waive
 / \ HTML MAIL    Morgan Stanley   confidentiality or privilege,
                                   and use is prohibited.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From eugen at leitl.org  Fri Sep 10 12:20:28 2004
From: eugen at leitl.org (Eugen Leitl)
Date: Fri, 10 Sep 2004 18:20:28 +0200
Subject: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org) (fwd from touch@ISI.EDU)
Message-ID: <20040910162028.GO1457@leitl.org>

From: Joe Touch <touch at ISI.EDU>
Subject: Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd frTo: "Discussions of anonymous Internet security." <anonsec at postel.org>
Date: Fri, 10 Sep 2004 09:03:50 -0700
Reply-To: "Discussions of anonymous Internet security." <anonsec at postel.org>

Clarifications below...

Eugen Leitl wrote:

>----- Forwarded message from "\"Hal Finney\"" <hal at finney.org> -----
>
>From: hal at finney.org ("Hal Finney")
>Date: Thu,  9 Sep 2004 12:57:29 -0700 (PDT)
>To: cryptography at metzdowd.com, cypherpunks at al-qaeda.net,
>	rah at shipwright.com
>Subject: Re: potential new IETF WG on anonymous IPSec
>
>
>>The IETF has been discussing setting up a working group
>>for anonymous IPSec.  They will have a BOF at the next IETF
>>in DC in November.  They're also setting up a mailing list you
>>might be interested in if you haven't heard about it already.
>>...
>>	http://www.postel.org/anonsec
>
>
>To clarify, this is not really "anonymous" in the usual sense. 

It does not authenticate the endpoint's identification, other than "same 
place I had been talking to."

There's no difference between having no "name" and having a name you 
cannot trust. I.e., I could travel under the name "anonymous" or "", or 
under the name "A. Smith". If you don't know whether I am actually A. 
Smith, the latter is identical to the former.

>Rather it
>is a proposal to an extension to IPsec to allow for unauthenticated
>connections.

Correction: it is a proposal to extend Internet security - including 
Ipsec, but also including TCP-MD5 (sometimes called "BGP MD5") and other 
security mechanisms at various layers. It is not focused only on IPsec.

>Presently IPsec relies on either pre-shared secrets or a
>trusted third party CA to authenticate the connection.  The new proposal
>would let connections go forward using a straight Diffie-Hellman type
>exchange without authentication.

This is one option, but not the only one.

>It also proposes less authentication
>of IP message packets, covering smaller subsets, as an option.

There are two aspects:
	- smaller portion of the packet is hashed
	- none of the packet is hashed, but a cookie is used

>The point has nothing to do with anonymity;

The last one, agreed. But the primary assumption is that we can avoid a 
lot of infrastructure and impediment to deployment by treating an 
ongoing conversation as a reason to trust an endpoint, rather than a 
third-party identification. Although anonymous access is not the primary 
goal, it is a feature of the solution.

>rather it is an attempt
>to secure against weaknesses in TCP which have begun to be exploited.

Please review the draft; there are a number of reasons this is being 
considered, not the least of which is to reduce the cumbersome 
requirement of key infrastructure as well as to avoid performance penalties.

>Sequence number guessing attacks are more successful today because of
>increasing bandwidth, and there have been several instances where they
>have caused disruption on the net.  While workarounds are in place, a
>better solution is desirable.

Please be more specific; how would it be better?

>This new effort is Joe Touch's proposal to weaken IPsec so that it uses
>less resources and is easier to deploy.  He calls the weaker version
>AnonSec.  But it is not anonymous, all the parties know the addresses
>of their counterparts.

Address != identity. Agreed, if what you want to do is hide traffic, 
this does not provide traffic confidentiality. But it does not tell you 
whether the packets come from 128.9.x.x (ISI, e.g.) or from someone 
spoofing 128.9.x.x; all you know is that whoever is using that address 
is capable of having an ongoing conversation (TCP connection, e.g.) with 
you.

I.e., there are two ways to be anonymous, as noted earlier:
	1) don't give out your name (A. Smith, e.g.)
	2) give out a name, but it doesn't necessarily mean anything
	(e.g., Mickey Mouse)

Even if you use "real" names in (2), there's no difference with (1), 
since you don't know whether the real Mickey Mouse is using it.

>Rather, it allows for a degree of security on
>connections between communicators who don't share any secrets or CAs.
>I don't think "anonymous" is the right word for this, and I hope the
>IETF comes up with a better one as they go forward.
>
>Hal Finney
>
>---------------------------------------------------------------------
>The Cryptography Mailing List
>Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
>
>----- End forwarded message -----
>
>
>------------------------------------------------------------------------
>
>_______________________________________________



_______________________________________________


----------

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20040910/b10a1240/attachment.pgp>

From bill.stewart at pobox.com  Sat Sep 11 01:54:09 2004
From: bill.stewart at pobox.com (Bill Stewart)
Date: Fri, 10 Sep 2004 22:54:09 -0700
Subject: potential new IETF WG on anonymous IPSec
In-Reply-To: <20040909195729.4798957E2B@finney.org>
References: <20040909195729.4798957E2B@finney.org>
Message-ID: <6.0.3.0.0.20040910223501.0403c120@pop.idiom.com>

At 12:57 PM 9/9/2004, Hal Finney wrote:
> >       http://www.postel.org/anonsec
>
>To clarify, this is not really "anonymous" in the usual sense.  Rather it
>is a proposal to an extension to IPsec to allow for unauthenticated
>connections.  Presently IPsec relies on either pre-shared secrets or a
>trusted third party CA to authenticate the connection.  The new proposal
>would let connections go forward using a straight Diffie-Hellman type
>exchange without authentication.  It also proposes less authentication
>of IP message packets, covering smaller subsets, as an option.

I read the draft, and I don't see how it offers any improvement
over draft-ietf-ipsec-internet-key-00.txt or Gilmore's proposal touse "open 
secret" as a not-very-secret pre-shared secret
that anybody who wants to can accept.
It does introduce some lower-horsepower alternatives for
authenticating less than the entire packet, and suggests
using AH which I thought was getting rather deprecated these days,
but another way to reduce horsepower needs is to use AES instead of 3DES.

Also, the author's document discusses protecting BGP to prevent
some of the recent denial-of-service attacks,
and asks for confirmation about the assertion in a message
on the IPSEC mailing list suggesting
    "E.g., it is not feasible for BGP routers to be configured with the
    appropriate certificate authorities of hundreds of thousands of peers".
Routers typically use BGP to peer with a small number of partners,
though some big ISP gateway routers might peer with a few hundred.
(A typical enterprise router would have 2-3 peers if it does BGP.)
If a router wants to learn full internet routes from its peers,
it might learn 1-200,000, but that's not the number of direct connections
that it has - it's information it learns using those connections.
And the peers don't have to be configured "rapidly without external 
assistance" -
you typically set up the peering link when you're setting up the
connection between an ISP and a customer or a pair of ISPs,
and if you want to use a CA mechanism to certify X.509 certs,
you can set up that information at the same time.



----
Bill Stewart  bill.stewart at pobox.com 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From pgut001 at cs.auckland.ac.nz  Sat Sep 11 13:43:44 2004
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Sun, 12 Sep 2004 05:43:44 +1200
Subject: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org) (fwd from touch@ISI.EDU)
In-Reply-To: <20040910162028.GO1457@leitl.org>
Message-ID: <E1C6Bua-0006NT-00@medusa01>

Eugen Leitl <eugen at leitl.org> writes:

>It does not authenticate the endpoint's identification, other than "same place
>I had been talking to."

So in other words it's the same baby-duck security model that's been quite
successfully used by SSH for about a decade, is also used in some SSL
implementations that don't just blindly trust anything with a certificate
(particularly popular with STARTTLS-enabled MTAs/MUAs where you don't want to
bother with CA-issued certs), and is even used in various X.509 applications
(via "certificate fingerprints"), although the X.509 folks don't like to admit
that because it implies that a known-good cert fingerprint is more reliable
than a CA :-).

Maybe it's worth doing some sort of generic RFC for this security model to
avoid scattering the same thing over a pile of IETF WGs, things like the
general operational principles (store a hash of the server key, compare it on
subsequent connects), how to present the value to the user (a format that's
consistent across protocols would be nice), maybe a simple /etc/passwd-type
file format listing servers and their matching hashes, etc etc etc.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From adam at cypherspace.org  Sat Sep 11 13:49:23 2004
From: adam at cypherspace.org (Adam Back)
Date: Sat, 11 Sep 2004 13:49:23 -0400
Subject: anonymous IP terminology (Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org))
In-Reply-To: <20040910162028.GO1457@leitl.org>
References: <20040910162028.GO1457@leitl.org>
Message-ID: <20040911174923.GA30946@bitchcake.off.net>

Joe Touch <touch at ISI.EDU> wrote:
> >The point has nothing to do with anonymity;
> 
> The last one, agreed. But the primary assumption is that we can avoid a 
> lot of infrastructure and impediment to deployment by treating an 
> ongoing conversation as a reason to trust an endpoint, rather than a 
> third-party identification. Although anonymous access is not the primary 
> goal, it is a feature of the solution.

Joe:

I respectfully request that you call this something other than
"anonymous".  It is quite confusing and misleading.  

Some people have spent quite a bit of time and effort in fact working
on anonymous IP and anonymous/pseudonymous transports.

For example at ZKS we worked on an anonymous/pseudonymous IP product
(which means cryptographically hiding the souce IP address from the
end-site).

There are some new open source anonymous IP projects.


Your proposal, which may indeed have some merit in simplifying key
management, has _nothing_ to do with anonymous IP.  Your overloading
of the established term will dilute the correct meaning.

Zooko provided the correct term and provided references:
"opportunistic encryption".  It sounds to have similar objectives to
what John had called opportunistic encryption and tried to do with
freeSWAN.  Lowever level terms may be unauthenticated as Hal
suggested.  Or non-certified key management (as the SSH cacheing of
previously before seen IP <-> key bindings and warnings when they
change).

> Although anonymous access is not the primary goal, it is a feature
> of the solution.

The access is _not_ anonymous.  The originator's IP, ISP call traces,
phone access records will be all over it and associated audit logs.

The distinguishing feature of anonymous is that not only is your name
not associated with the connection but there is no PII (personally
identifiable information) associated with it or obtainable from logs
kept.

And to be clear also anonymous means unlinkable anonymous across
multiple connections (which SSH type of authentication would not be)
and linkable anonymous means some observable linkage exists between
sessions which come from the same source (though no PII), and
pseudonymous means same as linkable anonymous plus association to a
persistent pseudonym.

Again there are actually cryptographic protcols for_ having anonymous
authentication: ZKPs, multi-show unlinkable credentials, and
refreshable (and so unlinkable) single-show credentials.

Adam

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From sandy at storm.ca  Sat Sep 11 16:20:29 2004
From: sandy at storm.ca (Sandy Harris)
Date: Sat, 11 Sep 2004 13:20:29 -0700
Subject: potential new IETF WG on anonymous IPSec
In-Reply-To: <C7C59F09-0341-11D9-BE07-000A95E2A184@zooko.com>
References: <20040909195729.4798957E2B@finney.org> <C7C59F09-0341-11D9-BE07-000A95E2A184@zooko.com>
Message-ID: <41435E0D.2070204@storm.ca>

Zooko O'Whielcronx wrote:

> On 2004, Sep 09, , at 16:57, Hal Finney wrote:
> 
>> ... an extension to IPsec to allow for unauthenticated
>> connections.  Presently IPsec relies on either pre-shared secrets or a
>> trusted third party CA to authenticate the connection.

No. It can also use RSA public keys without embedding them in
certificates or requiring a CA, let alone a 3rd party one.

>>  The new proposal
>> would let connections go forward using a straight Diffie-Hellman type
>> exchange without authentication.
> 
> ....
> 
>> I don't think "anonymous" is the right word for this, and I hope the
>> IETF comes up with a better one as they go forward.
> 
Sounds right to me, though "unauthenticeted" might be
more precise.

> I believe that in the context of e-mail [1, 2, 3, 4] and FreeSWAN this 
> is called "opportunistic encryption".

That is certainly not what FreeS/WAN meant by "opportunistic encryption".
http://www.freeswan.org/freeswan_trees/freeswan-1.99/doc/glossary.html#carpediem

OE does authenticate all connections. The trick is that the public keys
are stored in DNS so you do not have to exchange keys with the admin of
a site before you can do secure communications to it.

For this to be secure, you need DNSsec widely deployed. In effect you
are using DNS as a PKI. Without DNSsec, this reduces to something
fairly anonymous -- anyone who can lie in DNS can pretend to be
anyone they choose. However, that was never the design intent of
OE. If you want anonymous connections, there are easier ways.



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From adam at cypherspace.org  Sat Sep 11 15:09:54 2004
From: adam at cypherspace.org (Adam Back)
Date: Sat, 11 Sep 2004 15:09:54 -0400
Subject: anonymous IP terminology (Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org))
In-Reply-To: <41434608.7090902@isi.edu>
References: <20040910162028.GO1457@leitl.org> <20040911174923.GA30946@bitchcake.off.net> <41434608.7090902@isi.edu>
Message-ID: <20040911190954.GA12627@bitchcake.off.net>

On Sat, Sep 11, 2004 at 11:38:00AM -0700, Joe Touch wrote:
> >>Although anonymous access is not the primary goal, it is a feature
> >>of the solution.
> >
> >The access is _not_ anonymous.  The originator's IP, ISP call traces,
> >phone access records will be all over it and associated audit logs.
> 
> And you cannot determine whether that IP address came from the authentic 
> owner of that address or is spoofed. I'll try to be more careful - 
> you're right, in that it's not anonymous access. It IS anonymous 
> security, though.

I think you are confusing a weak potential for a technical ambiguity
of identity under attack conditions with anonymity.  (The technical
ambiguity would likely disappear in most practical settings).

Anonymity implies positives steps to avoid linking with PII.  With
anonymity you want not just technical ambiguity, but genuinely
pluasible deniability from an anonymity set -- preferably a large set
of users who could equally plausibly have established a given
connection, participated in an authentication protocol etc.

We don't after all call TCP anonymous, and your system is cleary
_less_ "anonymous" than TCP as there are security mechanisms involved
with various keys and authentication protocols which will only reduce
ambiguity.

> >The distinguishing feature of anonymous is that not only is your name
> >not associated with the connection but there is no PII (personally
> >identifiable information) associated with it or obtainable from logs
> >kept.
> 
> If I know the IP address you used, I still know NOTHING, FWIW. This is 
> no more distinguishable than the port number is in identifying something 
> behind a NAT.

Practically, knowing the IP address conveys a lot.  Many ISPs have
logs, some associated with DSL subscriber and phone records, for
billing, bandwidth caps, abuse complaints, spam cleanup etc etc.

The IP may be used for many different logged activities and some of
those activites may involve directly identified authentication.
People go to lengths to hide their IP precisely because it does
typically convey all too much.

> >And to be clear also anonymous means unlinkable anonymous across
> >multiple connections (which SSH type of authentication would not be)
> 
> That might be more specifically "per-connection anonymous", but the term 
> 'anonymous' is too general for that usage. However, there's still 
> nothing associated across connections in ANONSEC, IMO.

> You cannot know whether two connections from 10.0.0.1 on two different 
> ports with two different cookies are from the same endpoint. The point 
> of ANONSEC is that you don't care.

If one wants this to be true in practice it has to propogate up the
stack.  (Not the problem of ANONSEC, a problem for the higher level
app).

But even at the authentication protocol level one has to be quite
careful.  There are many gotchas if you really do want it to be
unlinkable.  (eg. pseudo random sequences occur in many settings at
different protocol levels which are in fact quite linkable).  I'll
give you one high level example.  At ZKS we had software to remail
MIME mail to provide a pseudonymous email.  But one gotcha is that
mail clients include MIME boundary lines which are pseudo-random
(purely to avoid string collision).  If these random lines are
generated with a non-cryptographic RNG it is quite likely that so
called unlinkable mail would in fact be linkable because of this
higher level protocol.  (We cared about unlinkability even tho' I said
pseudonymous because the user had multiple pseudonyms which were
supposed to be unlinkable across).

I would say if your interest in fixing such pseudo random sequeneces
is not present you should not be calling this anonymous.

But if it is part of your threat model, then you may in fact be using
anonymous authentication and that would be interesting to me at least
to participate.

Adam

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From bear at sonic.net  Sat Sep 11 17:53:59 2004
From: bear at sonic.net (bear)
Date: Sat, 11 Sep 2004 14:53:59 -0700 (PDT)
Subject: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from
 hal@finney.org) (fwd from touch@ISI.EDU)
In-Reply-To: <20040910162028.GO1457@leitl.org>
References: <20040910162028.GO1457@leitl.org>
Message-ID: <Pine.LNX.4.58.0409111447250.31600@bolt.sonic.net>



On Fri, 10 Sep 2004, Eugen Leitl wrote:

>From: Joe Touch <touch at ISI.EDU>

>>To clarify, this is not really "anonymous" in the usual sense.
>
>It does not authenticate the endpoint's identification, other than "same
>place I had been talking to."
>

That's pseudonymity, not anonymity.


>There's no difference between having no "name" and having a name you
>cannot trust. I.e., I could travel under the name "anonymous" or "", or
>under the name "A. Smith". If you don't know whether I am actually A.
>Smith, the latter is identical to the former.

This is just plain not true.  When operating under a pseudonym,
you are making linkable acts - linkable to each other even if
not necessarily linkable to your own official identity.  Anonymous
actions or communications are those which cannot be linked to any
other no matter how hard someone tries.

We can expect the public to fail to grasp the distinction, but
on this list "anonymous" is a very strong claim.  Anonymity is
*HARD* to do, not something that results from failing to check
a credential.

				Bear

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From zooko at zooko.com  Sun Sep 12 05:18:25 2004
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: 12 Sep 2004 06:18:25 -0300
Subject: potential new IETF WG on anonymous IPSec
In-Reply-To: <41435E0D.2070204@storm.ca>
References: <20040909195729.4798957E2B@finney.org> <C7C59F09-0341-11D9-BE07-000A95E2A184@zooko.com> <41435E0D.2070204@storm.ca>
Message-ID: <B3728B70-049C-11D9-BE07-000A95E2A184@zooko.com>

On 2004, Sep 11, , at 17:20, Sandy Harris wrote:

> Zooko O'Whielcronx wrote:
>
>> I believe that in the context of e-mail [1, 2, 3, 4] and FreeSWAN  
>> this is called "opportunistic encryption".
>
> That is certainly not what FreeS/WAN meant by "opportunistic  
> encryption".
> http://www.freeswan.org/freeswan_trees/freeswan-1.99/doc/ 
> glossary.html#carpediem

That link leads to the following definition: "A situation in which any  
two IPsec-aware machines can secure their communications, without a  
pre-shared secret and without a common  PKI or previous exchange of  
public keys. This is one of the goals  of the Linux FreeS/WAN project,  
discussed in our introduction section. Setting up for opportunistic  
encryption is described in our  configuration document."

This definition is indeed consistent with the concept that we are  
discussing.

If FreeS/WAN's implementation boils down to using DNS as a common PKI  
that is too bad, but their definition (which explicitly excludes a  
common PKI) seems to be the same as mine.

This concept is too important to go without a name.  Currently the best  
way to tell your interlocutor what concept you are talking about seems  
to be "you know, the way SSH does it, with the  
first-time-unauthenticated public key exchange....".  I heartily  
approve of Peter Gutmann's suggestion to write an RFC for it.

Regards,

Zooko

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From smb at research.att.com  Sun Sep 12 09:25:15 2004
From: smb at research.att.com (Steven M. Bellovin)
Date: Sun, 12 Sep 2004 09:25:15 -0400
Subject: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org) (fwd from touch@ISI.EDU) 
In-Reply-To: Your message of "Sun, 12 Sep 2004 05:43:44 +1200."
             <E1C6Bua-0006NT-00@medusa01> 
Message-ID: <20040912132515.6C7251AE7E@berkshire.research.att.com>

In message <E1C6Bua-0006NT-00 at medusa01>, Peter Gutmann writes:
>Eugen Leitl <eugen at leitl.org> writes:
>

>
>Maybe it's worth doing some sort of generic RFC for this security model to
>avoid scattering the same thing over a pile of IETF WGs, things like the
>general operational principles (store a hash of the server key, compare it on
>subsequent connects), how to present the value to the user (a format that's
>consistent across protocols would be nice), maybe a simple /etc/passwd-type
>file format listing servers and their matching hashes, etc etc etc.
>

Sounds good.  Who wants to write it...?

		--Steve Bellovin, http://www.research.att.com/~smb


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Sun Sep 12 09:59:24 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Sun, 12 Sep 2004 09:59:24 -0400
Subject: On the Voting Machine Makers' Tab
Message-ID: <p06110416bd69f94bff57@[66.149.49.5]>

<http://www.nytimes.com/2004/09/12/opinion/12sun2.html?th=&pagewanted=print&position=>

The New York Times
September 12, 2004

On the Voting Machine Makers' Tab

As doubts have grown about the reliability of electronic voting, some of
its loudest defenders have been state and local election officials. Many of
those same officials have financial ties to voting machine companies. While
they may sincerely think that electronic voting machines are so trustworthy
that there is no need for a paper record of votes, their views have to be
regarded with suspicion until their conflicts are addressed.

Computer scientists, who understand the technology better than anyone else,
have been outspoken about the perils of electronic voting. Good government
groups, like Common Cause, are increasingly mobilizing grass-roots
opposition. And state governments in a growing number of states, including
California and Ohio, have pushed through much-needed laws that require
electronic voting machines to produce paper records.

 But these groups have faced intense opposition from election officials. At
a hearing this spring, officials from Georgia, California and Texas
dismissed concerns about electronic voting, and argued that
voter-verifiable paper trails, which voters can check to ensure their vote
was correctly recorded, are impractical. The Election Center, which does
election training and policy work, and whose board is dominated by state
and local election officials, says the real problem is people who "scare
voters and public officials with claims that the voting equipment and/or
its software can be manipulated to change the outcome of elections."

What election officials do not mention, however, are the close ties they
have to the voting machine industry. A disturbing number end up working for
voting machine companies. When Bill Jones left office as California's
secretary of state in 2003, he quickly became a consultant to Sequoia
Voting Systems. His assistant secretary of state took a full-time job
there. Former secretaries of state from Florida and Georgia have signed on
as lobbyists for Election Systems and Software and Diebold Election
Systems. The list goes on.

Even while in office, many election officials are happy to accept voting
machine companies' largess. The Election Center takes money from Diebold
and other machine companies, though it will not say how much. At the
center's national conference last month, the companies underwrote meals and
a dinner cruise.

 Forty-three percent of the budget of the National Association of
Secretaries of State comes from voting machine companies and other vendors,
and at its conference this summer in New Orleans, Accenture, which compiles
voter registration databases for states, sponsored a dinner at the Old
State Capitol in Baton Rouge.

 There are also reports of election officials being directly offered gifts.
Last year, the Columbus Dispatch reported that a voting machine company was
offering concert tickets and limousine rides while competing for a contract
worth as much as $100 million, if not more.

When electronic voting was first rolled out, election officials and voting
machine companies generally acted with little or no public participation.
But now the public is quite rightly insisting on greater transparency and
more say in the decisions. If election officials want credibility in this
national discussion, they must do more to demonstrate that their only
loyalty is to the voter.

Making Votes Count: Editorials in this series remain online at
nytimes.com/makingvotescount.


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From hartmans at mit.edu  Sun Sep 12 14:45:12 2004
From: hartmans at mit.edu (Sam Hartman)
Date: Sun, 12 Sep 2004 14:45:12 -0400
Subject: potential new IETF WG on anonymous IPSec
In-Reply-To: <C7C59F09-0341-11D9-BE07-000A95E2A184@zooko.com> (Zooko
 O'Whielcronx's message of "10 Sep 2004 12:55:04 -0300")
References: <20040909195729.4798957E2B@finney.org>
	<C7C59F09-0341-11D9-BE07-000A95E2A184@zooko.com>
Message-ID: <tsloekbwclj.fsf@cz.mit.edu>

>>>>> "Zooko" == Zooko O'Whielcronx <zooko at zooko.com> writes:

    Zooko> On 2004, Sep 09, , at 16:57, Hal Finney wrote:
    >> To clarify, this is not really "anonymous" in the usual sense.
    >> Rather it is a proposal to an extension to IPsec to allow for
    >> unauthenticated connections.  Presently IPsec relies on either
    >> pre-shared secrets or a trusted third party CA to authenticate
    >> the connection.  The new proposal would let connections go
    >> forward using a straight Diffie-Hellman type exchange without
    >> authentication.
    Zooko> ...
    >> I don't think "anonymous" is the right word for this, and I
    >> hope the IETF comes up with a better one as they go forward.

    Zooko> I believe that in the context of e-mail [1, 2, 3, 4] and
    Zooko> FreeSWAN this is called "opportunistic encryption".
No.  opportunistic encryption means I have retrieved a key or cert for
the other party, but do not know whether it is actually the right
cert.  This is slightly different although at the level of current
discussion it has the same security properties.

--Sam

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From orourked at eeng.dcu.ie  Mon Sep 13 06:53:53 2004
From: orourked at eeng.dcu.ie (Damien O'Rourke)
Date: Mon, 13 Sep 2004 11:53:53 +0100
Subject: Looking for Source of AES code
Message-ID: <00e601c4997f$f5f66b00$4325ce88@DamienORourke>

Hi,

I have some AES code here in C and I am trying to find it's author and
source.  I can't find
it on the Internet so I figure it was taken from a book.  Now I don't want
to send the entire
code to the list for obvious reasons however I was hoping you could help me
from the following
small snippet.  Maybe the use of " _fastcall " might jog someone's memory.
If there is
code that appears similar to this but is not exactly the same I would
appreciate the source
of that also.


void _fastcall encrypt(FILE *Encryption_File, FILE *Encrypted_File, unsigned
*expkey)
{
uchar in[16], out[16];
unsigned state[NumberOfBytes], rnd, i;

while (!feof(Encryption_File))
{
  uchar k=0;
   fread(in,sizeof(uchar),16,Encryption_File);/

   *(state+0)= *(in+0)<<24 | *(in+1)<< 16  | *(in+2)<<8  | *(in+3);
   *(state+1)= *(in+4)<<24 | *(in+5)<< 16  | *(in+6)<<8  | *(in+7)  ;
   *(state+2)= *(in+8)<<24 | *(in+9)<< 16  | *(in+10)<<8 | *(in+11)  ;
   *(state+3)= *(in+1)<<24 | *(in+3)<< 16  | *(in+14)<<8 | *(in+15)  ;

   AddRoundKey (state, expkey);

 for( rnd = 1; rnd < NumberOfRounds + 1; rnd++ )
 {
  ByteSub((uchar *)state);
  ShiftRows ((uchar *)state);
  if( rnd < NumberOfRounds )
        MixColumns ((uchar *)state);
  AddRoundKey (state, expkey + rnd * NumberOfBytes);
 }


Many Thanks,
Damien.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From ben at algroup.co.uk  Mon Sep 13 08:18:32 2004
From: ben at algroup.co.uk (Ben Laurie)
Date: Mon, 13 Sep 2004 13:18:32 +0100
Subject: will spammers early adopt hashcash? (Re: Spam Spotlight on Reputation)
In-Reply-To: <20040907205640.GD9530@lightship.internal.homeport.org>
References: <p06110416bd6252da2a82@[4.240.162.204]> <20040906221533.GA29063@danisch.de> <Pine.LNX.4.58.0409070731140.7800@bolt.sonic.net> <20040907201313.GA10870@bitchcake.off.net> <20040907205640.GD9530@lightship.internal.homeport.org>
Message-ID: <41459018.7040909@algroup.co.uk>

Adam Shostack wrote:

> On Tue, Sep 07, 2004 at 04:13:13PM -0400, Adam Back wrote:
> 
> | Well we'll see.  If they have lots of CPU from zombies and can get and
> | maintain more with limited effort maybe even they can, and CAMRAM's
> | higher cost stamp on introductions only will prevail as the preferred
> | method.
> 
> Adam,
> 
> 	You've thought about this more than me.  What do you see as
> equilibrium postal rates if the spammers have 10k, 100k, or a million
> nodes to send?
> 
>         Will spammers run under nice?  Use your graphics card as a
> co-processor?  Is the rate of new vulns high enough to keep their CPU
> pools filled?

We have some figures for that kind of stuff in 
http://www.apache-ssl.org/proofwork.pdf.

Cheers,

Ben.

-- 
ApacheCon! 13-17 November! http://www.apachecon.com/

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"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 majordomo at metzdowd.com


From pgut001 at cs.auckland.ac.nz  Mon Sep 13 13:09:13 2004
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Tue, 14 Sep 2004 05:09:13 +1200
Subject: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org) (fwd from touch@ISI.EDU)
In-Reply-To: <20040912132515.6C7251AE7E@berkshire.research.att.com>
Message-ID: <E1C6uKH-0008Ou-00@medusa01>

"Steven M. Bellovin" <smb at research.att.com> writes:

>>Maybe it's worth doing some sort of generic RFC for this security model to
>>avoid scattering the same thing over a pile of IETF WGs, 
>
>Sounds good.  Who wants to write it...?

Since there seems to be at least some interest in this, I'll make a start on
it.  If anyone else wants to add their $0.03 to it [0], let me know.

Peter.

[0] Or $0.04 if you're paying in Euros.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From adam at homeport.org  Mon Sep 13 10:37:47 2004
From: adam at homeport.org (Adam Shostack)
Date: Mon, 13 Sep 2004 10:37:47 -0400
Subject: will spammers early adopt hashcash? (Re: Spam Spotlight on Reputation)
In-Reply-To: <41459018.7040909@algroup.co.uk>
References: <p06110416bd6252da2a82@[4.240.162.204]> <20040906221533.GA29063@danisch.de> <Pine.LNX.4.58.0409070731140.7800@bolt.sonic.net> <20040907201313.GA10870@bitchcake.off.net> <20040907205640.GD9530@lightship.internal.homeport.org> <41459018.7040909@algroup.co.uk>
Message-ID: <20040913143747.GA37796@lightship.internal.homeport.org>

On Mon, Sep 13, 2004 at 01:18:32PM +0100, Ben Laurie wrote:
| Adam Shostack wrote:
| 
| >On Tue, Sep 07, 2004 at 04:13:13PM -0400, Adam Back wrote:
| >
| >| Well we'll see.  If they have lots of CPU from zombies and can get and
| >| maintain more with limited effort maybe even they can, and CAMRAM's
| >| higher cost stamp on introductions only will prevail as the preferred
| >| method.
| >
| >Adam,
| >
| >	You've thought about this more than me.  What do you see as
| >equilibrium postal rates if the spammers have 10k, 100k, or a million
| >nodes to send?
| >
| >        Will spammers run under nice?  Use your graphics card as a
| >co-processor?  Is the rate of new vulns high enough to keep their CPU
| >pools filled?
| 
| We have some figures for that kind of stuff in 
| http://www.apache-ssl.org/proofwork.pdf.

Thanks!  That was exactly what I was hoping wouldn't get said, because
I no longer believe that hashcash is substantially useful.

Adam S

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From hartmans at mit.edu  Mon Sep 13 14:41:21 2004
From: hartmans at mit.edu (Sam Hartman)
Date: Mon, 13 Sep 2004 14:41:21 -0400
Subject: potential new IETF WG on anonymous IPSec
In-Reply-To: <E1C6uzk-0005u6-00@alva.home> (Tim Shepard's message of "Mon,
 13 Sep 2004 13:52:04 -0400")
References: <E1C6uzk-0005u6-00@alva.home>
Message-ID: <tsl7jqyj9ke.fsf@cz.mit.edu>

>>>>> "Tim" == Tim Shepard <shep at alum.mit.edu> writes:

    Tim> Sam said:

    >> No.  opportunistic encryption means I have retrieved a key or
    >> cert for the other party, but do not know whether it is
    >> actually the right cert.

    Tim> If the key is retrieved from the other end of a TCP
    Tim> connection (like vanilla ssh works the first time), is that
    Tim> included within the definition of "opportunistic encryption"?

Yes.


Note that for at least one of the uses of anonymous ipsec you
specifically don't want this behavior because you specifically don't
want people to cache keys in an ssh known_hosts style.  For other uses
you would want this behavior.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From bill.stewart at pobox.com  Mon Sep 13 15:00:19 2004
From: bill.stewart at pobox.com (Bill Stewart)
Date: Mon, 13 Sep 2004 12:00:19 -0700
Subject: potential new IETF WG on anonymous IPSec
In-Reply-To: <tsloekbwclj.fsf@cz.mit.edu>
References: <20040909195729.4798957E2B@finney.org>
 <C7C59F09-0341-11D9-BE07-000A95E2A184@zooko.com>
 <tsloekbwclj.fsf@cz.mit.edu>
Message-ID: <6.0.3.0.0.20040913114815.04081388@pop.idiom.com>

At 11:45 AM 9/12/2004, Sam Hartman wrote:
>No.  opportunistic encryption means I have retrieved a key or cert for
>the other party, but do not know whether it is actually the right
>cert.  This is slightly different although at the level of current
>discussion it has the same security properties.

Actually, FreeSWAN's "Opportunistic Encryption" meant
"if you've got IP traffic for somebody,
see if they can do encryption with you and use it if you can."

Because Gilmore wanted to make sure encryption was always done securely,
their implementation used a common PKI - DNSSEC and inverse DNS -
which has the advantage that a security gateway can use it when
all it knows is the IP address of the destination (which is typically the 
case),
but the severe disadvantage that very few people have control
over that DNS space and also that an IP address may belong to more than one 
domain.

There's a significant policy question there - if you don't have
a common PKI of some sort, is it worthwhile encrypting anyway,
protecting against passive eavesdroppers but not MITM,
or is that a false sense of security because the people who
most need security are the people most likely to have a government
annoyed enough at them to do the work of running a MITM attack?
Encryption against passive eavesdroppers makes password-stealing
and traffic analysis harder, so it's probably worth the risk,
but that wasn't the choice that FreeSWAM made.




Bill Stewart  bill.stewart at pobox.com 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From lynn at garlic.com  Mon Sep 13 15:16:17 2004
From: lynn at garlic.com (Anne & Lynn Wheeler)
Date: Mon, 13 Sep 2004 13:16:17 -0600
Subject: [anonsec] Re: potential new IETF WG on anonymous IPSec
  (fwd from hal@finney.org) (fwd from touch@ISI.EDU)
In-Reply-To: <E1C6Bua-0006NT-00@medusa01>
References: <20040910162028.GO1457@leitl.org>
 <E1C6Bua-0006NT-00@medusa01>
Message-ID: <6.1.2.0.2.20040913130542.044c47a0@mail.comcast.net>

At 11:43 AM 9/11/2004, Peter Gutmann wrote:
>So in other words it's the same baby-duck security model that's been quite
>successfully used by SSH for about a decade, is also used in some SSL
>implementations that don't just blindly trust anything with a certificate
>(particularly popular with STARTTLS-enabled MTAs/MUAs where you don't want to
>bother with CA-issued certs), and is even used in various X.509 applications
>(via "certificate fingerprints"), although the X.509 folks don't like to admit
>that because it implies that a known-good cert fingerprint is more reliable
>than a CA :-).


i've referred to it as identity agnostic ... as opposed to anonymous ... 
even with public key use. the scenario is that the original identity 
x.509  certificates created huge privacy issues.

the the current credit card scenario, it carries a name ... in theory 
so  that the merchant or point-of-sale can cross-check the name against 
additional forms of identification .... as a means of authentication (where 
the merchant is sort of a stand-in agent for the consumer's financial 
institution .... even tho the merchant and the consumer's financial 
institution may have significantly different and possibly opposing 
interests). in effect it is transforming something that should be purely an 
authentication operation (is the entity entitled to perform a transaction 
for the account) into a much more difficult (and privacy invasive) 
identification operation.

the x9.59 scenario .... is that the transaction is simply authenticated 
with a digital signature that the merchant passes thru to the consumer's 
financial institution. the consumer financial institution verifies the 
digital signature with public key on file for that account.  the 
verification of the digital signature implies some form of "something you 
have" authentication (implies that you uniquely have the corresponding 
private key).

it becomes a straight-forward authentication operation and identity 
agnostic ... w/o the horrible identity and privacy invasive that can 
accompany a x.509 identity certificate.

while it may be possible for various agents to associated the 
authentication operation .... the operations themselves, at least don't 
carry the possibly mandatory identity information & privacy invasive 
information that can be found in identity x.509 certificates.

--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/ 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From adam at cypherspace.org  Mon Sep 13 16:43:57 2004
From: adam at cypherspace.org (Adam Back)
Date: Mon, 13 Sep 2004 16:43:57 -0400
Subject: will spammers early adopt hashcash? (Re: Spam Spotlight on Reputation)
In-Reply-To: <20040913143747.GA37796@lightship.internal.homeport.org>
References: <p06110416bd6252da2a82@[4.240.162.204]> <20040906221533.GA29063@danisch.de> <Pine.LNX.4.58.0409070731140.7800@bolt.sonic.net> <20040907201313.GA10870@bitchcake.off.net> <20040907205640.GD9530@lightship.internal.homeport.org> <41459018.7040909@algroup.co.uk> <20040913143747.GA37796@lightship.internal.homeport.org>
Message-ID: <20040913204357.GB30081@bitchcake.off.net>

Ben and Richard CLayton's paper makes several assumptions and we'll
see how those pan out in the field as time goes on.

We don't really know what the true cost of maintaining ownership of
many machines.  No doubt much lower than it should be because of poor
security on microsoft OSes.  But even so there must be some turn over
as the user instals AV, firewalls, gets cut off by ISP, gets IP
blacklisted etc.

The general argument is in the FAQ quoted below.

Essentially whatever resources spammers do have, hashcash is going to
slow them down because the balance of CPU power vs bandwidth is such
that 20-bit hashcahs with current hardware is likely to slow down the
output of a typical consumer destkop+DSL line down by afact or 10-100x
less spam.  (Depnds on CPU power, DSL uplink, and number of Bcc
recipients per message).  Hashcash costs equal cpu per Bcc recipient.
Without hashcash Bcc recipients to the same domain or to a hub cost a
tiny bit of bandwidth -- the size of the email address (+"RCPT TO
\r\n").

Will it be enough -- we don't know yet, but if widely deployed it
would make spammers adapt.  We just don't yet know how they will
adapt.

The other question Ben & Richards paper doesn't explore is the CAMRAM
way of using hashcash.  In this model you only pay hashcash for
_introductions_.  After parties have replied to a mail, the mail is
whitelisted (short term by address only (risky no auth, joe-job
hazard) medium term with CAMRAM email header signatures).  If simple
hashcash per mail turns out not to be enough, CAMRAM can increase the
work factor, as people do not reply to spammers; and many emails are
to-and-fro vs first introduction emails.  (So the sender can afford to
pay more on average).  Eric sent a spreadsheet with some of this type
of calculation.

There may also be some mileage in Hal Finney's RPOW
http://www.rpow.net where the legitimate user can re-use stamps he
receives.  (The scaling issues of the RPOW servers would need to be
engineered carefully, there are servers, they can be per eg domain ,
but still compared to hashash this is more infrastructure as hashcash
is pure end-to-end).

Adam

http://www.hashcash.org/faq/ 2c and 2d

| 2c But won't spammers steal CPU time?
| 
| Spammers already compromise security on many users machines to make
| so-called "Zombie" armies to send spam from. However currently the
| rate at which spammers can send mail on a zombie machine is limited
| purely by the speed of those machine's internet links. A typical DSL
| user might be able to send 25 unique messages per second each of size
| 1KB (assumes 256kbit uplink). Or many more messages per second if the
| messages are delivered to multiple users at once (using multiple Cc or
| Bcc recipients). Even a 20-bit stamp takes 1/2 second per recipient on
| the highest end pc hardware at time of writing. This would slow
| spammers down by a factor of 10-100 or more per compromised machine
| (depending on whether the messages sent are sent individually or to
| many users at once).
| 
| 2d But won't spammers deliver to many recipients at once?
| 
| Spammers commonly optimize the amount of spam they can send over a
| given link speed by delivering messages to 100s or 1000s of Bcc
| recipients at once directly to an end-site, or to an ISP mail-hub. In
| this way they can consume just 3.5KB of bandwidth in sending messages
| to 100 recipients compared to the 100KB which would be used to send
| each message separately. This would allow a spammer to send 700
| messages per second (assumes DSL with 256kbit uplink).
| 
| Delivering in batches reduces the degree of customization the spammer
| can make because all of the message bodies in a batch have to be the
| same, but never-the-less is a trick spammers commonly use to increase
| the number of mails per second they can send.
| 
| However with hashcash a separate stamp is required for each individual
| recipient, which stops this spammer trick. If the spammer has to put a
| hashcash stamp for each recipient, even a 3Ghz Pentium 4 can only
| generate 2 stamps per second, compared to 700 per second with no
| hashcash, so using hashcash in this scenario slows the number of mails
| the spammer can send by 350x.

Adam

On Mon, Sep 13, 2004 at 10:37:47AM -0400, Adam Shostack wrote:
> On Mon, Sep 13, 2004 at 01:18:32PM +0100, Ben Laurie wrote:
> | Adam Shostack wrote:
> | 
> | >On Tue, Sep 07, 2004 at 04:13:13PM -0400, Adam Back wrote:
> | >
> | >| Well we'll see.  If they have lots of CPU from zombies and can get and
> | >| maintain more with limited effort maybe even they can, and CAMRAM's
> | >| higher cost stamp on introductions only will prevail as the preferred
> | >| method.
> | >
> | >Adam,
> | >
> | >	You've thought about this more than me.  What do you see as
> | >equilibrium postal rates if the spammers have 10k, 100k, or a million
> | >nodes to send?
> | >
> | >        Will spammers run under nice?  Use your graphics card as a
> | >co-processor?  Is the rate of new vulns high enough to keep their CPU
> | >pools filled?
> | 
> | We have some figures for that kind of stuff in 
> | http://www.apache-ssl.org/proofwork.pdf.
> 
> Thanks!  That was exactly what I was hoping wouldn't get said, because
> I no longer believe that hashcash is substantially useful.
> 
> Adam S

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From brg at gladman.plus.com  Tue Sep 14 04:35:59 2004
From: brg at gladman.plus.com (Brian Gladman)
Date: Tue, 14 Sep 2004 09:35:59 +0100
Subject: Looking for Source of AES code
In-Reply-To: <00e601c4997f$f5f66b00$4325ce88@DamienORourke>
References: <00e601c4997f$f5f66b00$4325ce88@DamienORourke>
Message-ID: <4146AD6F.7000909@gladman.plus.com>

Damien O'Rourke wrote:

> Hi,
> 
> I have some AES code here in C and I am trying to find it's author and
> source.  I can't find
> it on the Internet so I figure it was taken from a book.  Now I don't want
> to send the entire
> code to the list for obvious reasons however I was hoping you could help me
> from the following
> small snippet.  Maybe the use of " _fastcall " might jog someone's memory.
> If there is
> code that appears similar to this but is not exactly the same I would
> appreciate the source
> of that also.
> 
> 
> void _fastcall encrypt(FILE *Encryption_File, FILE *Encrypted_File, unsigned
> *expkey)
> {
> uchar in[16], out[16];
> unsigned state[NumberOfBytes], rnd, i;
> 
> while (!feof(Encryption_File))
> {
>   uchar k=0;
>    fread(in,sizeof(uchar),16,Encryption_File);/
> 
>    *(state+0)= *(in+0)<<24 | *(in+1)<< 16  | *(in+2)<<8  | *(in+3);
>    *(state+1)= *(in+4)<<24 | *(in+5)<< 16  | *(in+6)<<8  | *(in+7)  ;
>    *(state+2)= *(in+8)<<24 | *(in+9)<< 16  | *(in+10)<<8 | *(in+11)  ;
>    *(state+3)= *(in+1)<<24 | *(in+3)<< 16  | *(in+14)<<8 | *(in+15)  ;

I don't know whose code it is but it has bugs in it.

The line above should be:

  *(state+3)= *(in+12)<<24 | *(in+13)<< 16  | *(in+14)<<8 | *(in+15);

I doubt that this is the only problem in this code either.

[snip]

     Brian Gladman


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From eugen at leitl.org  Tue Sep 14 04:31:11 2004
From: eugen at leitl.org (Eugen Leitl)
Date: Tue, 14 Sep 2004 10:31:11 +0200
Subject: pci hardware for secure crypto storage (OpenSSL/OpenBSD)
Message-ID: <20040914083111.GX1457@leitl.org>


I'm looking for (cheap, PCI/USB) hardware to store secrets (private key) and
support crypto primitives (signing, cert generation). It doesn't have to be
fast, but to support loading/copying of secrets in physically secure environments, and
not generate nonextractable secret onboard. Environment is
OpenBSD/Linux/OpenSSL/gpg.

Any suggestions?

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20040914/be486892/attachment.pgp>

From hadmut at danisch.de  Tue Sep 14 05:55:41 2004
From: hadmut at danisch.de (Hadmut Danisch)
Date: Tue, 14 Sep 2004 11:55:41 +0200
Subject: potential new IETF WG on anonymous IPSec
In-Reply-To: <tsl7jqyj9ke.fsf@cz.mit.edu>
References: <E1C6uzk-0005u6-00@alva.home> <tsl7jqyj9ke.fsf@cz.mit.edu>
Message-ID: <20040914095541.GA30922@danisch.de>

On Mon, Sep 13, 2004 at 02:41:21PM -0400, Sam Hartman wrote:
> 
>     >> No.  opportunistic encryption means I have retrieved a key or
>     >> cert for the other party, but do not know whether it is
>     >> actually the right cert.
> 
>     Tim> If the key is retrieved from the other end of a TCP
>     Tim> connection (like vanilla ssh works the first time), is that
>     Tim> included within the definition of "opportunistic encryption"?
> 
> Yes.



Be careful. I believe that this is not as simple. It depends on 
what you use the key for.

If it is used for encryption, then something like "opportunistic
encryption" exists. After all, using an unverified key for encryption
is not yet worse than using no encryption. So even if the key might 
be the attacker's one, nothing is lost compared to plain
communication. 

But avoiding faked TCP resets is also a matter of authenticity. 

Does 'opportunistic authentication' exist?



regards
Hadmut

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From kelsey.j at ix.netcom.com  Tue Sep 14 09:32:59 2004
From: kelsey.j at ix.netcom.com (John Kelsey)
Date: Tue, 14 Sep 2004 09:32:59 -0400 (GMT-04:00)
Subject: will spammers early adopt hashcash? (Re: Spam Spotlight on
 Reputation)
Message-ID: <10102562.1095168781026.JavaMail.root@gonzo.psp.pas.earthlink.net>

>From: Adam Back <adam at cypherspace.org>
>Sent: Sep 13, 2004 4:43 PM
>To: Adam Shostack <adam at homeport.org>
>Cc: Ben Laurie <ben at algroup.co.uk>, bear <bear at sonic.net>, 
>	Hadmut Danisch <hadmut at danisch.de>, 
>	"R. A. Hettinga" <rah at shipwright.com>, cryptography at metzdowd.com, 
>	Eric Johansson <esj at harvee.org>, Adam Back <adam at cypherspace.org>
>Subject: Re: will spammers early adopt hashcash? (Re: Spam Spotlight on Reputation)

...
>Essentially whatever resources spammers do have, hashcash is going to
>slow them down because the balance of CPU power vs bandwidth is such
>that 20-bit hashcahs with current hardware is likely to slow down the
>output of a typical consumer destkop+DSL line down by afact or 10-100x
>less spam.  

It sure seems like one other impact of this is going to be that zombie machines can't do much spamming in the background, while letting the user of the machine think he still is in control of it.  I don't know whether they do that now, though.  

--John

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From nelson at crynwr.com  Tue Sep 14 12:26:12 2004
From: nelson at crynwr.com (Russell Nelson)
Date: Tue, 14 Sep 2004 12:26:12 -0400
Subject: will spammers early adopt hashcash? (Re: Spam Spotlight on Reputation)
In-Reply-To: <20040913204357.GB30081@bitchcake.off.net>
References: <p06110416bd6252da2a82@[4.240.162.204]>
	<20040906221533.GA29063@danisch.de>
	<Pine.LNX.4.58.0409070731140.7800@bolt.sonic.net>
	<20040907201313.GA10870@bitchcake.off.net>
	<20040907205640.GD9530@lightship.internal.homeport.org>
	<41459018.7040909@algroup.co.uk>
	<20040913143747.GA37796@lightship.internal.homeport.org>
	<20040913204357.GB30081@bitchcake.off.net>
Message-ID: <16711.7076.157416.902019@desk.crynwr.com>

(everybody is on the mailing list; why all the CC's?)

Adam Back writes:
 > Will it be enough -- we don't know yet, but if widely deployed it
 > would make spammers adapt.  We just don't yet know how they will
 > adapt.

Cryptography is not about math; it's not about secrets; it's not about
security.  It's about economics.  I'd really like to see people NOT
talk about the security of cryptography, but instead of about the cost
of it.  If the cost of breaking a system exceeds the value of an
identifiable message, nobody will bother breaking it.  If the cost of
using a system exceeds the value of the system, nobody will bother
using it.

So, in this context, Ben & Richards paper is not so much that
"hashcash won't work" but instead "the value of using hashcash is
exceeded by the cost of using it."

-- 
--My blog is at angry-economist.russnelson.com  | Violence never solves
Crynwr sells support for free software  | PGPok | problems, it just changes
521 Pleasant Valley Rd. | +1 212-202-2318 voice | them into more subtle
Potsdam, NY 13676-3213  | FWD# 404529 via VOIP  | problems.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From dshaw at jabberwocky.com  Tue Sep 14 18:25:15 2004
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue, 14 Sep 2004 18:25:15 -0400
Subject: pci hardware for secure crypto storage (OpenSSL/OpenBSD)
In-Reply-To: <20040914083111.GX1457@leitl.org>
References: <20040914083111.GX1457@leitl.org>
Message-ID: <20040914222515.GB27176@jabberwocky.com>

On Tue, Sep 14, 2004 at 10:31:11AM +0200, Eugen Leitl wrote:
> 
> I'm looking for (cheap, PCI/USB) hardware to store secrets (private
> key) and support crypto primitives (signing, cert generation). It
> doesn't have to be fast, but to support loading/copying of secrets
> in physically secure environments, and not generate nonextractable
> secret onboard. Environment is OpenBSD/Linux/OpenSSL/gpg.

Since your environment includes GPG, then I think the OpenPGP
smartcard meets pretty well what you are requesting.  Combine it it
with a USB smartcard reader, and the card becomes USB, too ;)

http://www.silicon-trust.com/pdf/secure_8/48_ppc.pdf
http://www.g10code.de/p-card.html

David

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Tue Sep 14 18:41:11 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Tue, 14 Sep 2004 18:41:11 -0400
Subject: No Paper for Md. Anti-Touchscreen Voters
Message-ID: <p061104e6bd6d23521a8d@[66.149.49.5]>

<http://www.telegram.com/apps/pbcs.dll/article?Date=20040914&Category=APA&ArtNo=409141037&SectionCat=&Template=printart>

Article published Sep 14, 2004

No Paper for Md. Anti-Touchscreen Voters

By TOM STUCKEY
Associated Press Writer

 Maryland's highest court Tuesday rejected demands for additional
safeguards for touchscreen voting machines, saying elections officials have
done everything necessary to ensure the paperless devices are accurate and
secure.

The Court of Appeals also rejected a call to allow citizens who do not
trust touchscreen voting to use paper ballots in the Nov. 2 general
election.

The decision came in a two-paragraph order issued less than three hours
after the judges heard arguments on a suit brought by TrueVoteMD. The
citizens group alleges the electronic machines, used statewide for the
first time in March, are vulnerable to fraud and that the state cannot
guarantee fair and accurate election results.

Lead plaintiff Linda Schade said that although the decision was not a
surprise, it means voters "are going to be forced to vote on an insecure
system."

Schade said the state delayed the suit so long that "judges found
themselves challenged to find a remedy for this upcoming election that
could be implemented in time."

Linda Lamone, state election laws administrator, said outside the courtroom
that making significant changes in the voting system at this late date
would have created chaos on Election Day.

Asked about the security of the state's 16,000 Diebold AccuVote-TS
electronic machines, Lamone said, "I'm very confident they are accurate and
secure."

TrueVoteMD wants the state to equip all electronic machines with printers
that would make a copy of each vote, although it acknowledged in court that
it was too late to do that for the November election.

For the upcoming vote, the group had sought paper ballots for voters who
mistrust the computer voting system, as well as additional security
measures, such as installing Microsoft Windows software patches on the
computers used to tabulate votes.

The group contends paper records would ensure that votes were properly
recorded and could be used for recounts.

"We're basically playing Russian roulette," TrueVoteMD lawyer Ryan Phair
said as he listed potential problems with electronic machines. "We know
there is vulnerability. It is just a matter of time until it happens."

Assistant Attorney General Michael Berman said more than 20 successful
elections have been held in Maryland using the Diebold machines with no
evidence of fraud or allegations of inaccurate vote counts.

Phair mentioned allegations of glitches with computerized systems in other
states, but said it might be impossible to detect widespread fraud such as
rewriting of software to skew election results.

Phair said TrueVoteMD will continue its legal battle to force the state to
use printers on electronic machines in future elections.

Also Tuesday, a local election judge was ordered to return to the
Montgomery County elections board an electronic voting machine that U.S.
Sen. Barbara Mikulski, D-Md., had trouble using in a weekend demonstration.
The machine marked the wrong vote when Mikulski's hand brushed against the
screen, and it took her several attempts to correct the vote.

The election judge, Stan Boyd, had tests performed on the machine, but
would not elaborate on the tests or any findings.

Kevin Karpinski, an attorney for the county board, said any problems
testing might uncover could be misleading because the machine was only for
demonstration purposes and does not have updated software that will be used
in the November election.
-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From iang at systemics.com  Wed Sep 15 11:30:54 2004
From: iang at systemics.com (Ian Grigg)
Date: Wed, 15 Sep 2004 16:30:54 +0100
Subject: pci hardware for secure crypto storage (OpenSSL/OpenBSD)
In-Reply-To: <20040914222515.GB27176@jabberwocky.com>
References: <20040914083111.GX1457@leitl.org> <20040914222515.GB27176@jabberwocky.com>
Message-ID: <4148602E.3020502@systemics.com>

There is a device that is similar to those characteristics:

http://woudt.nl/epass-pgp/
http://www.financialcryptography.com/mt/archives/000201.html

iang

David Shaw wrote:
> On Tue, Sep 14, 2004 at 10:31:11AM +0200, Eugen Leitl wrote:
> 
>>I'm looking for (cheap, PCI/USB) hardware to store secrets (private
>>key) and support crypto primitives (signing, cert generation). It
>>doesn't have to be fast, but to support loading/copying of secrets
>>in physically secure environments, and not generate nonextractable
>>secret onboard. Environment is OpenBSD/Linux/OpenSSL/gpg.
> 
> 
> Since your environment includes GPG, then I think the OpenPGP
> smartcard meets pretty well what you are requesting.  Combine it it
> with a USB smartcard reader, and the card becomes USB, too ;)
> 
> http://www.silicon-trust.com/pdf/secure_8/48_ppc.pdf
> http://www.g10code.de/p-card.html

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From eugen at leitl.org  Wed Sep 15 11:56:04 2004
From: eugen at leitl.org (Eugen Leitl)
Date: Wed, 15 Sep 2004 17:56:04 +0200
Subject: pci hardware for secure crypto storage (OpenSSL/OpenBSD)
In-Reply-To: <4148602E.3020502@systemics.com>
References: <20040914083111.GX1457@leitl.org> <20040914222515.GB27176@jabberwocky.com> <4148602E.3020502@systemics.com>
Message-ID: <20040915155604.GP1457@leitl.org>

On Wed, Sep 15, 2004 at 04:30:54PM +0100, Ian Grigg wrote:
> There is a device that is similar to those characteristics:
> 
> http://woudt.nl/epass-pgp/

"If you loose or damage your token: you loose your private key and any data
encrypted to it. Because the key is generated inside the token and cannot
leave it, it is not possible to make a backup of the private key." is a
knockout criterium, though.

Also an interactive PIN entry for each interaction is a no-no, if the machine
is in a rack at the host.

H4x0rs may break in and sign a few stray blobs, but they won't be able to
steal the private key itself.

> http://www.financialcryptography.com/mt/archives/000201.html

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20040915/0bf64316/attachment.pgp>

From hadmut at danisch.de  Wed Sep 15 11:53:19 2004
From: hadmut at danisch.de (Hadmut Danisch)
Date: Wed, 15 Sep 2004 17:53:19 +0200
Subject: Forensic: Who gave this crypto talk?
Message-ID: <20040915155319.GA31931@danisch.de>

Hi,

I have again one of these special, strange, freaky questions. 
I'm still investigating some "unusual activities" in 
science and cryptography. 

There are some handwritten notes, they seem 
to be some kind of transcript of slides from a talk 
about cryptography. I need to find out when, where, and by
whom that talk was given. 

These notes already existed in the end of 1997, so the 
talk must have been given 1997 or before. 

The talk is about cryptography and system design theory. 
It is about 'layers', such as physics, electrical engieering, 
boolean functions, boolean circuits, algebra of 
polynomial power series, operating system, automata theory. 
It mentions an "access & authentication description language
for a modified secure unix-pw protocol", and comes to 
the conlusion that "crypto can act as a system science". 

Gus Simmons is mentioned several times, but this might not 
have been part of the talk but a personal annotation of the 
person who made the transcript. 

Does anyone know about such a talk?

(The notes are available at 
http://www.danisch.de/tmp/discussion.pdf )


regards
Hadmut








---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From egerck at nma.com  Wed Sep 15 14:39:25 2004
From: egerck at nma.com (Ed Gerck)
Date: Wed, 15 Sep 2004 11:39:25 -0700
Subject: public-key: the wrong model for email?
Message-ID: <41488C5D.8050205@nma.com>

[Perry: please use this version, if possible]

Public-key cryptography burdens the recipient and puts the recipient in
charge, while the sender is at the recipient's mercy. Is this the right
model for email security? After all, the sender is the party at risk.

To clarify, my comment is not that PKC is not useful for email. I believe it
is, but not directly used as it is today.

What I am saying is that the problem is key distribution. I want to separate the
key distribution solution as directly done by PKC today (send the public-key) from
a possible general solution for PKC key distribution that does not require sending
the public-key. The point is that when PKC solves this problem directly, it solves
it in a way that's useful for webservers (the webserver does not have to
trust the client's certificate) but presents difficulties for email senders (the
sender has to trust the recipient's certificate). Email use of PKC treats the
recipient as a server.

I think that what we need is a key distribution method for email (that can still
use PKC and PKI) where, because the sender has all the risk, the sender defines how
email is secured and delivered. The recipient should always be able to receive
it, without too much burden or required previous work.

For example, let's see how FedEx works. The sender chooses the service and the
type of envelope to protect the message. The sender also chooses the instructions
that must be followed before the envelope can be opened by the recipient.
The recipient has no charge to pay for, or burden, in order to receive the
envelope, and does not have to do anything before the envelope is sent. The
recipient is able to verify the identity of the sender and, if so desired,
refuse the envelope. The recipient can open the envelope if and only if
the recipient is willing to follow the sender's instructions (e.g., providing
name, address, date, signature).

Yes, SSL and public-key encryption are and continue to be a success for web
servers. However, the security model for protecting email with public-key
cryptography seems to be backwards, technically and business wise. The sender,
who is the party at risk, has to trust a lock provided by the recipient (his
public-key) to protect her secrets (the message). If FedEx would provide message
security a la PGP, PGP/MIME or S/MIME email, the sender would have to convince
the recipient to pay and send in advance an envelope for the sender to use.
The sender, however, would never know whether the envelope indeed prevented
others from prying into its contents.

A better situation would arise if the lock (i.e., the envelope) would be controlled
by the sender. Moreover, the recipient is not the business driver who needs to
provide, pay for and protect the lock. The sender is the party who has the
motivation to spend money to provide and protect the lock.

In short, I find that public-key cryptography cannot solve the security issues of
email when used as it is today and, most importantly, cannot provide the needed
motivation for users, senders and recipients, to buy into it.

It's not a matter of improvements in usability, better pricing or user education
[1]. It simply does not work as it should work. That's also why, IMO, it does
not take off. It is using the wrong mathematics for the problem.

Does anyone know of any email system that would put the sender in charge?

Comments?

Cheers,
Ed Gerck

[1] Public-key cryptography gives the impression that email message security can
be achieved quite simply. The public-key can be distributed at will, no need for
secrecy, and anyone can receive private and secure messages. The same procedure
being applied to each side, sender and receiver, both could immediately engage
in private and secure communication.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From thierry.moreau at connotech.com  Wed Sep 15 15:49:12 2004
From: thierry.moreau at connotech.com (Thierry Moreau)
Date: Wed, 15 Sep 2004 15:49:12 -0400
Subject: pci hardware for secure crypto storage (OpenSSL/OpenBSD)
In-Reply-To: <20040914083111.GX1457@leitl.org>
References: <20040914083111.GX1457@leitl.org>
Message-ID: <41489CB8.7070704@connotech.com>



Eugen Leitl wrote:

>I'm looking for (cheap, PCI/USB) hardware to store secrets (private key) and
>support crypto primitives (signing, cert generation). It doesn't have to be
>fast, but to support loading/copying of secrets in physically secure environments, and
>not generate nonextractable secret onboard. Environment is
>OpenBSD/Linux/OpenSSL/gpg.
>
>Any suggestions?
>
If I may put words in your mouth, you would require a server-side public 
key cryptography apparatus where the long-term private key value would 
be subject to utmost protection available, and the signature capability 
is nonetheless available to some "functional area" software on an 
general-purpose processor with less stringen protections. Hint: the 
software application where a security certificate is authorized is the 
?functional area? software. Presumably, some key management scheme must 
be provided so that once a "functional area" becomes suspicious, its 
usage of the private key can be rovoked through a key renewal, and the 
private key is not at stake.

The disclosure of such system is at 
http://www.connotech.com/WIRCPATA.HTM. Be reassured that this was a 
preventive publication, so this design is in the public domain (and is, 
or should have been, prior art to US patent 6,671,804).

Such server-side cryptographic hardware is currently under development. 
It should take the form of a 1U operational secure device and a separate 
key management console, the latter ensuring that no significant secret 
is ever stored on a personal computer. The application is not, however, 
certificate signing, as your post implies. I doubt that you will find 
products that fits your need as I expressed them. Perhaps with lower 
security, notably requiring that you trust the API design and 
implementation between the cryptographic hardware and the functional area.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: thierry.moreau at connotech.com


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Wed Sep 15 19:12:54 2004
From: iang at systemics.com (Ian Grigg)
Date: Thu, 16 Sep 2004 00:12:54 +0100
Subject: potential new IETF WG on anonymous IPSec
In-Reply-To: <6.0.3.0.0.20040913114815.04081388@pop.idiom.com>
References: <20040909195729.4798957E2B@finney.org> <C7C59F09-0341-11D9-BE07-000A95E2A184@zooko.com> <tsloekbwclj.fsf@cz.mit.edu> <6.0.3.0.0.20040913114815.04081388@pop.idiom.com>
Message-ID: <4148CC76.7060502@systemics.com>

Bill Stewart wrote:
> Actually, FreeSWAN's "Opportunistic Encryption" meant
> "if you've got IP traffic for somebody,
> see if they can do encryption with you and use it if you can."

That seems to be the meaning of putting "Opportunistic"
and "Encryption" together.

> Because Gilmore wanted to make sure encryption was always done securely,
> their implementation used a common PKI - DNSSEC and inverse DNS -
> which has the advantage that a security gateway can use it when
> all it knows is the IP address of the destination (which is typically 
> the case),
> but the severe disadvantage that very few people have control
> over that DNS space and also that an IP address may belong to more than 
> one domain.
> 
> There's a significant policy question there - if you don't have
> a common PKI of some sort, is it worthwhile encrypting anyway,
> protecting against passive eavesdroppers but not MITM,
> or is that a false sense of security because the people who
> most need security are the people most likely to have a government
> annoyed enough at them to do the work of running a MITM attack?
> Encryption against passive eavesdroppers makes password-stealing
> and traffic analysis harder, so it's probably worth the risk,
> but that wasn't the choice that FreeSWAM made.

Bill, you have a knack for putting this in context.

Historically, it's possible to see why Gilmore went
with the no-risk security, and reduced deployment of
FreeSWAN by an order of magnitude or more.

But, these days, it seems like a no-brainer:  there
is no such thing as an easily accessible trustworthy
PKI.  (I am recalled to mind the Hettingarian creed of
"only financial guaruntees are trustworthy guaruntees...")

And, the ones who have a government annoyed at them
probably know they need special care....  I've not met
a revolutionary that didn't know that the government
is shooting at them.

So the question is, how do we get FreeSWAN to use
opportunistic cryptography, sans DNS?

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Wed Sep 15 19:41:41 2004
From: iang at systemics.com (Ian Grigg)
Date: Thu, 16 Sep 2004 00:41:41 +0100
Subject: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from
 hal@finney.org) (fwd from touch@ISI.EDU)
In-Reply-To: <E1C6uKH-0008Ou-00@medusa01>
References: <E1C6uKH-0008Ou-00@medusa01>
Message-ID: <4148D335.4010207@systemics.com>

Peter Gutmann wrote:
> "Steven M. Bellovin" <smb at research.att.com> writes:
>>>Maybe it's worth doing some sort of generic RFC for this security model to
>>>avoid scattering the same thing over a pile of IETF WGs, 
>>
>>Sounds good.  Who wants to write it...?
> 
> Since there seems to be at least some interest in this, I'll make a start on
> it.  If anyone else wants to add their $0.03 to it [0], let me know.

It occurs to me that a number of these ideas could
be written up over time ... a wiki, anyone?  I think
it is high past time to start documenting crypto
patterns.

FWIW, on opportunistic cryptography (a la "SSH model")
I wrote up a opportunistic draft paper here:

http://iang.org/papers/spock.html

(FTR, I've received substantial comments from TwanVDS
and DigbytT.)

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From lynn at garlic.com  Wed Sep 15 20:54:11 2004
From: lynn at garlic.com (Anne & Lynn Wheeler)
Date: Wed, 15 Sep 2004 18:54:11 -0600
Subject: public-key: the wrong model for email?
In-Reply-To: <41488C5D.8050205@nma.com>
References: <41488C5D.8050205@nma.com>
Message-ID: <6.1.2.0.2.20040915181029.05be2ac0@mail.comcast.net>

At 12:39 PM 9/15/2004, Ed Gerck wrote:
> > [1] Public-key cryptography gives the impression that email message 
> security can
> > be achieved quite simply. The public-key can be distributed at will, no 
> need for
> > secrecy, and anyone can receive private and secure messages. The same 
> procedure
> > being applied to each side, sender and receiver, both could immediately 
> engage
> > in private and secure communication.


there are (at least) 2-3 characteristics of various public key systems

1) the public key doesn't have to be kept confidential as part of the 
distribution

2) you don't need a unique key for every unique security &/or business domain

3) other parties can attest to any bindings between the public key and 
other characteristics

however, while the fact that public key secrecy isn't required (vis-a-vis 
secret keys) ... and possibly enables one or more of the mentioned 
characteristics, public key operation doesn't mandate all such 
characteristics be mandatory for the use of public keys.

PGP allows that a relying party vet a public key with the key owner and/or 
vet the key with one or more others (web-of-trust)

note that while public key alleviates the requirement that a key be 
distributed with secrecy ... it doesn't eliminate the requirement that the 
public key have some trust characteristic associated (i.e. secrecy will 
tend to include some trust, but elimination of secrecy doesn't eliminate 
the requirement for trust).

so an infrastructure analogy to physical mail for public key .... is that 
public key becomes the trusted address for the recipient. in the physical 
world ... to send some mail ... you need a trusted mailing address for the 
recipient ... you need to have acquired that address in some manner and 
furthermore have some trust that it is the correct address. so lets assume 
that some number of equivalent mechanisms exist for public keys. it so 
happens that the encryption of the contents with the public key and the 
addressing of the contents with that same public key .... has some 
associated trusted infrastructure that delivers the package to the correct 
recipient.

lets say that instead of having personal zip-codes and personal cell-phone 
numbers (that you take with you regardless of the service and/or physical 
location)... that can reach you regardless of where you happen to be in the 
world ....  the "number" that can be guaranteed to reach you, also happens 
to have the characteristics of a public key.

so public key mapping to entity infrastructures take on similar 
characteristics as personal (physical) mailing addresses and/or personal 
cell-phone numbers ... and then you have trusted infrastructures (usps, 
telephone companies, gov. posts) that can be relied on to make the 
connection to the appropriate recipient .... which then approximates a
public key paradigm mapping to existing physical world paradigms.

in the current physical world infrastructure, the publication &/or 
distribution of addresses are relatively low-cost (&/or free) operations 
with the infrastructures making their real money off the delivery ... as 
opposed to the publication.

translated to the internet paradigm .... everybody has a public key (in 
much the same way that everybody can have a personal cellphone number that 
may reach them regardless of where they are in the world). the public key 
is registered in something like the domain name infrastructure which then 
is able to figure out how to find you in the world (in manner similar to 
how personal cellphone number can find you anywhere in the world).

it isn't necessary that public key paradigms have to be the wrong model for 
email .... it is that the various existing economic models for making money 
off of public key infrastructures may be inconsistent with normal expected 
business operations. however, there is nothing intrinsic to public keys 
that mandate they are tied to existing public key infrastructure economic 
models.

--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/  

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From b.m.m.d.weger at TUE.nl  Thu Sep 16 03:43:51 2004
From: b.m.m.d.weger at TUE.nl (Weger, B.M.M. de)
Date: Thu, 16 Sep 2004 09:43:51 +0200
Subject: public-key: the wrong model for email?
Message-ID: <9F38CF35D80CAE409B979F3EB5242B4A01846669@winex2.campus.tue.nl>

Hi Ed,

What about ID-based crypto: the public key can be any string, such as
your e-mail address. So the sender can encrypt even before the
recipient has a key pair. The private key is derived from the
public key by a trusted party when the recipient asks for it.
Yes, the recipient does have some burden here, but it seems to
me that that is unavoidable.
I'm not saying that this is without problems (private key distribution,
inherent key escrow / recovery, revocation issues), or that it's easier 
manageable than traditional PKI, but it may solve some of your issues.

The idea for ID-based crypto comes from Adi Shamir, back in 1984.
The first practical and mathematically sound realisation is due to
Boneh and Franklin (Crypto 2001), and is brought to the market
by Voltage (www.voltage.com). I don't know their products, only that
it exists, and I'm not a shareholder. I do think it's interesting
math and interesting crypto, and that it could lead to interesting 
technology.

Grtz,
Benne de Weger

========================================= 
Technische Universiteit Eindhoven 
Coding & Crypto Groep 
Faculteit Wiskunde en Informatica 
Den Dolech 2 
Postbus 513 
5600 MB Eindhoven 
kamer HG 9.84 
tel. (040) 247 2704, bgg 5141 
e-mail: b.m.m.d.weger at tue.nl 
www: http://www.win.tue.nl/~bdeweger 
========================================= 
 

> -----Original Message-----
> From: owner-cryptography at metzdowd.com 
> [mailto:owner-cryptography at metzdowd.com] On Behalf Of Ed Gerck
> Sent: woensdag 15 september 2004 20:39
> To: cryptography at metzdowd.com
> Subject: public-key: the wrong model for email?
> 
> [Perry: please use this version, if possible]
> 
> Public-key cryptography burdens the recipient and puts the 
> recipient in charge, while the sender is at the recipient's 
> mercy. Is this the right model for email security? After all, 
> the sender is the party at risk.
> 
> To clarify, my comment is not that PKC is not useful for 
> email. I believe it is, but not directly used as it is today.
> 
> What I am saying is that the problem is key distribution. I 
> want to separate the key distribution solution as directly 
> done by PKC today (send the public-key) from a possible 
> general solution for PKC key distribution that does not 
> require sending the public-key. The point is that when PKC 
> solves this problem directly, it solves it in a way that's 
> useful for webservers (the webserver does not have to trust 
> the client's certificate) but presents difficulties for email 
> senders (the sender has to trust the recipient's 
> certificate). Email use of PKC treats the recipient as a server.
> 
> I think that what we need is a key distribution method for 
> email (that can still use PKC and PKI) where, because the 
> sender has all the risk, the sender defines how email is 
> secured and delivered. The recipient should always be able to 
> receive it, without too much burden or required previous work.
> 
> For example, let's see how FedEx works. The sender chooses 
> the service and the type of envelope to protect the message. 
> The sender also chooses the instructions that must be 
> followed before the envelope can be opened by the recipient.
> The recipient has no charge to pay for, or burden, in order 
> to receive the envelope, and does not have to do anything 
> before the envelope is sent. The recipient is able to verify 
> the identity of the sender and, if so desired, refuse the 
> envelope. The recipient can open the envelope if and only if 
> the recipient is willing to follow the sender's instructions 
> (e.g., providing name, address, date, signature).
> 
> Yes, SSL and public-key encryption are and continue to be a 
> success for web servers. However, the security model for 
> protecting email with public-key cryptography seems to be 
> backwards, technically and business wise. The sender, who is 
> the party at risk, has to trust a lock provided by the recipient (his
> public-key) to protect her secrets (the message). If FedEx 
> would provide message security a la PGP, PGP/MIME or S/MIME 
> email, the sender would have to convince the recipient to pay 
> and send in advance an envelope for the sender to use.
> The sender, however, would never know whether the envelope 
> indeed prevented others from prying into its contents.
> 
> A better situation would arise if the lock (i.e., the 
> envelope) would be controlled by the sender. Moreover, the 
> recipient is not the business driver who needs to provide, 
> pay for and protect the lock. The sender is the party who has 
> the motivation to spend money to provide and protect the lock.
> 
> In short, I find that public-key cryptography cannot solve 
> the security issues of email when used as it is today and, 
> most importantly, cannot provide the needed motivation for 
> users, senders and recipients, to buy into it.
> 
> It's not a matter of improvements in usability, better 
> pricing or user education [1]. It simply does not work as it 
> should work. That's also why, IMO, it does not take off. It 
> is using the wrong mathematics for the problem.
> 
> Does anyone know of any email system that would put the 
> sender in charge?
> 
> Comments?
> 
> Cheers,
> Ed Gerck
> 
> [1] Public-key cryptography gives the impression that email 
> message security can be achieved quite simply. The public-key 
> can be distributed at will, no need for secrecy, and anyone 
> can receive private and secure messages. The same procedure 
> being applied to each side, sender and receiver, both could 
> immediately engage in private and secure communication.
> 
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to 
> majordomo at metzdowd.com
> 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From egerck at nma.com  Thu Sep 16 01:19:52 2004
From: egerck at nma.com (Ed Gerck)
Date: Wed, 15 Sep 2004 22:19:52 -0700
Subject: public-key: the wrong model for email?
In-Reply-To: <6.1.2.0.2.20040915181029.05be2ac0@mail.comcast.net>
References: <41488C5D.8050205@nma.com> <6.1.2.0.2.20040915181029.05be2ac0@mail.comcast.net>
Message-ID: <41492278.3090303@nma.com>

Anne & Lynn Wheeler wrote:

> PGP allows that a relying party vet a public key with the key owner 
> and/or vet the key with one or more others (web-of-trust)
> 
> note that while public key alleviates the requirement that a key be 
> distributed with secrecy ... it doesn't eliminate the requirement that 
> the public key have some trust characteristic associated (i.e. secrecy 
> will tend to include some trust, but elimination of secrecy doesn't 
> eliminate the requirement for trust).

Lynn,

My question on this is not about trust, even though I usually have  many
questions on trust ;-)

Yes, PKC provides a workable solution for key distribution... when you
look at servers. For email, the PKC solution is not workable (hasn't been)
and gives a false impression of security. For example, the sender has no
way of knowing if the recipient's key is weak (in spite of its length)
or has some "key-access" feature. Nonetheless, the sender has to use that
key.

The analogy here is with you sending a confidential document using a courier
you don't know and cannot verify. Would you?

Further, it is generally in the recipient's interest that the decision to
send document X using channel Y should be under the sender's control. Any
limitation or directive imposed by the recipient on the sender (such as:
use my public-key) can shift the burden of risk to the recipient (your key
was weak, hence I had a loss). Liability follows power. The current use of
PKC in email is neither good to the sender nor to the recipient.

To further clarify, my comment is not that PKC is not useful for email. I
believe it is, but not directly used as it is today. The PKC key distribution
solution is backwards for email.

Cheers,
Ed Gerck

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From egerck at nma.com  Thu Sep 16 05:05:15 2004
From: egerck at nma.com (Ed Gerck)
Date: Thu, 16 Sep 2004 02:05:15 -0700
Subject: public-key: the wrong model for email?
In-Reply-To: <9F38CF35D80CAE409B979F3EB5242B4A01846669@winex2.campus.tue.nl>
References: <9F38CF35D80CAE409B979F3EB5242B4A01846669@winex2.campus.tue.nl>
Message-ID: <4149574B.800@nma.com>

Benne,

With Voltage, all communications corresponding to the same public key can be
decrypted using the same private key, even if the user is offline. To me, this
sounds worse than the PKC problem of trusting the recipient's key. Voltage
also corresponds to mandatory key escrow, as you noted, with all its drawbacks.

Cheers,
Ed Gerck

Weger, B.M.M. de wrote:

> Hi Ed,
> 
> What about ID-based crypto: the public key can be any string, such as
> your e-mail address. So the sender can encrypt even before the
> recipient has a key pair. The private key is derived from the ...

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From wk at gnupg.org  Thu Sep 16 06:15:42 2004
From: wk at gnupg.org (Werner Koch)
Date: Thu, 16 Sep 2004 12:15:42 +0200
Subject: pci hardware for secure crypto storage (OpenSSL/OpenBSD)
In-Reply-To: <4148602E.3020502@systemics.com> (Ian Grigg's message of "Wed,
 15 Sep 2004 16:30:54 +0100")
References: <20040914083111.GX1457@leitl.org>
	<20040914222515.GB27176@jabberwocky.com>
	<4148602E.3020502@systemics.com>
Message-ID: <878ybacyep.fsf@wheatstone.g10code.de>

On Wed, 15 Sep 2004 16:30:54 +0100, Ian Grigg said:

> There is a device that is similar to those characteristics:
> http://woudt.nl/epass-pgp/
> http://www.financialcryptography.com/mt/archives/000201.html

The advantage of the OpenPGP card is that is is a specification that
it is open and ready for everyone to implement.  No proprietary
strings attached as usual in the smartcard business.  So go write an
application according to the specs and it will, run with any card
compliant with the spec.  Any vendor may implement this spec on his
card.  Whether you do this on a slow 4 Euro chip or a fast 8 Euro chip
or on an iButton is up to you.  Our card is just one implementation of
the spec using an expensive chip.


  Werner

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From lindac at dimacs.rutgers.edu  Thu Sep 16 09:57:17 2004
From: lindac at dimacs.rutgers.edu (Linda Casals)
Date: Thu, 16 Sep 2004 09:57:17 -0400 (EDT)
Subject: [Publicity-list] DIMACS Workshop on Computational Issues in Auction Design
Message-ID: <200409161357.JAA08356@dimacs.rutgers.edu>


*************************************************
     
DIMACS Workshop on Computational Issues in Auction Design
          
     October 7 - 8, 2004
     DIMACS Center, Rutgers University, Piscataway, NJ

Organizers: 
       
     Jayant Kalagnanam, IBM Watson Lab, jayant at us.ibm.com  
     Eric Maskin, School of Social Science, Institute for Advanced
         Study, maskin at ias.edu 
     David Parkes, Harvard University, parkes at eecs.harvard.edu 
     Aleksandar Pekec, Fuqua School of Business, Duke University,
         pekec at duke.edu 
     Michael Rothkopf, Rutgers University, rothkopf at rutcor.rutgers.edu 
     
Presented under the auspices of the Special Focus on Computation and
the Socio-Economic Sciences.

    ************************************************ 

Recent advances in information technology and its rapid acceptance by
the business community have allowed for the possibility of expediting
complex business transactions. The most prominent example is use of
auctions in corporate procurement and in government deregulation
efforts. When many items with interrelated values are being sold,
economic efficiency can be increased by allowing bidders to make bids
on combinations of items. Procedures for auctioning combinations of
items have inherent computational problems that have to be overcome,
and the emergence of these issues has sparked considerable research
activity in the computer science and combinatorial optimization
communities. The most prominent example is combinatorial auctions in
which multiple goods are auctioned and bidders have and wish to
express different valuations on which goods complement each other and
which goods substitute for each other.

Topics of interest include:
-- expressive bidding languages
-- practical applications (e.g. to electricity, spectrum,...)
-- procurement and e-sourcing
-- combinatorial exchanges
-- preference elicitation
-- optimal auction design
-- approximate mechanisms
-- communication and computation complexity in combinatorial auctions

**************************************************************
Workshop Program:

Thursday, October 7, 2004 

 8:00 -  8:30  Registration and Breakfast - CoRE Building, 4th Floor

 8:30 -  8:45  Welcome and Opening Remarks
               Fred Roberts, DIMACS Director

 8:45 -  9:30  Characterizing Dominant Strategy Mechanisms with 
               Multi-dimensional types
               Rakesh Vohra, Northwestern

 9:30 - 10:10  Multiitem auctions with credit limits
               Shmuel Oren and Shehzad Wadalawala, UC Berkeley

10:10 - 10:30  Break

10:30 - 11:15  Approximation Algorithms for Truthful Mechanisms
               Eva Tardos, Cornell
             
11:15 - 11:55  Tolls for heterogeneous selfish users in multicommodity
               generalized congestion games
               Lisa Fleischer, Carnegie Mellon University, Kamal Jain,
               MSR and Mohammad Mahdian, MIT

11:55 - 12:35  VCG Overpayment in Random Graphs
               Evdokia Nikolova and  David Karger, MIT

12:35 -  2:00  Lunch

 2:00 -  2:45  The communication requirements of social
               choice rules and supporting budget sets
               Ilya Segal, Stanford University

 2:45 -  3:25  The communication complexity of the private
               value single item bisection auction
               Elena Grigorieva,  P Jean-Jacques Herings, Rudolf Muller, and
	       Dries Vermeulen, University Maastricht, the Netherlands

 3:25 -  3:45  Break

 3:45 -  4:30  Market Mechanisms for Redeveloping Spectrum
               Evan Kwerel, FCC

 4:30 -  5:15  Issues in Electricity Market Auction Design
               Richard O'Neill, FERC

 5:15 -  6:15  Panel

 6:30          Dinner

Friday, October 8, 2004

 8:00 -  8:30  Breakfast and Registration

 8:30 -  9:15  Incentive Compatibility in Multi-unit Auctions
               Sushil Bikhchandani, UCLA
             
 9:15 - 10:00  The Over-Concentrating Nature of Simultaneous Ascending Auctions
               Charles Zheng, Northwestern

10:00 - 10:20  Break

10:20 - 11:00  Designing Auction Protocols under Asymmetric Information on
               Nature's Selection
               Takayuki Ito, Nagoya Inst.,  Makoto Yokoo, Kyushu and
               Shigeo Matsubara, NTT

11:00 - 11:40  Elicitation in combinatorial auctions with restricted 
               preferences and bounded interdependency between items
               Vincent Conitzer and Tuomas Sandholm, Carnegie 
               Mellon University, and Paolo Santi, Pisa University
               
11:40 - 12:20  Applying learning algorithms to preference elicitation
               in combinatorial auctions
               Sebastien Lahaie and David C. Parkes, Harvard

12:20 -  1:30  Lunch


 1:30 -  2:15  To auction or not?  Historical perspectives on the development
               of ecommerce
               Andrew Odlyzko, University of Minnesota

 2:15 -  2:55  Non-computational Approaches to Mitigating Computational Problems
               in Combinatorial Auctions
               Sasa Pekec, Duke University and Michael Rothkopf, Rutgers University

 2:55 -  3:15  Break

 3:15 -  3:55  The Clock-Proxy Auction: A Practical Combinatorial Auction Design
               Peter Cramton and Lawrence M.Ausubel, University of Maryland and
	       Paul Milgrom, Stanford University

 3:55 -  4:35  Generation and Selection of Core Outcomes in Sealed Bid
               Combinatorial Auctions
               Bob Day and S Raghavan, University of Maryland

 4:35 -  5:15  Eliciting Bid Taker Non-price Preferences
               in (Combinatorial) Auctions
               Craig Boutilier, University of Toronto, 
               Tuomas Sandholm, Carnegie Mellon University 
               and Rob Shields, CombineNet

Poster Presentations:

Methods for boosting revenue in Combinatorial Auctions
Anton Likhodedov and Tuomas Sandholm, Carnegie Mellon University

Arbitrage in Combinatorial Exchanges
Andrew Gilpin and Tuomas Sandholm, Carnegie Mellon University

Optimal Auctions with Finite Support
Edith Elkind, Princeton University

Optimal Distributed Protocols for Generalized Job 
Shop Scheduling Problems via Ascending Combinatorial Auctions
Judy Geng and Roy Kwon, University of Toronto

Negotiation-Range Mechanisms: Coalition-Resistant Markets
Rica Gonen, Hebrew University

A Bidder Aid Tool for Dynamic Package Creation in the 
FCC Spectrum Auctions
Karla Hoffman, GMU, Dinesh Menon and 
Susara A. van den Heever, Decision Analytics

An Exact Algorithm for Procurement Problems under a 
Total Quantity Discount Structure
D.Goossens, A.Maas, F.C.R. Spieksma, and 
J.J van de Klundert, Maastricht U. and Katholieke U. Leuven

Approximation Algorithms for CAs with Complement-Free Bidders
Shahar Dobzinski, Noam Nisan, Michael Schapiraz, The Hebrew
University, University of Jerusalum


**************************************************************
Registration Fees:

(Pre-registration deadline: September 30, 2004)

Please see website for additional registration information.

*********************************************************************
Information on participation, registration, accomodations, and travel 
can be found at:

http://dimacs.rutgers.edu/Workshops/AuctionDesign/

   **PLEASE BE SURE TO PRE-REGISTER EARLY**

*******************************************************************

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From adam at homeport.org  Thu Sep 16 11:54:35 2004
From: adam at homeport.org (Adam Shostack)
Date: Thu, 16 Sep 2004 11:54:35 -0400
Subject: public-key: the wrong model for email?
In-Reply-To: <4149574B.800@nma.com>
References: <9F38CF35D80CAE409B979F3EB5242B4A01846669@winex2.campus.tue.nl> <4149574B.800@nma.com>
Message-ID: <20040916155434.GG12604@lightship.internal.homeport.org>

Given our failure to deploy PKC in any meaningful way*, I think that
systems like Voltage, and the new PGP Universal are great.

* I don't see Verisign's web server tax as meaningful; they accept no
liability, and numerous companies foist you off to unrelted domains.
We could get roughly the same security level from fully opportunistic
or memory-oportunistic models.

Adam

On Thu, Sep 16, 2004 at 02:05:15AM -0700, Ed Gerck wrote:
| Benne,
| 
| With Voltage, all communications corresponding to the same public key can be
| decrypted using the same private key, even if the user is offline. To me, 
| this
| sounds worse than the PKC problem of trusting the recipient's key. Voltage
| also corresponds to mandatory key escrow, as you noted, with all its 
| drawbacks.
| 
| Cheers,
| Ed Gerck
| 
| Weger, B.M.M. de wrote:
| 
| >Hi Ed,
| >
| >What about ID-based crypto: the public key can be any string, such as
| >your e-mail address. So the sender can encrypt even before the
| >recipient has a key pair. The private key is derived from the ...
| 
| ---------------------------------------------------------------------
| The Cryptography Mailing List
| Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From lynn at garlic.com  Thu Sep 16 12:42:37 2004
From: lynn at garlic.com (Anne & Lynn Wheeler)
Date: Thu, 16 Sep 2004 10:42:37 -0600
Subject: public-key: the wrong model for email?
In-Reply-To: <41492278.3090303@nma.com>
References: <41488C5D.8050205@nma.com>
 <6.1.2.0.2.20040915181029.05be2ac0@mail.comcast.net>
 <41492278.3090303@nma.com>
Message-ID: <6.1.2.0.2.20040916102815.04395c70@mail.comcast.net>

At 11:19 PM 9/15/2004, Ed Gerck wrote:
>Yes, PKC provides a workable solution for key distribution... when you
>look at servers. For email, the PKC solution is not workable (hasn't been)
>and gives a false impression of security. For example, the sender has no
>way of knowing if the recipient's key is weak (in spite of its length)
>or has some "key-access" feature. Nonetheless, the sender has to use that
>key.


the issue then is what level do you trust the recipient, what is the threat 
model, and what are the countermeasures.

if there is a general trust issue with the recipient (not just their key 
generating capability) ... then a classified document compromise could 
happen after it has been transmitted. you may have to do a complete audit & 
background check of the recipient before any distribution of classified 
document.

if the threat model is purely the document transmission, and you worry only 
about the recipient's key generating capability being up to the task of 
protecting the document transmission ... but you otherwise aren't worried 
about other trust issues with the recipient ... then go for 3rd party 
secure transmission service ... say where the encrypted package is 
delivered to the recipient and the recipient has to do some sort of 
real-time retrieval from the 3rd party of the package encryption key.

in the physical world ... there still could be the issue that the delivery 
address for the recipient (to be used by the 3rd party delivery service) 
might not be trusted.

part of the problem with introducing trust issues involving any specific 
recipient issue starts a real slippery slope  .... since the security of 
the system is all of the infrastructure .... and just addressing a single 
recipient trust issue (like key generation strength) .... still leaves open 
all sorts of other recipient trust issues.

say you have 3rd party encryption and secure delivery ...  with the 
possibility that the electronic package might be evesdropped (copied but 
not decoded). the issue then is how does the 3rd party know that the 
correct recipient is the only one that obtains the correct decryption key. 
there has to be some trust at some point that the correct recipient and 
only the correct recipient can decode any encrypted electronic package. at 
some point there has to be some flavor of trusting some sort of recipient 
authentication mechanism.

either the sender has it before hand (like the recipient's public key) or 
there is some sort of post-transmission authentication of the recipient. 
eliminating the requirement for strong authentication of the recipient 
before the transmission doesn't really eliminate the problem, it just moves 
it to some point.

--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/ 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Thu Sep 16 13:12:48 2004
From: iang at systemics.com (Ian Grigg)
Date: Thu, 16 Sep 2004 18:12:48 +0100
Subject: public-key: the wrong model for email?
In-Reply-To: <20040916155434.GG12604@lightship.internal.homeport.org>
References: <9F38CF35D80CAE409B979F3EB5242B4A01846669@winex2.campus.tue.nl> <4149574B.800@nma.com> <20040916155434.GG12604@lightship.internal.homeport.org>
Message-ID: <4149C990.3020106@systemics.com>

Adam Shostack wrote:
> Given our failure to deploy PKC in any meaningful way*, I think that
> systems like Voltage, and the new PGP Universal are great.

I think the consensus from debate back last year on
this group when Voltage first surfaced was that it
didn't do anything that couldn't be done with PGP,
and added more risks to boot.  So, yet another biz
idea with some hand wavey crypto, which is great if
it works, but it's not necessarily security.

> * I don't see Verisign's web server tax as meaningful; they accept no
> liability, and numerous companies foist you off to unrelted domains.
> We could get roughly the same security level from fully opportunistic
> or memory-oportunistic models.

Yes, or worse;  it turns out that Verisign may very
well be the threat as well as the solution.  As I
wrote here:

http://www.financialcryptography.com/mt/archives/000206.html

Verisign are in the eavesdropping business, which
not only calls into doubt their own certs, but also
all other CAs, and the notion of a trusted third
party as a workable concept.

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From egerck at nma.com  Thu Sep 16 14:53:48 2004
From: egerck at nma.com (Ed Gerck)
Date: Thu, 16 Sep 2004 11:53:48 -0700
Subject: public-key: the wrong model for email?
In-Reply-To: <6.1.2.0.2.20040916102815.04395c70@mail.comcast.net>
References: <41488C5D.8050205@nma.com> <6.1.2.0.2.20040915181029.05be2ac0@mail.comcast.net> <41492278.3090303@nma.com> <6.1.2.0.2.20040916102815.04395c70@mail.comcast.net>
Message-ID: <4149E13C.7060102@nma.com>


Anne & Lynn Wheeler wrote:

  > the issue then is what level do you trust the recipient, what is the
> threat model, and what are the countermeasures.
> 
> if there is a general trust issue with the recipient (not just their key 
> generating capability) ... then a classified document compromise could 
> happen after it has been transmitted. you may have to do a complete 
> audit & background check of the recipient before any distribution of 
> classified document.

If the recipient cannot in good faith detect a key-access ware, or a
GAK-ware, or a Trojan, or a bug, why would a complete background
check of the recipient help?

Talking about trust, it is important to note that when the email is sent
the recipient is already trusted not to disclose. But even though the
recipient is trustworthy his environment may not be. It is not a matter of
personal trust  or "complete background checks". This may all be fine
and, unknown to the recipient, the key might be weak, on purpose or by
some key-access "feature" included in the software (unknown to the user).
Or, the PKC software may have a bug (as PGP recently disclosed).

Loss from disclosure is also something that is much more important for
the sender. If the recipient's public-key fails to be effective in
protecting the sender, the sender's information is compromised. That's
why I make the point that PKC for email has it backwards: the sender
should not be at the recipient's mercy.

PKC for email also reverses the usual business model, because the
recipient is not so interested in protecting the sender or paying
for the sender's security. The sender would.

Regarding the use of PKC to sign emails, I see no problems using
PKC. The sender has the private-key, has the incentive to keep it
secure, and uses it to sign when he so desires. The sender does not
need to rely on the recipient, or receive anything from the recipient,
in order to sign an email. The problem with PKC email signature is
PKI. However, email signature can also be done without PKI, by PGP.

Cheers,
Ed Gerck

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From egerck at nma.com  Thu Sep 16 15:05:57 2004
From: egerck at nma.com (Ed Gerck)
Date: Thu, 16 Sep 2004 12:05:57 -0700
Subject: public-key: the wrong model for email?
In-Reply-To: <4149C990.3020106@systemics.com>
References: <9F38CF35D80CAE409B979F3EB5242B4A01846669@winex2.campus.tue.nl> <4149574B.800@nma.com> <20040916155434.GG12604@lightship.internal.homeport.org> <4149C990.3020106@systemics.com>
Message-ID: <4149E415.9040307@nma.com>

> Adam Shostack wrote:
> 
> I think the consensus from debate back last year on
> this group when Voltage first surfaced was that it
> didn't do anything that couldn't be done with PGP,
> and added more risks to boot.

Voltage actually does. It allows secure communication
without pre-registering the recipient.

Cheers,
Ed Gerck

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Thu Sep 16 16:06:47 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Thu, 16 Sep 2004 16:06:47 -0400
Subject: Phones gain coded security
Message-ID: <p06110413bd6fa2a9f645@[66.149.49.5]>

<http://www.vnunet.com/print/1158147>


IT Week

 Phones gain coded security

Certicom offers a cross platform security kit for handset developers
Daniel Robinson, IT Week 16 Sep 2004

Cryptography firm Certicom has announced a cross-platform security toolkit
for future mobile phone handsets. The Certicom Security Architecture for
Mobility will provide a common programming interface for developers to
access functions such as encryption across various mobile chipsets and
operating systems, according to the firm. The move should speed development
of handsets with better security.

Certicom's Security Architecture for Mobility (CSA) builds on the company's
Security Builder Middleware, a hardware abstraction layer that is optimised
to work with a specific chipset or hardware platform. The first supported
hardware will be Intel's Wireless Trusted Platform, which consists of
security functions that are built into Intel's PXA270 series of XScale
mobile chips. CSA will support this from the fourth quarter of this year,
and support for other mobile platforms will follow.

"Pressure for greater security is coming from enterprise customers.
[Security] used to be seen as an add-on to IT systems, but lately it has
been regarded as something that has to be embedded from the beginning,"
commented Certicom's vice-president of marketing, Roy Pereira.

CSA has resulted from Certicom's collaboration with Intel on security for a
major handset vendor, Pereira said. He declined to name the vendor, for
commercial reasons. Handset vendors are focused on applications, not
cryptography, Certicom said, and its middleware layer lets them easily
build in cryptography support, shortening the development time and giving
handset makers a common interface for encryption functions no matter what
the underlying chipset is.

"They could move their code from a basic ARM chip to a PXA270 and get a
boost from the hardware support without having to rewrite," Pereira said.

CSA also includes a software cryptography module for platforms that do not
have on-chip encryption hardware. Other optional modules include Security
Builder IPSec, a library of VPN functions for resource-constrained devices;
Security Builder SSL for Secure Sockets Layer commun- ications; and
Security Builder PKI for managing digital certificates.

However, CSA offers more than just encryption, according to Pereira. It
supports the secure boot feature of Intel's Wireless Trusted Platform,
which checks the handset has not been tampered with before starting the
operating system. Certicom said it would support all major handset
platforms, including those with on-chip security hardware.


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From hadmut at danisch.de  Thu Sep 16 16:28:59 2004
From: hadmut at danisch.de (Hadmut Danisch)
Date: Thu, 16 Sep 2004 22:28:59 +0200
Subject: public-key: the wrong model for email?
In-Reply-To: <41488C5D.8050205@nma.com>
References: <41488C5D.8050205@nma.com>
Message-ID: <20040916202859.GA4640@danisch.de>

On Wed, Sep 15, 2004 at 11:39:25AM -0700, Ed Gerck wrote:
> 
> Yes, SSL and public-key encryption are and continue to be a success for web
> servers. However, the security model for protecting email with public-key
> cryptography seems to be backwards, technically and business wise.


Exactly. It is easy to protect web sites with SSL, but it is difficult
to protect e-mail against spam with PKC.

Why?

Because PKC works for this Alice&Bob communication scheme. If you 
connect to a web server, then what you want to know, or what 
authentication means is: "Are you really www.somedomain.com?"
That's the Alice&Bob model. SSL is good for that.

If I send you an encrypted e-mail, I do want that _you_ Ed Gerck, 
can read it only. That's still the Alice&Bob model. PGP and S/MIME
are good for that. 

If you send me an e-mail with a signature, and there is any particular
relation between you and me, where it is important for an attacker to 
pretend to be Ed Gerck and not just anyone, even that is still the 
Alice&Bob model. PGP and S/MIME still work.

But that's not the way E-Mail works in common.

E-Mail means: Anyone on this world is basically able to send 
me an e-mail. And that's not yet an attack, because that's what
I want, that's why I put my e-mail address on my web page.

This is not Alice&Bob anymore. 

This is Anyone&Bob.

The sender of an e-mail does not need to pretend beeing a particular
person or sender. Any identity of the 8 (10?) billion humans on earth
will do it. 

What does it mean if the message has a digital signature? It most
certainly means that the sender is a human from planet earth. You 
could tell the same without a signature.

PKC is good as long as the communication model is a closed and 
relatively small user group. A valid signature of an unknown sender
has at least the meaning that the sender belongs to that user group. 

But if that 'closed user group' is all mankind, then this meaning
becomes useless. A digital signature is useful only if you know the
sender of if you can tell from the signature that the sender belongs
to a closed user group (e.g. is a citizen of some jurisdiction). 

But this is not the Alice&Bob model anymore. That's not what 
PKC is good for. 



There's another problem: 

Since e-mail does not require to forge mails from a particular
identity, but from anyone, you run into the problem that there 
are plenty of unsecure keys floating around. 

When Alice keeps her key well protected, an Attacker has no 
chance.

But for E-Mail, there is not just one Alice. There are
about 500 Millions of users.

Let's imagine that everyone has a public/secret key pair. 

How many of them use a Windows Computer vulnerable to the 
latest worm collecting all secrets from their computer?
If only 0.2% of those keys were compromised, that's still 

     1 Million of secret keys 

available for spammers etc.


Let's assume that this 1,000,000 keys were compromised 
within one year. That's an average of 2,700 keys a day. 
So the attackers/spammers/phishers have 2,700 fresh keys
every day to forge e-mail, and most of the owners will 
not even realize that their key was stolen within that day. 

This is where reality and the science of cryptography differ. 

It does not work because not all attackers agree to 
play the Alice&Bob game.


regards
Hadmut







---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From adam at homeport.org  Thu Sep 16 19:35:09 2004
From: adam at homeport.org (Adam Shostack)
Date: Thu, 16 Sep 2004 19:35:09 -0400
Subject: public-key: the wrong model for email?
In-Reply-To: <4149E415.9040307@nma.com>
References: <9F38CF35D80CAE409B979F3EB5242B4A01846669@winex2.campus.tue.nl> <4149574B.800@nma.com> <20040916155434.GG12604@lightship.internal.homeport.org> <4149C990.3020106@systemics.com> <4149E415.9040307@nma.com>
Message-ID: <20040916233508.GA22039@lightship.internal.homeport.org>

On Thu, Sep 16, 2004 at 12:05:57PM -0700, Ed Gerck wrote:
| >Adam Shostack wrote:
| >
| >I think the consensus from debate back last year on
| >this group when Voltage first surfaced was that it
| >didn't do anything that couldn't be done with PGP,
| >and added more risks to boot.
| 
| Voltage actually does. It allows secure communication
| without pre-registering the recipient.

Generate a key for "unknown-recipient at foocorp.com" encrypt mail to
Bob to that key.  When Bob shows up, decrypt and send over ssl.

Adam

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From adam at homeport.org  Thu Sep 16 19:36:20 2004
From: adam at homeport.org (Adam Shostack)
Date: Thu, 16 Sep 2004 19:36:20 -0400
Subject: public-key: the wrong model for email?
In-Reply-To: <4149C990.3020106@systemics.com>
References: <9F38CF35D80CAE409B979F3EB5242B4A01846669@winex2.campus.tue.nl> <4149574B.800@nma.com> <20040916155434.GG12604@lightship.internal.homeport.org> <4149C990.3020106@systemics.com>
Message-ID: <20040916233620.GB22039@lightship.internal.homeport.org>

On Thu, Sep 16, 2004 at 06:12:48PM +0100, Ian Grigg wrote:
| Adam Shostack wrote:
| >Given our failure to deploy PKC in any meaningful way*, I think that
| >systems like Voltage, and the new PGP Universal are great.
| 
| I think the consensus from debate back last year on
| this group when Voltage first surfaced was that it
| didn't do anything that couldn't be done with PGP,
| and added more risks to boot.  So, yet another biz
| idea with some hand wavey crypto, which is great if
| it works, but it's not necessarily security.

Sure, I like the system even if it breaks, because it focuses on ease
of use.  I didn't say I thought it secure.

| >* I don't see Verisign's web server tax as meaningful; they accept no
| >liability, and numerous companies foist you off to unrelted domains.
| >We could get roughly the same security level from fully opportunistic
| >or memory-oportunistic models.
| 
| Yes, or worse;  it turns out that Verisign may very
| well be the threat as well as the solution.  As I
| wrote here:
| 
| http://www.financialcryptography.com/mt/archives/000206.html
| 
| Verisign are in the eavesdropping business, which
| not only calls into doubt their own certs, but also
| all other CAs, and the notion of a trusted third
| party as a workable concept.

Yes.

Adam

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From bill.stewart at pobox.com  Thu Sep 16 19:57:39 2004
From: bill.stewart at pobox.com (Bill Stewart)
Date: Thu, 16 Sep 2004 16:57:39 -0700
Subject: public-key: the wrong model for email?
In-Reply-To: <41492278.3090303@nma.com>
References: <41488C5D.8050205@nma.com>
 <6.1.2.0.2.20040915181029.05be2ac0@mail.comcast.net>
 <41492278.3090303@nma.com>
Message-ID: <6.0.3.0.0.20040916162226.042a2808@pop.idiom.com>

At 10:19 PM 9/15/2004, Ed Gerck wrote:
>Yes, PKC provides a workable solution for key distribution... when you
>look at servers. For email, the PKC solution is not workable (hasn't been)
>and gives a false impression of security. For example, the sender has no
>way of knowing if the recipient's key is weak (in spite of its length)
>or has some "key-access" feature. Nonetheless, the sender has to use that key.

I don't understand the threat model here.  The usual models are
- Key too short - Obvious to the sender
- Recipient's machine is compromised
         - Not obvious to sender, but not fixable by email program
- Recipient is stupid and careless
         - Often obvious to sender, but not fixable by email program
- Recipient's Public Key generator system generates weak keys
         - Hard for sender to detect and work around
         - Usually requires extra work by recipient to obtain
         compromised software, unless mandated by Corporate IT Droids
         - Recipient can reduce risk by using open source software
- Recipient's Public Key generator mails copy of private key to 
keyserver.kgbvax.gov
         - Indistinguishable from previous case
- Recipient's Client Software mails copy of session key to ashcroft.kgbvax.gop
         - Indistinguishable from previous case
- Recipient's Email Client forwards incoming mail message plaintext
         disguised as bouncegrams or viruses.
         - Indistinguishable from previous case.
- Recipient's Secret Key is recipient's dog's name spelled backwards,
         written on yellow sticky note pasted next to open window,
         under the big mirror with a good view of recipient's keyboard and 
screen.
         - Not a software problem
- Recipient's Computer Disk automatically backed up to optical storage at night
         - No sense subpoenaing cyphertext when you can subpoena plaintext.

You're focusing on a relatively niche threat model,
unless there's some operational aspect here I'm missing.

If you wanted to do something fancy, you could insist that the
recipient send the sender a Diffie-Hellmann Half-Key,
which you use to generate a session key that you use for message encryption,
and transmit your DH half-key along with the encrypted message
for the sender to decrypt.  It's still subject to most of the same threats
as the RSA-like public-key model, though maybe it's a bit easier
to detect weak Diffie-Hellmann keys.  However, unless you want to
force the recipient to change their client interface,
the easier place to implement something is in their SMTP client,
and the obvious way to do that is some variant on SSL-SMTP.

If you _still_ want more control, set up a web server,
and instead of sending your actual secret message, send
Encrypt ( Key=Alice, Message="
         ----- BEGIN PGP SIGNED MESSAGE
         Alice - I've sent you an encrypted message at
                 https://bob.example.net/cookie123456.PGP
                 This URL will self-destruct in 5 business days.
                         - Bob
         ----- END PGP SIGNED MESSAGE
         ")

However, if Alice was using a compromised email client,
she could just as easily be using a compromised browser. 


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From egerck at nma.com  Thu Sep 16 20:23:01 2004
From: egerck at nma.com (Ed Gerck)
Date: Thu, 16 Sep 2004 17:23:01 -0700
Subject: public-key: the wrong model for email?
In-Reply-To: <20040916233508.GA22039@lightship.internal.homeport.org>
References: <9F38CF35D80CAE409B979F3EB5242B4A01846669@winex2.campus.tue.nl> <4149574B.800@nma.com> <20040916155434.GG12604@lightship.internal.homeport.org> <4149C990.3020106@systemics.com> <4149E415.9040307@nma.com> <20040916233508.GA22039@lightship.internal.homeport.org>
Message-ID: <414A2E65.5020603@nma.com>

Adam Shostack wrote:

> On Thu, Sep 16, 2004 at 12:05:57PM -0700, Ed Gerck wrote:
> | >Adam Shostack wrote:
> | >
> | >I think the consensus from debate back last year on
> | >this group when Voltage first surfaced was that it
> | >didn't do anything that couldn't be done with PGP,
> | >and added more risks to boot.
> | 
> | Voltage actually does. It allows secure communication
> | without pre-registering the recipient.
> 
> Generate a key for "unknown-recipient at foocorp.com" encrypt mail to
> Bob to that key.  When Bob shows up, decrypt and send over ssl.

How do you know when the right Bob shows up? And...why encrypt? The
email never left your station. Your method is equivalent to: send
anything to Bob at "unknown-recipient at foocorp.com". When Bob shows
up pray he is the right one and send email over ssl. You also have to
run an ssl server (or trust Bob's server key).

With Voltage, you encrypt the email to "unknown-recipient at foocorp.com"
and send it. The sender's work is done[*]. Yes, the other problems still
exist with Voltage.

Cheers,
Ed Gerck

[*] The recipient can decrypt the Voltage email only IF both the sender
and  recipient can refer to the same key generation parameters for the
recipient. This is a problem that I have not seen Voltage discuss. Users
in different or competing administration boundaries will not be able
to communicate with each other in general.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Fri Sep 17 07:58:56 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Fri, 17 Sep 2004 07:58:56 -0400
Subject: Symantec to acquire @Stake
Message-ID: <p06110435bd7081d926de@[66.149.49.5]>

<http://www.siliconvalley.com/mld/siliconvalley/9682511.htm?template=contentModules/printstory.jsp>

The San Jose Mercury News

Posted on Thu, Sep. 16, 2004

Symantec to acquire digital security company




CUPERTINO, Calif. (AP) - Symantec Corp. said Thursday it is acquiring
digital security consulting firm stake Inc.

Financial details were not disclosed. The deal is expected to close next month.

Cupertino, Calif.-based Symantec is one of the world's biggest information
security companies, selling consulting services and software such as the
Norton AntiVirus program. The company does business with individuals and
corporations in more than 35 countries.

Cambridge, Mass.-based stake sells consulting services and computer
programs to protect networks from hackers and other security risks.
Businesses that have purchased the company's SmartRisk and other products
include six of the world's top 10 financial institutions and four of the
world's 10 top independent software companies.

``Our customers are looking to us for a broad range of security
expertise,'' said Gail Hamilton, a Symantec executive vice president. ``By
joining forces with the leader in application security consulting, we
expand the capacity and capabilities of our consulting organization.''

Symantec shares rose 31 cents to close at $51.32 Thursday on the Nasdaq
Stock Market.

------

On the Net:

Symantec: http://www.symantec.com

stake: http://www.atstake.com/




-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From rah at shipwright.com  Fri Sep 17 08:44:37 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Fri, 17 Sep 2004 08:44:37 -0400
Subject: Register: Symantec snags @stake
Message-ID: <p06110488bd708968ec69@[66.149.49.5]>

<http://www.theregister.co.uk/2004/09/17/symantec_buys_atstake/print.html>

The Register


 Biting the hand that feeds IT

The Register ? Business ? Financial News ?

 Original URL: http://www.theregister.co.uk/2004/09/17/symantec_buys_atstake/

Symantec snags @stake
By John Leyden (john.leyden at theregister.co.uk)
Published Friday 17th September 2004 09:51 GMT

IT security giant Symantec yesterday announced an agreement to acquire
security consultancy @stake for an undisclosed amount. Symantec said the
deal, expected to close in October, will allow it to expand its existing
security services and consultancy businesses.

@stake supplies security auditing and analysis products alongside its core
digital security consulting services. Its SmartRisk services address
various aspects of IT security, including application security, critical
infrastructure, wireless and wired networks, storage systems, and
education. @stake's customers include six of the world's top ten financial
institutions, four of the world's top ten independent software companies
and seven of the world's top ten telecommunications carriers. @stake was
founded by members of hacker group l0pht back in 2000.

Symnatec's acquisition of @stake comes after arch rival McAfee bought
application security and consultancy firm Foundstone for $86m last month.
Foundstone competes with @stake, eEye and others in the application
security consultancy biz.

Symantec's purchase of @stake is one of a series of acquisitions by the
company over the last two years or so. In July 2002 it acquired security
consultancy Riptech for $145m cash. More recently it bought anti-spam
specialist Brightmail for $370m. ?


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From iang at systemics.com  Fri Sep 17 10:54:09 2004
From: iang at systemics.com (Ian Grigg)
Date: Fri, 17 Sep 2004 15:54:09 +0100
Subject: How to implement a self-destructing message.
In-Reply-To: <6.0.3.0.0.20040916162226.042a2808@pop.idiom.com>
References: <41488C5D.8050205@nma.com> <6.1.2.0.2.20040915181029.05be2ac0@mail.comcast.net> <41492278.3090303@nma.com> <6.0.3.0.0.20040916162226.042a2808@pop.idiom.com>
Message-ID: <414AFA91.2030609@systemics.com>

Bill Stewart wrote:

> I don't understand the threat model here.  The usual models are
...
> - Recipient's Computer Disk automatically backed up to optical storage at night
>         - No sense subpoenaing cyphertext when you can subpoena plaintext.

In terms of threats actually seen in the real world
leading to costs, etc, I would have thought that the
subpoena / civil / criminal case would be the largest.

In this case, the threat might be something like:

   - Recipient forwards plaintext to someone who
     forwards it to someone who is a threat, where
     the number of links between Recipient and Threat
     are from 0 to many.  Zero means, one year later,
     Recipient becomes threat.
         - Hard for the sender to detect and work around.
         - Could be mitigated by contract provisions,
           such as email clients that automatically
           attach "Confidential" tags on or otherwise
           arrange for emails to be excepted from civil
           proceedings *.
         - Could the email clients use digsigs to
           evidence entry into confidential comms?

As this threat is real, persistent and growing in
popularity, the obsession of perfectly covering more
crypto-savvy threats seems .. unbalanced?

>         ----- BEGIN PGP SIGNED MESSAGE
>         Alice - I've sent you an encrypted message at
>                 https://bob.example.net/cookie123456.PGP
>                 This URL will self-destruct in 5 business days.
>                         - Bob
>         ----- END PGP SIGNED MESSAGE

Ahhhh, now if one could implement a message that self-
destructed on the recipient's machine, that would
start to improve security against the above outlined
threat.  I've toyed with the notion of integrating
contracts negotiation into clients, such that mailers
automatically delete messages agreed earlier to have
a TTL.

But, it seems that even in the chat world, there are
vast numbers of people that routinely save every chat
message / session.  So it needs to be an advisory
negotiation only.  Hence, my thought that if we could
add a contract / in-confidence / without prejudice
label on the message, even if the recipient kept a
copy (via override) then at least it could be locked
out of civil court proceedings *.

iang

*  In some sense or other, if the term "WITHOUT
PREJUDICE" is put on correspondence, that makes it
confidential and protects it from being brought in
to civil proceedings.  Normal IANAL caveats apply.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From lynn at garlic.com  Fri Sep 17 11:11:05 2004
From: lynn at garlic.com (Anne & Lynn Wheeler)
Date: Fri, 17 Sep 2004 09:11:05 -0600
Subject: public-key: the wrong model for email?
In-Reply-To: <20040916233508.GA22039@lightship.internal.homeport.org>
References: <9F38CF35D80CAE409B979F3EB5242B4A01846669@winex2.campus.tue.nl>
 <4149574B.800@nma.com>
 <20040916155434.GG12604@lightship.internal.homeport.org>
 <4149C990.3020106@systemics.com>
 <4149E415.9040307@nma.com>
 <20040916233508.GA22039@lightship.internal.homeport.org>
Message-ID: <6.1.2.0.2.20040917080049.044ec130@mail.comcast.net>

At 05:35 PM 9/16/2004, Adam Shostack wrote:
>Generate a key for "unknown-recipient at foocorp.com" encrypt mail to
>Bob to that key.  When Bob shows up, decrypt and send over ssl.


note there is still the issue of knowing it is bob ... whether before the 
"transmission" or after the "transmission" .... and, in fact, the 
"transmission" itself is somewhat arbitrary.

in the physical world ... the base point is that the sender pays to 
physically transmit something. there is threat model of taking physical 
possession of whatever is being transmitted. they then pay extra for 
countermeasures wrong person taking physical possession. they also pay 
extra for extra care in delivery to the correct person.

the current electronic world ... the base point is that the sender doesn't 
actually pay per transmission. with encryption, the threat model is changed 
to possession of the unencrypted information. encryption (shared-secret or 
digital signatures) is also used to help with the issue of "delivery" to 
the correct person (although the convention is converted to the correct 
person decrypts the data).

so what is the difference between the sender setting up facility so that 
"when bob shows up" .... bob gets a decrypted version .... and say sending 
a version to some trusted 3rd party that is encrypted with the 3rd party's 
key ... and direction to only let bob have it when bob shows up. how does 
the 3rd party know its bob ... any better than the originating sender? note 
also in standard ssl ... the recipient generates a random symmetric key and 
sends it to the server, encrypted with the server's public key. there is 
nothing about how the server knows that the bob making the contact ... and 
the bob that is suppose to receive the information .... is the same entity.

so the 3rd party keeps the pre-transmitted encrypted stuff with directions 
to only give it to any entity that shows the magic something (the movie 
stuff about tearing a bill in half and the person needs to have the 
appropriate torn half).  the 3rd party holds it until bob contacts the 
sender and gets the magic something ... which they they can give to the 3rd 
party. given the nature of electronic transmission ... is that really 
substantially different than the sender waiting until bob contacts them 
before doing the original transmission.

if it is purely electronic world ... how does the sender get the necessary 
information to the correct bob ... so that the correct bob can give the 
stuff to the 3rd party ... to proove that they are the correct bob.

so possibly the only distinction ... is that the email communication 
between bob and the sender is non-real-time ... and the SSL communication 
is considered possibly real-time .... so the scenario isn't actually the 
information being transmitted between the sender and bob that is the issue 
... it is possibly the mechanics of real-time vis-a-vis non-realtime?

so the sender at some point has to trust bob's authentication information 
(whether directly and/or outsourced to 3rd party) ... say digital signature 
public key and may or may not trust that same key for encryption.

common pgp flow ... which effectively is the same as ssl ....  same process 
steps ... but possibly not in real time. sender looks up in some directory 
the contact information for bob,
this directory is trusted to map the contact process for bob to bob .... 
the directory may or may not also provide some authentication information 
for bob.  if the sender doesn't have authentication information for bob ... 
they send message to bob requesting authentication information. when they 
get that back, they vet the authentication information before using it to 
make sure it is actually for bob. so now they have a process which has some 
assurance of contacting bob and some assurance that bob can be authenticated.
this is pretty much true whether the actual sender is responsible for the 
steps or has been outsourced to some 3rd party.

now the issue is wether or not the authentication information is also 
trusted to securely protect the classified information during transmission 
(aka public key).  possible scenario if sender  requires different 
encryption keys from authentication information:

1) sender sends message to bob saying classifed document is waiting. bob 
generates secret key, digitally signs it, encrypts it with the senders 
public key and returns it to the sender. this could be all email exchange 
... or possibly combination of email and ssl .... it could also be directly 
with the sender or a 3rd party agent on the sender's behalf.

2) the sender decrypts bob's message, validates the digital signature, 
encrypts the classified information with bob's secret key and sends the 
information to bob. the sender's process can be email or ssl ... and can 
either directly be the sender ... or a 3rd party acting on the sender's behalf.

for efficiency purposes .... the acquisition of bob's authentication 
information and possible encryption key might be collapsed into single 
round trip. sender (or 3rd party on sender's behalf) send bob a message 
that they need both bob's authentication information .... as well as a 
digitally signed, randomly generated secret key ... which is encrypted with 
the supplied public key. the sender/3rd party then has to vet bob's 
authentication information .... before using the randomly generated secret 
key. again, the exchange could be purely non-real-time email .... or 
combination of email and real-time ssl.

sort of practical issues:

given that the electronic paradigm have enuf differences from the physical 
world sending model (i.e. sender doesn't pay in the base case) .... can 
sender's be induced to pay 3rd party to outsource some of the operations?

given that the there are some number of other vulnerabilities and exploits 
in the overall infrastructure .... is the treat model specifically to 
trusting bob's public key for both authentication and confidential 
transmission .... sufficient to impose the extra processes (and/or convince 
sender's that they need to pay extra money for outsourcing to 3rd parties).

since the paradigm issue of securely transmitted has changed from secure 
physical movement to safe encryption .... a 3rd party may only have to 
provide a business of assuring recipients'  public keys for "safe" 
transmission (as opposed to actually doing the transmission). everybody 
gets to generate their own public/private key pair for authentication. the 
same key pair is not used for both authentication and encryption. people 
may also generate their own encryption key pair.

senders either trust a recipient's encryption key pair ... or they don't. 
if the sender doesn't trust a recipient's encryption key pair .... they ask 
for a encryption public key that has been issued by a trusted 3rd party ... 
and for which the 3rd party is willing to attest to. there is an issue of 
how the issued private key has gotten to the recipient ... but that isn't a 
whole lot of difference than the process of a recipient exchanging a real 
secret key for transmission. there is an issue of whether or not the 
recipient has continued to protect the encryption private key .... but that 
isn't a whole lot difference than whether or not the recipient has the 
facility to protect the unencrypted classified document (once they receive it).

the physical world has the sender outsourcing and paying for the actual 
secure physical movement .... and some assurance that it only goes to the 
intended recipient. translated to the electronic world ... the paradigm has 
been changed to the use of encryption to make sure wrong people don't have 
the unencrypted version ... and various kinds of authentication processes. 
so the critical processes has changed not from the actual movement of the 
data ... but the encryption process "gatekeepers" .... aka the integrity 
and management of keys used for authentication and decryption. so rather 
than focus on the actual electronic transmission processes .... focus on 
the issues related to the keys.

--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/ 


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From lynn at garlic.com  Fri Sep 17 11:11:05 2004
From: lynn at garlic.com (Anne & Lynn Wheeler)
Date: Fri, 17 Sep 2004 09:11:05 -0600
Subject: public-key: the wrong model for email?
In-Reply-To: <20040916233508.GA22039@lightship.internal.homeport.org>
References: <9F38CF35D80CAE409B979F3EB5242B4A01846669@winex2.campus.tue.nl>
 <4149574B.800@nma.com>
 <20040916155434.GG12604@lightship.internal.homeport.org>
 <4149C990.3020106@systemics.com>
 <4149E415.9040307@nma.com>
 <20040916233508.GA22039@lightship.internal.homeport.org>
Message-ID: <6.1.2.0.2.20040917080049.044ec130@mail.comcast.net>

At 05:35 PM 9/16/2004, Adam Shostack wrote:
>Generate a key for "unknown-recipient at foocorp.com" encrypt mail to
>Bob to that key.  When Bob shows up, decrypt and send over ssl.


note there is still the issue of knowing it is bob ... whether before the 
"transmission" or after the "transmission" .... and, in fact, the 
"transmission" itself is somewhat arbitrary.

in the physical world ... the base point is that the sender pays to 
physically transmit something. there is threat model of taking physical 
possession of whatever is being transmitted. they then pay extra for 
countermeasures wrong person taking physical possession. they also pay 
extra for extra care in delivery to the correct person.

the current electronic world ... the base point is that the sender doesn't 
actually pay per transmission. with encryption, the threat model is changed 
to possession of the unencrypted information. encryption (shared-secret or 
digital signatures) is also used to help with the issue of "delivery" to 
the correct person (although the convention is converted to the correct 
person decrypts the data).

so what is the difference between the sender setting up facility so that 
"when bob shows up" .... bob gets a decrypted version .... and say sending 
a version to some trusted 3rd party that is encrypted with the 3rd party's 
key ... and direction to only let bob have it when bob shows up. how does 
the 3rd party know its bob ... any better than the originating sender? note 
also in standard ssl ... the recipient generates a random symmetric key and 
sends it to the server, encrypted with the server's public key. there is 
nothing about how the server knows that the bob making the contact ... and 
the bob that is suppose to receive the information .... is the same entity.

so the 3rd party keeps the pre-transmitted encrypted stuff with directions 
to only give it to any entity that shows the magic something (the movie 
stuff about tearing a bill in half and the person needs to have the 
appropriate torn half).  the 3rd party holds it until bob contacts the 
sender and gets the magic something ... which they they can give to the 3rd 
party. given the nature of electronic transmission ... is that really 
substantially different than the sender waiting until bob contacts them 
before doing the original transmission.

if it is purely electronic world ... how does the sender get the necessary 
information to the correct bob ... so that the correct bob can give the 
stuff to the 3rd party ... to proove that they are the correct bob.

so possibly the only distinction ... is that the email communication 
between bob and the sender is non-real-time ... and the SSL communication 
is considered possibly real-time .... so the scenario isn't actually the 
information being transmitted between the sender and bob that is the issue 
... it is possibly the mechanics of real-time vis-a-vis non-realtime?

so the sender at some point has to trust bob's authentication information 
(whether directly and/or outsourced to 3rd party) ... say digital signature 
public key and may or may not trust that same key for encryption.

common pgp flow ... which effectively is the same as ssl ....  same process 
steps ... but possibly not in real time. sender looks up in some directory 
the contact information for bob,
this directory is trusted to map the contact process for bob to bob .... 
the directory may or may not also provide some authentication information 
for bob.  if the sender doesn't have authentication information for bob ... 
they send message to bob requesting authentication information. when they 
get that back, they vet the authentication information before using it to 
make sure it is actually for bob. so now they have a process which has some 
assurance of contacting bob and some assurance that bob can be authenticated.
this is pretty much true whether the actual sender is responsible for the 
steps or has been outsourced to some 3rd party.

now the issue is wether or not the authentication information is also 
trusted to securely protect the classified information during transmission 
(aka public key).  possible scenario if sender  requires different 
encryption keys from authentication information:

1) sender sends message to bob saying classifed document is waiting. bob 
generates secret key, digitally signs it, encrypts it with the senders 
public key and returns it to the sender. this could be all email exchange 
... or possibly combination of email and ssl .... it could also be directly 
with the sender or a 3rd party agent on the sender's behalf.

2) the sender decrypts bob's message, validates the digital signature, 
encrypts the classified information with bob's secret key and sends the 
information to bob. the sender's process can be email or ssl ... and can 
either directly be the sender ... or a 3rd party acting on the sender's behalf.

for efficiency purposes .... the acquisition of bob's authentication 
information and possible encryption key might be collapsed into single 
round trip. sender (or 3rd party on sender's behalf) send bob a message 
that they need both bob's authentication information .... as well as a 
digitally signed, randomly generated secret key ... which is encrypted with 
the supplied public key. the sender/3rd party then has to vet bob's 
authentication information .... before using the randomly generated secret 
key. again, the exchange could be purely non-real-time email .... or 
combination of email and real-time ssl.

sort of practical issues:

given that the electronic paradigm have enuf differences from the physical 
world sending model (i.e. sender doesn't pay in the base case) .... can 
sender's be induced to pay 3rd party to outsource some of the operations?

given that the there are some number of other vulnerabilities and exploits 
in the overall infrastructure .... is the treat model specifically to 
trusting bob's public key for both authentication and confidential 
transmission .... sufficient to impose the extra processes (and/or convince 
sender's that they need to pay extra money for outsourcing to 3rd parties).

since the paradigm issue of securely transmitted has changed from secure 
physical movement to safe encryption .... a 3rd party may only have to 
provide a business of assuring recipients'  public keys for "safe" 
transmission (as opposed to actually doing the transmission). everybody 
gets to generate their own public/private key pair for authentication. the 
same key pair is not used for both authentication and encryption. people 
may also generate their own encryption key pair.

senders either trust a recipient's encryption key pair ... or they don't. 
if the sender doesn't trust a recipient's encryption key pair .... they ask 
for a encryption public key that has been issued by a trusted 3rd party ... 
and for which the 3rd party is willing to attest to. there is an issue of 
how the issued private key has gotten to the recipient ... but that isn't a 
whole lot of difference than the process of a recipient exchanging a real 
secret key for transmission. there is an issue of whether or not the 
recipient has continued to protect the encryption private key .... but that 
isn't a whole lot difference than whether or not the recipient has the 
facility to protect the unencrypted classified document (once they receive it).

the physical world has the sender outsourcing and paying for the actual 
secure physical movement .... and some assurance that it only goes to the 
intended recipient. translated to the electronic world ... the paradigm has 
been changed to the use of encryption to make sure wrong people don't have 
the unencrypted version ... and various kinds of authentication processes. 
so the critical processes has changed not from the actual movement of the 
data ... but the encryption process "gatekeepers" .... aka the integrity 
and management of keys used for authentication and decryption. so rather 
than focus on the actual electronic transmission processes .... focus on 
the issues related to the keys.

--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/ 


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From crypto at ovillatx.sytes.net  Fri Sep 17 12:29:01 2004
From: crypto at ovillatx.sytes.net (lrk)
Date: Fri, 17 Sep 2004 11:29:01 -0500
Subject: public-key: the wrong model for email?
In-Reply-To: <6.0.3.0.0.20040916162226.042a2808@pop.idiom.com>
References: <41488C5D.8050205@nma.com> <6.1.2.0.2.20040915181029.05be2ac0@mail.comcast.net> <41492278.3090303@nma.com> <6.0.3.0.0.20040916162226.042a2808@pop.idiom.com>
Message-ID: <20040917162901.GA245@ovillatx.sytes.net>

On Thu, Sep 16, 2004 at 04:57:39PM -0700, Bill Stewart wrote:
> At 10:19 PM 9/15/2004, Ed Gerck wrote:
> >Yes, PKC provides a workable solution for key distribution... when you
> >look at servers. For email, the PKC solution is not workable (hasn't been)
> >and gives a false impression of security. For example, the sender has no
> >way of knowing if the recipient's key is weak (in spite of its length)
> >or has some "key-access" feature. Nonetheless, the sender has to use that 
> >key.
> 
> I don't understand the threat model here.

That seems to be the actual problem. If you want real security, you need a
vault, guards, cryptographers, and do the crypto in the vault.

I use GnuPG so my e-mail is in an "envelope" rather than on a "postcard".
If the fedz want to read it they bring guns, slammers, and rubber hoses
anyway.


Perhaps it is time to define an e-mail definition of crypto to keep the
"postman" from reading the "postcards". That should be easy enough to
implement for the average user and provide some degree of privacy for
their mail. Call it "envelopes" rather than "crypto". Real security 
requires more than a Windoz program.


-- 
crypto at ovillatx.sytes.net

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Fri Sep 17 14:35:09 2004
From: iang at systemics.com (Ian Grigg)
Date: Fri, 17 Sep 2004 19:35:09 +0100
Subject: public-key: the wrong model for email?
In-Reply-To: <20040917162901.GA245@ovillatx.sytes.net>
References: <41488C5D.8050205@nma.com> <6.1.2.0.2.20040915181029.05be2ac0@mail.comcast.net> <41492278.3090303@nma.com> <6.0.3.0.0.20040916162226.042a2808@pop.idiom.com> <20040917162901.GA245@ovillatx.sytes.net>
Message-ID: <414B2E5D.1060306@systemics.com>

lrk wrote:

> Perhaps it is time to define an e-mail definition of crypto to keep the
> "postman" from reading the "postcards". That should be easy enough to
> implement for the average user and provide some degree of privacy for
> their mail. Call it "envelopes" rather than "crypto". Real security 
> requires more than a Windoz program.

Oh, that's really easy.  Each mailer (MUA) should (on
install) generate a self-signed cert.  Stick the fingerprint
in the headers of every mail going out.  An MUA that sees
the fingerpring in an incoming mail can send a request email
to acquire the full key.  Or stick the entire cert in there,
it's not as if anyone would care.

Then each MUA can start encrypting to that key opportunistically.

Lots of variations.  But the key thing is that the MUA
should simply generate the key, sign it, and send it out
on demand, or more freuqently.  There's really no reason
why this can't all be automated.  After all, the existing
email system is automated, and trusted well enough to
deliver email, so why can't it deliver self-signed certs?

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Fri Sep 17 14:18:50 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Fri, 17 Sep 2004 14:18:50 -0400
Subject: [Openswan dev] [Announce] Openswan 2.2.0 released
Message-ID: <p061104e7bd70db030dc4@[66.149.49.5]>


--- begin forwarded text


Date: Fri, 17 Sep 2004 17:48:25 +0200 (MET DST)
From: Paul Wouters <paul at xelerance.com>
To: announce at openswan.org
Subject: [Openswan dev] [Announce] Openswan 2.2.0 released
List-Id: Openswan developer mailinglist <dev.openswan.org>
List-Archive: <http://lists.openswan.org/pipermail/dev>
List-Post: <mailto:dev at openswan.org>
List-Help: <mailto:dev-request at openswan.org?subject=help>
List-Subscribe: <http://lists.openswan.org/mailman/listinfo/dev>,
	<mailto:dev-request at openswan.org?subject=subscribe>
Sender: dev-bounces at openswan.org


Xelerance is proud to release Openswan 2.2.0

It is available at the usual locations:

http://www.openswan.org/code/openswan-2.2.0.tar.gz
ftp://ftp.openswan.org/openswan/openswan-2.2.0.tar.gz

A seperate NAT-traversal patch and seperate KLIPS patch are available as well.

RPMS have been released for RedHat-9, Fedora Core 2 and 3-test1, RHEL3 and
Suse 9.1.  (RedHat-9 still requires KLIPS support in the kernel).

All released files have been signed with the build at openswan.org GPG key
available from the keyservers.

The following are the most important changes:

* Added RFC 3706 DPD support (see README.DPD)
* Added AES from JuanJo's ALG patches
* Fixes for /proc filesystem issues that started to appear in 2.4.25
* Merge X.509 1.5.4 + latest security fixes (CAN-2004-0590)
* Updated .spec for building RPMS compatible with Kernel 2.6
* Merge X.509 security fixes from 1.6.3
* Fixes for NAT-T on 2.6 pulled up from 2.1.x (Herbert Xu)
* Fixes for SA Selectors on 2.6 pulled up from 2.1.x (Herbert Xu)

Bugs can be reported via http://bugs.openswan.org/ or via one of the mailing
lists at http://lists.openswan.org/

Paul
_______________________________________________
Announce mailing list
Announce at openswan.org
http://lists.openswan.org/mailman/listinfo/announce
_______________________________________________
Dev mailing list
Dev at openswan.org
http://lists.openswan.org/mailman/listinfo/dev

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From egerck at nma.com  Fri Sep 17 15:42:29 2004
From: egerck at nma.com (Ed Gerck)
Date: Fri, 17 Sep 2004 12:42:29 -0700
Subject: public-key: the wrong model for email?
In-Reply-To: <6.0.3.0.0.20040916162226.042a2808@pop.idiom.com>
References: <41488C5D.8050205@nma.com> <6.1.2.0.2.20040915181029.05be2ac0@mail.comcast.net> <41492278.3090303@nma.com> <6.0.3.0.0.20040916162226.042a2808@pop.idiom.com>
Message-ID: <414B3E25.6060402@nma.com>

Bill Stewart wrote:

> At 10:19 PM 9/15/2004, Ed Gerck wrote:
> 
>> Yes, PKC provides a workable solution for key distribution... when you
>> look at servers. For email, the PKC solution is not workable (hasn't 
>> been)
>> and gives a false impression of security. For example, the sender has no
>> way of knowing if the recipient's key is weak (in spite of its length)
>> or has some "key-access" feature. Nonetheless, the sender has to use 
>> that key.
> 
> 
> I don't understand the threat model here.  The usual models are
 > ...

Good list, even though missing some points that are important here,
mentioned below.

The disclosure threat is that the message may be disclosed AFTER it is
decrypted (this may happen even without the recipient being at fault).
I am NOT talking about the disclosure threat. Except for the disclosure
threat, the threat model includes anything that is not under control
or cannot be directly verified by the sender.

The obvious strategy for the sender is to trust the least possible
(ideally, nothing) regarding message security.

Public-key encryption for email makes this difficult from the start.
With all the public-key fancy foot work (eg, CA certs, CRL, OCSP, etc.),
the sender still has to trust the public-key generated by the recipient
regarding its basic property to encrypt messages that can only be
decrypted by the recipient when the message arrives.

Yes, the sender can do a challenge-response using that key and confirm
that the recipient has the private-key. But what the sender does not
have, and cannot have, is any assurance that his messages are only
decryptable by the recipient. The sender has no way of knowing if the
recipient's public-key is weak (in spite of its great length), or has
some "key-access" feature, or bug, or has been revoked in the mean
time [1]. Trusting the recipient helps but the recipient may not even
know it (in spite of the recipient's best efforts).

This problem also affects SSH and anything that uses public-key crypto,
including smart-card generated keys. For email, however, it can break
message security in spite of the sender's and recipient's best efforts.

Since the sender is the party who bears most, if not all, the risk, my
question was whether email security could benefit by using a different
model. Public-key crypto could still be used, but possibly not as it
is today. Again, the problem is both technical and business-wise.

> If you _still_ want more control, set up a web server,
> and instead of sending your actual secret message, send
> Encrypt ( Key=Alice, Message="
>         ----- BEGIN PGP SIGNED MESSAGE
>         Alice - I've sent you an encrypted message at
>                 https://bob.example.net/cookie123456.PGP
>                 This URL will self-destruct in 5 business days.
>                         - Bob
>         ----- END PGP SIGNED MESSAGE
>         ")

The attacker could read the first message and download the second message.
It could make it detectable, though (but not necessarily traceable).

Cheers,
Ed Gerck

[1] The security fault happens when you (in spite of all your best efforts) send
an email message using a public-key that is revoked (eg, because the private-key was
compromised) at the time the message is received, due to various delays such as in
message transport, certificate revocation, and compromise discovery. You simply have
no way of knowing, even if the key was not listed in a CRL at the very second you
sent the message, whether the key has not been compromised at the time the message
is received. It gets worse. If the private-key is compromised any time after the
message is sent, the message can be decrypted from a cache copy somewhere -- even
if the recipient keeps the decrypted copy safe.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From eugen at leitl.org  Fri Sep 17 16:28:51 2004
From: eugen at leitl.org (Eugen Leitl)
Date: Fri, 17 Sep 2004 22:28:51 +0200
Subject: public-key: the wrong model for email?
Message-ID: <20040917202851.GG1457@leitl.org>

On Fri, Sep 17, 2004 at 07:35:09PM +0100, Ian Grigg wrote:

> Oh, that's really easy.  Each mailer (MUA) should (on
> install) generate a self-signed cert.  Stick the fingerprint

apt-get install postfix-tls

Allright, this still doesn't generate the certs, nor reference them in the
main.cf.

> in the headers of every mail going out.  An MUA that sees
> the fingerpring in an incoming mail can send a request email
> to acquire the full key.  Or stick the entire cert in there,
> it's not as if anyone would care.

I would cache the cert fingerprints, and log when those change.
 
> Then each MUA can start encrypting to that key opportunistically.

Start/TLS does encrypt my mail far more often the PGP/GPG.
 
> Lots of variations.  But the key thing is that the MUA
> should simply generate the key, sign it, and send it out
> on demand, or more freuqently.  There's really no reason
> why this can't all be automated.  After all, the existing
> email system is automated, and trusted well enough to
> deliver email, so why can't it deliver self-signed certs?

Talk to Exim/Postfix maintainers. They should ship self-signed cert Start/TLS
config out of the box. Even without cert caching, that'd require a MITM.
Not exactly cheap, and prone to detection, if practiced on a nonnegligible
scale (fingerprint checking).

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net




----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20040917/9eed5df9/attachment.pgp>

From smb at research.att.com  Fri Sep 17 20:41:56 2004
From: smb at research.att.com (Steven M. Bellovin)
Date: Fri, 17 Sep 2004 20:41:56 -0400
Subject: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org) (fwd from touch@ISI.EDU) 
In-Reply-To: Your message of "Thu, 16 Sep 2004 00:41:41 BST."
             <4148D335.4010207@systemics.com> 
Message-ID: <20040918004156.5C71E1AE7E@berkshire.research.att.com>

In message <4148D335.4010207 at systemics.com>, Ian Grigg writes:
>Peter Gutmann wrote:
>> "Steven M. Bellovin" <smb at research.att.com> writes:
>>>>Maybe it's worth doing some sort of generic RFC for this security model to
>>>>avoid scattering the same thing over a pile of IETF WGs, 
>>>
>>>Sounds good.  Who wants to write it...?
>> 
>> Since there seems to be at least some interest in this, I'll make a start on
>> it.  If anyone else wants to add their $0.03 to it [0], let me know.
>
>It occurs to me that a number of these ideas could
>be written up over time ... a wiki, anyone?  I think
>it is high past time to start documenting crypto
>patterns.
>

For RFCs, there are two paths.  If the topic is general enough (and, of 
course, the advice is good enough), Russ Housley or I would consider 
sponsoring the document as a BCP.  If it's narrow or we're not 
interested for some reason (other than quality, of course), it could be 
an individual submission.  I encourage both paths.

		--Steve Bellovin, http://www.research.att.com/~smb



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From bill.stewart at pobox.com  Fri Sep 17 13:00:09 2004
From: bill.stewart at pobox.com (Bill Stewart)
Date: Fri, 17 Sep 2004 10:00:09 -0700
Subject: How to implement a self-destructing message.
In-Reply-To: <414AFA91.2030609@systemics.com>
References: <41488C5D.8050205@nma.com>
 <6.1.2.0.2.20040915181029.05be2ac0@mail.comcast.net>
 <41492278.3090303@nma.com>
 <6.0.3.0.0.20040916162226.042a2808@pop.idiom.com>
 <414AFA91.2030609@systemics.com>
Message-ID: <20040918054139.799ADF294@red.metdow.com>

At 07:54 AM 9/17/2004, Ian Grigg wrote:
>Ahhhh, now if one could implement a message that self-
>destructed on the recipient's machine, that would
>start to improve security against the above outlined
>threat.  I've toyed with the notion of integrating
>contracts negotiation into clients, such that mailers
>automatically delete messages agreed earlier to have a TTL.

That's been done, by "Disappearing Inc".
www.disappearing.com/  says they're now owned by Omniva.

The proprietor gave a talk at a Cypherpunks meeting some years ago,
after they'd done a big Scannelly splash in USA Today.
He started out by identifying the problem he was trying to solve,
which is for routine document destruction -
a cooperating sender and receiver want to know
that their message will disappear after some time
if neither of them tries to make other copies or work around the system;
the problem of making a truly non-copyable system is snake oil
that he wasn't going to try to sell.

The system creates a session key and a cookie,
which it sends to a policy server,
encrypts the message with the session key,
and includes the cookie and encrypted message in the email.

The recipient's mail client handles and stores the encrypted message,
and when the recipient wants to read it,
he runs a Disappearing Inc. crypto client which
sends the cookie to the policy server, gets the session key,
and decrypts the mail in a viewer program.

After whatever timeout the sender specifies,
the policy server deletes the key and cookie,
so the recipient can no longer decrypt the message.
Originally the business model was that Disappearing Inc.
ran the policy server, and it was accessible using https or whatever,
but they later also started selling servers to customers.

The system obviously doesn't stop the recipient from
screen-scraping the message (don't remember if it supported cut&paste),
but it's designed for the Ollie North problem
         "What do you mean the email system backs up all messages
         on optical disk?  I thought I deleted the evidence!"
or the business equivalent (anti-trust suit wants all your
correspondence from the last 17 years.)

It's not a perfect system - courts can order the policy server
not to delete any data, for instance - but any data that
has been deleted before then has really been deleted,
assuming the policy server's disk isn't also backed up on optical.
And Ed Gerck gets to know that his message was transmitted
with adequate encryption under control of the sender.




----
Bill Stewart  bill.stewart at pobox.com 


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From hadmut at danisch.de  Sat Sep 18 03:04:54 2004
From: hadmut at danisch.de (Hadmut Danisch)
Date: Sat, 18 Sep 2004 09:04:54 +0200
Subject: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org) (fwd from touch@ISI.EDU)
In-Reply-To: <4148D335.4010207@systemics.com>
References: <E1C6uKH-0008Ou-00@medusa01> <4148D335.4010207@systemics.com>
Message-ID: <20040918070454.GA1261@danisch.de>

On Thu, Sep 16, 2004 at 12:41:41AM +0100, Ian Grigg wrote:
> 
> It occurs to me that a number of these ideas could
> be written up over time ... a wiki, anyone?  I think
> it is high past time to start documenting crypto
> patterns.

Wikis are not that good for discussions, and I do believe
that this requires some discussion.

I'd propose a separate mailing list for that.

regards
Hadmut

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From ben at algroup.co.uk  Sat Sep 18 09:54:42 2004
From: ben at algroup.co.uk (Ben Laurie)
Date: Sat, 18 Sep 2004 14:54:42 +0100
Subject: public-key: the wrong model for email?
In-Reply-To: <4149E13C.7060102@nma.com>
References: <41488C5D.8050205@nma.com> <6.1.2.0.2.20040915181029.05be2ac0@mail.comcast.net> <41492278.3090303@nma.com> <6.1.2.0.2.20040916102815.04395c70@mail.comcast.net> <4149E13C.7060102@nma.com>
Message-ID: <414C3E22.2010306@algroup.co.uk>

Ed Gerck wrote:
> 
> Anne & Lynn Wheeler wrote:
> 
>  > the issue then is what level do you trust the recipient, what is the
> 
>> threat model, and what are the countermeasures.
>>
>> if there is a general trust issue with the recipient (not just their 
>> key generating capability) ... then a classified document compromise 
>> could happen after it has been transmitted. you may have to do a 
>> complete audit & background check of the recipient before any 
>> distribution of classified document.
> 
> 
> If the recipient cannot in good faith detect a key-access ware, or a
> GAK-ware, or a Trojan, or a bug, why would a complete background
> check of the recipient help?

Let's assume for a moment that a solution exists that satisfies your 
requirements. Since the recipient _must_ be able to read the document in 
the end, and is assumed to be incapable of securing their software, then 
the document is still available to third parties without the consent of 
the sender, is it not?

It seems to me that fixing the PK "problem" would in no way improve the 
senders situation given that threat model.

Cheers,

Ben.

-- 
ApacheCon! 13-17 November! http://www.apachecon.com/

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"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 majordomo at metzdowd.com


From lynn at garlic.com  Sat Sep 18 12:19:20 2004
From: lynn at garlic.com (Anne & Lynn Wheeler)
Date: Sat, 18 Sep 2004 10:19:20 -0600
Subject: public-key: the wrong model for email?
In-Reply-To: <4149E13C.7060102@nma.com>
References: <41488C5D.8050205@nma.com>
 <6.1.2.0.2.20040915181029.05be2ac0@mail.comcast.net>
 <41492278.3090303@nma.com>
 <6.1.2.0.2.20040916102815.04395c70@mail.comcast.net>
 <4149E13C.7060102@nma.com>
Message-ID: <6.1.2.0.2.20040918101032.060d7710@mail.comcast.net>

At 12:53 PM 9/16/2004, Ed Gerck wrote:
>If the recipient cannot in good faith detect a key-access ware, or a
>GAK-ware, or a Trojan, or a bug, why would a complete background
>check of the recipient help?

a "complete audit and background check" ... would include an audit of the 
recipient ... not just the recipient person .... but the recipient ... as 
in the recipient operation.

so given sufficient sender concern, checking might be similar to something 
that the federal reserve has specified for a fedwire terminal .... although 
the announcement about allowing fedwire access via the internet has raised 
some eyebrows. i'm sure that such things don't happen .... but could all 
the stuff about swift providing internet-oriented services been some 
motivation?

the issue for the sender is that they could be concerned about a number of 
different possible vulnerabilities ... and complete audit and background 
check would be to try and cover all the bases ... aka the leakage of a 
classified document wouldn't solely be restricted to technical subversion.

--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/ 


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Sat Sep 18 11:22:40 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Sat, 18 Sep 2004 11:22:40 -0400
Subject: They Said It Couldn't Be Done
Message-ID: <p061104abbd7203207609@[66.149.49.5]>

<http://www.nytimes.com/2004/09/18/opinion/18sat2.html?th=&pagewanted=print&position=>

The New York Times
September 18, 2004

They Said It Couldn't Be Done
any computer scientists insist that electronic voting machines will be
trustworthy only when they produce paper receipts that can be audited. But
supporters of electronic voting have long argued that doing so would be
extremely difficult, if not impossible. Nevada proved the naysayers wrong
this month, running the first statewide election in which electronic voting
machines produced paper records of votes cast. Election officials across
the country now have no excuse not to provide systems that voters can trust.

There is a growing body of evidence indicating that electronic voting
machines are vulnerable to tampering and to software glitches that can skew
the vote totals. The best safeguard is a voter-verifiable paper trail,
receipts that are printed out during the voting process. Voters can view
the receipts to check them against the choices they made on the computer
screens. Each receipt remains under glass and, after the vote is cast,
falls into a locked box. The receipts can be used in a recount or an audit
to check the accuracy of the machine tallies.

 The main argument against voter-verifiable paper trails is that they are
impractical. At a May meeting of the federal Election Assistance
Commission, and again at the National Association of State Election
Directors' summer conference, local election officials denounced the
campaign for voter-verifiable paper records. At both events, critics waved
a receipt about three feet long, saying one that big would be needed for
Los Angeles County's lengthy ballot.

But Nevada's secretary of state, Dean Heller, has always believed that
paper records are practical, and this month he proved it. Primary voters
across the state cast votes on machines that printed out paper records, and
none of the nightmarish possibilities came to pass. The poll workers had no
trouble with the technology. And election officials had spare machines and
printers on hand in the few cases when printers jammed or had other
mechanical problems.

 Conditions in Nevada favored success. The turnout was light, and the
ballot was short enough that the receipt was only about five inches long.
But there is no reason to believe that paper trails could not work in any
election. Alfred Charles, a vice president of Sequoia Voting Systems, which
made the machines used in Nevada, says that if the receipts are done
properly, listing only the candidates and referendum choices that the voter
actually selects, length should not be a problem, and it is unlikely that
even Los Angeles County would require anything like three-foot-long paper
receipts.

Even if Nevada's approach - attaching printers to touch-screen machines -
had failed, there would still be other ways to provide a paper record.
Probably the best solution is the optical scan system used now in many
jurisdictions, where voters mark paper ballots that are then read by
computers. In optical scan systems, the paper ballots the voters fill out
can be retained and used as a check against the machines' tallies.

Nevada has taken the lead on paper trails not only in its own elections,
but also in Congress. Its senators - John Ensign, a Republican, and Harry
Reid, a Democrat - have co-sponsored the bipartisan Voting Integrity and
Verification Act, one of a number of pending bills that would require that
all electronic voting machines produce voter-verifiable paper trails.
Congress should pass such legislation right away so all Americans can have
the same confidence in their elections as Nevadans now have.

Copyrigh
-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From rah at shipwright.com  Sat Sep 18 19:41:13 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Sat, 18 Sep 2004 19:41:13 -0400
Subject: The Hand-Marked Ballot Wins for Accuracy
Message-ID: <p06110400bd7277f9d963@[66.149.49.5]>

<http://nytimes.com/2004/09/19/politics/campaign/19ballot.html?pagewanted=print&position=>

The New York Times

September 19, 2004

The Hand-Marked Ballot Wins for Accuracy
By TOM ZELLER Jr.

fter the pandemonium over dimpled and pregnant chads in the 2000 election,
nearly everyone agreed it was time to rethink old vote-counting ways. But
the stampede to touch-screen voting was not inevitable.

 Another, demonstrably more reliable technology was already on the rise:
optical scan voting, introduced in some parts of the country in the late
1970's. By the 2000 election, optical scanning - which involves marking a
paper ballot that is ultimately read and counted by a computer - had
overtaken all other voting methods as the most common way to vote in the
United States. This year, optical scan systems will be used in more than 45
percent of all counties, according to Election Data Services, a political
consulting firm in Washington.

 After the 2000 election, a study by the Voting Technology Project, a joint
effort by the California Institute of Technology and the Massachusetts
Institute of Technology, took a hard look at the nation's voting systems.
Using a measure of what they called "residual votes" - overcounting,
undercounting or not counting votes for any reason - researchers found that
two existing voting methods had produced relatively low error rates in the
last four presidential elections: old-fashioned hand-counted paper ballots
and optical scan systems.

 The study found that the mechanical lever system, which dominated the
market in 1980 and has been in decline ever since, performed considerably
worse. In overall performance, electronic voting - both the older
push-button variety and the newer touch-screen units - performed scarcely
better than punch cards.

 "The immediate implication of our analysis is that the U.S. can lower the
number of lost votes in 2004 by replacing punch cards and lever machines
with optical scanning," the report said. "Touch screens are, in our
opinion, still unproven."

 But election officials who decided to change systems overwhelmingly went
for the touch screens. Compared with about 13 percent of registered voters
in 2000, this year roughly 30 percent of those registered will be asked to
vote on electronic systems. Optical scan systems grew as well, although at
a much slower pace: from about 30 percent of registered voters in 2000 to
just under 35 percent this year, according to Election Data Services.

 The Caltech/M.I.T. study said that the newest electronic systems had great
potential, but were plagued by a variety of problems, like loose cables and
confusing interfaces.

 Change is natural, said Stephen Ansolabehere, a political science
professor at M.I.T. and a member of the study team. But "optical scanning
is a pretty good interim solution for the next five or 10 years,'' he said.

And then what? Litigators, start your engines: the Internet.

Professor Ansolabehere is among those who predict that myriad security
obstacles will one day be overcome and votes will be cast from the nation's
living rooms.

 "I think it's inevitable," he said.

 Copyrigh
-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From egerck at nma.com  Sat Sep 18 20:29:19 2004
From: egerck at nma.com (Ed Gerck)
Date: Sat, 18 Sep 2004 17:29:19 -0700
Subject: public-key: the wrong model for email?
In-Reply-To: <414C3E22.2010306@algroup.co.uk>
References: <41488C5D.8050205@nma.com> <6.1.2.0.2.20040915181029.05be2ac0@mail.comcast.net> <41492278.3090303@nma.com> <6.1.2.0.2.20040916102815.04395c70@mail.comcast.net> <4149E13C.7060102@nma.com> <414C3E22.2010306@algroup.co.uk>
Message-ID: <414CD2DF.6010002@nma.com>

Ben Laurie wrote:

> Ed Gerck wrote:
>> If the recipient cannot in good faith detect a key-access ware, or a
>> GAK-ware, or a Trojan, or a bug, why would a complete background
>> check of the recipient help?
> 
> Let's assume for a moment that a solution exists that satisfies your 
> requirements. Since the recipient _must_ be able to read the document in 
> the end, and is assumed to be incapable of securing their software, then 
> the document is still available to third parties without the consent of 
> the sender, is it not?

The recipient was not assumed to be entirely incapable of securing his
software. The recipient can be trusted to do a number of things that are
basic, for example, to operate an email software. In fact, we can even
assume a pretty sophisticated recipient, trained to use all the security
email software systems commercially available. Still, the recipient will
be incapable of verifying whether his RSA private-key is weak or not. Thus,
even fully unwillingly and under best efforts, the recipient can put the
sender's message security at risk when using that recipient's RSA public-
key.

> It seems to me that fixing the PK "problem" would in no way improve the 
> senders situation given that threat model.

The sender's situation can be improved mostly when the sender trusts the
least possible (ideally, nothing) regarding message security. In other
words, the sender would like to avoid anything that is not under control or
cannot be directly verified by the sender. Doing a background check of the
recipient is orthogonal to the PK problem. It does not help nor solve it.

Cheers,
Ed Gerck

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From egerck at nma.com  Sat Sep 18 21:05:05 2004
From: egerck at nma.com (Ed Gerck)
Date: Sat, 18 Sep 2004 18:05:05 -0700
Subject: public-key: the wrong model for email?
In-Reply-To: <6.1.2.0.2.20040918101032.060d7710@mail.comcast.net>
References: <41488C5D.8050205@nma.com> <6.1.2.0.2.20040915181029.05be2ac0@mail.comcast.net> <41492278.3090303@nma.com> <6.1.2.0.2.20040916102815.04395c70@mail.comcast.net> <4149E13C.7060102@nma.com> <6.1.2.0.2.20040918101032.060d7710@mail.comcast.net>
Message-ID: <414CDB41.8040504@nma.com>


Anne & Lynn Wheeler wrote:

> At 12:53 PM 9/16/2004, Ed Gerck wrote:
> 
>> If the recipient cannot in good faith detect a key-access ware, or a
>> GAK-ware, or a Trojan, or a bug, why would a complete background
>> check of the recipient help?
> 
> 
> a "complete audit and background check" ... would include an audit of 
> the recipient ... not just the recipient person .... but the recipient 
> ... as in the recipient operation.

I agree with you that more checks is usually better. But if you are talking
about someone else verifying the recipient's machine, we're talking about
what seems to me to be a much worse security risk. Who exactly would you
trust to verify your machine and potentially read your decrypted email and
other documents? A "neutral" third-party? Just allowing a third-party to
have access to my machine would go against a number of NDAs and security
policies that I routinely sign. Further, in terms of internal personnel doing
it, we know that 70% of the attacks are internal. The solution to my email
security problem should not be installing a back-door in your machine.

> (snip) the 
> leakage of a classified document wouldn't solely be restricted to 
> technical subversion.

The leakage of a classified document has a number of aspects to consider
in order to prevent it, as we all know. From the sender's viewpoint, however,
what strategy should have the most impact in reducing leakage of a classified
document? It seems clear to me that it is in avoiding anything that is not
under control or cannot be directly verified by the sender. In other words,
it should be more effective to eliminate the sender's reliance on the
recipient's public-key (the sender cannot control or verify whether the key
is weak or not) than do yet another background check of the recipient operation.
Even if the recipient passes today, it may be vulnerable tomorrow. The
sender can't control it.

Cheers--/Ed Gerck

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Sun Sep 19 02:15:05 2004
From: iang at systemics.com (Ian Grigg)
Date: Sun, 19 Sep 2004 07:15:05 +0100
Subject: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from
 hal@finney.org) (fwd from touch@ISI.EDU)
In-Reply-To: <20040918004156.5C71E1AE7E@berkshire.research.att.com>
References: <20040918004156.5C71E1AE7E@berkshire.research.att.com>
Message-ID: <414D23E9.4090001@systemics.com>

Steven M. Bellovin wrote:

> For RFCs, there are two paths.  If the topic is general enough (and, of 
> course, the advice is good enough), Russ Housley or I would consider 
> sponsoring the document as a BCP.  If it's narrow or we're not 
> interested for some reason (other than quality, of course), it could be 
> an individual submission.  I encourage both paths.

It sounds like an RFC / BCP would be a good target.
I suspect given the controversy over a lot of these
ideas an intermediate phase would be needed where
the controversy could be aired in depth, before being
summarised into a BCP.

 From that pov, a wiki + discussion list leading to a
BCP would seem like a good idea.

Alternatively, let all these things be thrown into
the mixing pot and see what happens?

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Sat Sep 18 22:55:49 2004
From: iang at systemics.com (Ian Grigg)
Date: Sun, 19 Sep 2004 03:55:49 +0100
Subject: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from
 hal@finney.org) (fwd from touch@ISI.EDU)
In-Reply-To: <20040918070454.GA1261@danisch.de>
References: <E1C6uKH-0008Ou-00@medusa01> <4148D335.4010207@systemics.com> <20040918070454.GA1261@danisch.de>
Message-ID: <414CF535.6070603@systemics.com>

Hadmut Danisch wrote:
> On Thu, Sep 16, 2004 at 12:41:41AM +0100, Ian Grigg wrote:
> 
>>It occurs to me that a number of these ideas could
>>be written up over time ... a wiki, anyone?  I think
>>it is high past time to start documenting crypto
>>patterns.
> 
> 
> Wikis are not that good for discussions, and I do believe
> that this requires some discussion.
> 
> I'd propose a separate mailing list for that.

It possibly requires both.  A mailing list by itself
tends to generate great thoughts that don't get finished
by being turned into summaries.  Also, those in charge
tend to slow the process, just through being too busy.
(I'm not talking about just this list, I've noticed
the effect on RFC lists where the editor wakes up after
a week and skips all the debate and starts again.)
A wiki working with a mailing list might address both
those issues.

(It's just a guess, I've never really worked with a
Wiki, just read some entries over at wikipedia.)

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Sun Sep 19 20:18:50 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Sun, 19 Sep 2004 20:18:50 -0400
Subject: Time for new hash standard
Message-ID: <p06110460bd73d189d8a2@[66.149.49.5]>

<http://smh.com.au/cgi-bin/common/popupPrintArticle.pl?path=/articles/2004/09/20/1095532207966.html>


Sydney Morning Herald

Time for new hash standard
By Bruce Schneier
Comment
 September 20, 2004 - 9:09AM

 At the CRYPTO conference in Santa Barbara, CA, last month, researchers
announced several weaknesses in common hash functions. These results, while
mathematically significant, aren't cause for alarm. But even so, it's
probably time for the cryptography community to get together and create a
new hash standard.

 One-way hash functions are a cryptographic construct used in many
applications. They are used in conjunction with public-key algorithms for
both encryption and digital signatures. They are used in integrity
checking. They are used in authentication. They have all sorts of
applications in a great many different protocols. Much more than encryption
algorithms, one-way hash functions are the workhorses of modern
cryptography.

 In 1990, Ron Rivest invented the hash function MD4. In 1992, he improved
on MD4 and developed another hash function: MD5. In 1993, the National
Security Agency published a hash function very similar to MD5, called SHA
(Secure Hash Algorithm). Then, in 1995, citing a newly discovered weakness
that it refused to elaborate on, the NSA made a change to SHA. The new
algorithm was called SHA-1. Today, the most popular hash function is SHA-1,
with MD5 still being used in older applications.

 One-way hash functions are supposed to have two properties. One, they're
one way. This means that it is easy to take a message and compute the hash
value, but it's impossible to take a hash value and recreate the original
message. (By "impossible" I mean "can't be done in any reasonable amount of
time.") Two, they're collision free. This means that it is impossible to
find two messages that hash to the same hash value. The cryptographic
reasoning behind these two properties is subtle, and I invite curious
readers to learn more in my book "Applied Cryptography."

 Breaking a hash function means showing that either - or both - of those
properties are not true. Cryptanalysis of the MD4 family of hash functions
has proceeded in fits and starts over the last decade or so, with results
against simplified versions of the algorithms and partial results against
the whole algorithms. This year, Eli Biham and Rafi Chen, and separately
Antoine Joux, announced some pretty impressive cryptographic results
against MD5 and SHA. Collisions have been demonstrated in SHA. And there
are rumors, unconfirmed at this writing, of results against SHA-1.

 The magnitude of these results depends on who you are. If you're a
cryptographer, this is a huge deal. While not revolutionary, these results
are substantial advances in the field. The techniques described by the
researchers are likely to have other applications, and we'll be better able
to design secure systems as a result. This is how the science of
cryptography advances: we learn how to design new algorithms by breaking
other algorithms. Additionally, algorithms from the NSA are considered a
sort of alien technology: they come from a superior race with no
explanations. Any successful cryptanalysis against an NSA algorithm is an
interesting data point in the eternal question of how good they really are
in there.

 To a user of cryptographic systems - as I assume most readers are - this
news is important, but not particularly worrisome. MD5 and SHA aren't
suddenly insecure. No one is going to be breaking digital signatures or
reading encrypted messages anytime soon with these techniques. The
electronic world is no less secure after these announcements than it was
before.

 But there's an old saying inside the NSA: "Attacks always get better; they
never get worse." These techniques will continue to improve, and probably
someday there will be practical attacks based on these techniques.

 It's time for us all to migrate away from SHA-1.

 Luckily, there are alternatives. The National Institute of Standards and
Technology already has standards for longer - and harder to break - hash
functions: SHA-224, SHA-256, SHA-384, and SHA-512. They're already
government standards, and can already be used. This is a good stopgap, but
I'd like to see more.

 I'd like to see NIST orchestrate a worldwide competition for a new hash
function, like they did for the new encryption algorithm, AES, to replace
DES. NIST should issue a call for algorithms, and conduct a series of
analysis rounds, where the community analyzes the various proposals with
the intent of establishing a new standard.

 Most of the hash functions we have, and all the ones in widespread use,
are based on the general principles of MD4. Clearly we've learned a lot
about hash functions in the past decade, and I think we can start applying
that knowledge to create something even more secure.

 Better to do it now, when there's no reason to panic, than years from now,
when there might be.

 Bruce Schneier is a world-renowned security technologist. His latest book
is Beyond Fear: Thinking Sensibly About Security in an Uncertain World. He
can be reached at www.schneier.com. This article first appeared in his
monthly newsletter Crypto-Gram and is reproduced with permission. Copyright
rests with the author.


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From rah at shipwright.com  Mon Sep 20 08:33:02 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Mon, 20 Sep 2004 08:33:02 -0400
Subject: Academics locked out by tight visa controls
Message-ID: <p06110481bd747da7309b@[66.149.49.5]>

<http://www.mercurynews.com/mld/mercurynews/9710963.htm?template=contentModules/printstory.jsp>

Posted on Mon, Sep. 20, 2004

Academics locked out by tight visa controls
U.S. SECURITY BLOCKS FREE EXCHANGE OF IDEAS
By Bruce Schneier


Cryptography is the science of secret codes, and it is a primary Internet
security tool to fight hackers, cyber crime, and cyber terrorism. CRYPTO is
the world's premier cryptography conference. It's held every August in
Santa Barbara.

This year, 400 people from 30 countries came to listen to dozens of talks.
Lu Yi was not one of them. Her paper was accepted at the conference. But
because she is a Chinese Ph.D. student in Switzerland, she was not able to
get a visa in time to attend the conference.

In the three years since 9/11, the U.S. government has instituted a series
of security measures at our borders, all designed to keep terrorists out.
One of those measures was to tighten up the rules for foreign visas.
Certainly this has hurt the tourism industry in the U.S., but the damage
done to academic research is more profound and longer-lasting.

According to a survey by the Association of American Universities, many
universities reported a drop of more than 10 percent in foreign student
applications from last year. During the 2003 academic year, student visas
were down 9 percent. Foreign applications to graduate schools were down 32
percent, according to another study by the Council of Graduate Schools.

There is an increasing trend for academic conferences, meetings and
seminars to move outside of the United States simply to avoid visa hassles.

This affects all of high-tech, but ironically it particularly affects the
very technologies that are critical in our fight against terrorism.

Also in August, on the other side of the country, the University of
Connecticut held the second International Conference on Advanced
Technologies for Homeland Security. The attendees came from a variety of
disciplines -- chemical trace detection, communications compatibility,
X-ray scanning, sensors of various types, data mining, HAZMAT clothing,
network intrusion detection, bomb diffusion, remote-controlled drones --
and illustrate the enormous breadth of scientific know-how that can
usefully be applied to counterterrorism.

It's wrong to believe that the U.S. can conduct the research we need alone.
At the Connecticut conference, the researchers presenting results included
many foreigners studying at U.S. universities. Only 30 percent of the
papers at CRYPTO had only U.S. authors. The most important discovery of the
conference, a weakness in a mathematical function that protects the
integrity of much of the critical information on the Internet, was made by
four researchers from China.

Every time a foreign scientist can't attend a U.S. technology conference,
our security suffers. Every time we turn away a qualified technology
graduate student, our security suffers. Technology is one of our most
potent weapons in the war on terrorism, and we're not fostering the
international cooperation and development that is crucial for U.S. security.

Security is always a trade-off, and specific security countermeasures
affect everyone, both the bad guys and the good guys. The new U.S.
immigration rules may affect the few terrorists trying to enter the United
States on visas, but they also affect honest people trying to do the same.

All scientific disciplines are international, and free and open information
exchange -- both in conferences and in academic programs at universities --
will result in the maximum advance in the technologies vital to homeland
security. The Soviet Union tried to restrict academic freedom along
national lines, and it didn't do the country any good. We should try not to
follow in those footsteps.

BRUCE SCHNEIER is a security technologist and chief technology officer of
Counterpane Internet Security, Inc., in Mountain View. He wrote this for
the Mercury News.

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From kelsey.j at ix.netcom.com  Mon Sep 20 10:03:57 2004
From: kelsey.j at ix.netcom.com (John Kelsey)
Date: Mon, 20 Sep 2004 10:03:57 -0400 (GMT-04:00)
Subject: Academics locked out by tight visa controls
Message-ID: <17894379.1095689037533.JavaMail.root@grover.psp.pas.earthlink.net>

>From: "R. A. Hettinga" <rah at shipwright.com>
>Sent: Sep 20, 2004 8:33 AM
>Subject: Academics locked out by tight visa controls

><http://www.mercurynews.com/mld/mercurynews/9710963.htm?template=contentModules/printstory.jsp>

>Posted on Mon, Sep. 20, 2004

>Academics locked out by tight visa controls
>U.S. SECURITY BLOCKS FREE EXCHANGE OF IDEAS
>By Bruce Schneier

...

I guess I've been surprised this issue hasn't seen a lot more discussion.  It takes nothing more than to look at the names of the people doing PhDs and postdocs in any technical field to figure out that a lot of them are at least of Chinese, Indian, Arab, Iranian, Russian, etc., ancestry.  And only a little more time to find out that a lot of them are not citizens, and have a lot of hassles with respect to living and working here.  What do you suppose happens to the US lead in high-tech, when we *stop* drawing in some large fraction of the smartest, hardest-working thousandth of a percent of mankind?  

--John

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From adam at homeport.org  Mon Sep 20 10:50:18 2004
From: adam at homeport.org (Adam Shostack)
Date: Mon, 20 Sep 2004 10:50:18 -0400
Subject: Academics locked out by tight visa controls
In-Reply-To: <17894379.1095689037533.JavaMail.root@grover.psp.pas.earthlink.net>
References: <17894379.1095689037533.JavaMail.root@grover.psp.pas.earthlink.net>
Message-ID: <20040920145017.GA99462@lightship.internal.homeport.org>

On Mon, Sep 20, 2004 at 10:03:57AM -0400, John Kelsey wrote:

| >Academics locked out by tight visa controls
| >U.S. SECURITY BLOCKS FREE EXCHANGE OF IDEAS
| >By Bruce Schneier
| 
| I guess I've been surprised this issue hasn't seen a lot more
| discussion.  It takes nothing more than to look at the names of the
| people doing PhDs and postdocs in any technical field to figure out
| that a lot of them are at least of Chinese, Indian, Arab, Iranian,
| Russian, etc., ancestry.  And only a little more time to find out that
| a lot of them are not citizens, and have a lot of hassles with respect
| to living and working here.  What do you suppose happens to the US
| lead in high-tech, when we *stop* drawing in some large fraction of
| the smartest, hardest-working thousandth of a percent of mankind?   

Those people don't get a vote.  The politicians in question will be
dead and gone before the slope of the curve changes anything.  Why
*would* we discuss it?

Adam the cynic.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Mon Sep 20 11:05:34 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Mon, 20 Sep 2004 11:05:34 -0400
Subject: VeriSecure Systems, Inc. Demonstrates Check 21 Fraud Prevention
Message-ID: <p061104a5bd74a22abf5e@[66.149.49.5]>

<http://home.businesswire.com/portal/site/google/index.jsp?ndmViewId=news_view&newsId=20040920005169&newsLang=en>



Search Results for Google
 


 
 September 20, 2004 09:00 AM US Eastern Timezone

VeriSecure Systems, Inc. Demonstrates Check 21 Fraud Prevention

  FORT LAUDERDALE, Fla.--(BUSINESS WIRE)--Sept. 20, 2004--VeriSecure
Systems(TM), Inc. announced that its Check Fraud Prevention System (CFPS)
was tested under the auspices of the Financial Services Technology
Consortium, whose members include the largest financial institutions in the
US, as well as community banks, check clearing exchanges and other
institutions. VeriSecure Systems technology was demonstrated to survive the
check truncation, imaging and exchange and to offer security value
throughout the process.


 In October of 2003, Congress passed legislation known as Check 21. This
legislation becomes effective October 2004 and enables the banking industry
to exchange bank check images in lieu of paper bank checks. Called
"Controlling Fraud in a Truncated Check Environment", the purpose of the
project was to assess the survivability, performance and viability of
"next-generation" document security features in image based operations for
bank checks, by conducting real life simulated exchanges among ten
institutions.

 VeriSecure Systems employed its Check Fraud Prevention System (CFPS) for
the project, which is based on its US Patent #5,432,506 "Counterfeit
Document Detection System." The technology uses cryptography to create a
unique code for each check. The security feature is applied as a standard
printed barcode symbol by the check issuer. VeriSecure's software,
developed in conjunction with Inlite Research, Inc., can provide a fully
automated solution to read and validate the codes from either the actual
paper documents or from the images of the documents. The software rapidly
verifies the authenticity of the information printed on the checks, and
identifies any alterations, thus preventing the most prevalent forms of
fraud.

 Tom Chapman, VeriSecure's founder and the inventor of the technology said,
"This project has certainly helped to demonstrate how cryptography can
easily and conveniently be put to use, to validate any type of physical
documents or their images. Along with fraud losses, this technology has the
potential to reduce operating expenses of financial institutions as well as
remittance processing for corporations."

 Gene Manheim, President of Inlite Research explained that "Industry
standard barcodes serve as the robust foundation to secure check images,
and enable innovative technologies like CFPS to provide fraud prevention
across a huge range of images."

 Frank Jaffe, project manager for FSTC, said "Based on the results of the
project, and given the magnitude of the risks of loss from check fraud,
FSTC believes that financial institutions and check issuers will be well
served by the adoption of these new document security features."

 About VeriSecure Systems

 The Company licenses its patented technology which is designed to verify
the authenticity of physical documents and/or captured images. It is
located in Plantation, Florida. (954) 401-8378
http://www.verisecuresystems.com

 About Inlite Research

 Since 1992, Inlite Research Inc. offers its Image Processing and Barcode
Recognition technologies to OEMs and solution providers in markets that
demand the utmost accuracy, productivity and quality in business processes.
It is located in Sunnyvale, California. (408) 737-7092
http://www.inliteresearch.com

 About The Financial Services Technology Consortium

 The Financial Services Technology Consortium (FSTC.ORG) is a consortium of
leading North American-based financial institutions, technology vendors,
independent research organizations, and government agencies. New York, NY.
(212) 461-7116 http://www.fstc.org
 Contacts
VeriSecure Systems, Inc., Plantation, Fla.
Tom Chapman, 954-401-8378 Print this Release

Terms of Use   |    ? Business Wire 2004

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From nelson at crynwr.com  Mon Sep 20 14:23:46 2004
From: nelson at crynwr.com (Russell Nelson)
Date: Mon, 20 Sep 2004 14:23:46 -0400
Subject: Time for new hash standard
In-Reply-To: <p06110460bd73d189d8a2@[66.149.49.5]>
References: <p06110460bd73d189d8a2@[66.149.49.5]>
Message-ID: <16719.8242.172109.222858@desk.crynwr.com>

 >  Luckily, there are alternatives. The National Institute of Standards and
 > Technology already has standards for longer - and harder to break - hash
 > functions: SHA-224, SHA-256, SHA-384, and SHA-512. They're already
 > government standards, and can already be used. This is a good stopgap, but
 > I'd like to see more.

http://cr.yp.to/antiforgery.html#hash127

-- 
--My blog is at angry-economist.russnelson.com  | Violence never solves
Crynwr sells support for free software  | PGPok | problems, it just changes
521 Pleasant Valley Rd. | +1 212-202-2318 voice | them into more subtle
Potsdam, NY 13676-3213  | FWD# 404529 via VOIP  | problems.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From hal at finney.org  Mon Sep 20 15:43:56 2004
From: hal at finney.org (Hal Finney)
Date: Mon, 20 Sep 2004 12:43:56 -0700 (PDT)
Subject: Time for new hash standard
Message-ID: <20040920194356.EC32357E2B@finney.org>

Bruce Schneier wrote:
>  Luckily, there are alternatives. The National Institute of Standards and
> Technology already has standards for longer - and harder to break - hash
> functions: SHA-224, SHA-256, SHA-384, and SHA-512. They're already
> government standards, and can already be used. This is a good stopgap, but
> I'd like to see more.

Russell Nelson suggested:
> http://cr.yp.to/antiforgery.html#hash127

I believe this is a MAC, despite the name.  It seems to be easier to
create secure MACs than secure hash functions, perhaps because there are
no secrets in a hash, while in a MAC there is a secret key that makes
the attacker's job harder.

Hal

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From DaveHowe at gmx.co.uk  Mon Sep 20 17:22:15 2004
From: DaveHowe at gmx.co.uk (Dave Howe)
Date: Mon, 20 Sep 2004 22:22:15 +0100
Subject: They Said It Couldn't Be Done
In-Reply-To: <p061104abbd7203207609@[66.149.49.5]>
References: <p061104abbd7203207609@[66.149.49.5]>
Message-ID: <414F4A07.5060702@gmx.co.uk>

R. A. Hettinga wrote:
> Nevada has taken the lead on paper trails not only in its own elections,
> but also in Congress. Its senators - John Ensign, a Republican, and Harry
> Reid, a Democrat - have co-sponsored the bipartisan Voting Integrity and
> Verification Act, one of a number of pending bills that would require that
> all electronic voting machines produce voter-verifiable paper trails.
> Congress should pass such legislation right away so all Americans can have
> the same confidence in their elections as Nevadans now have.
I must admit I am surprised a new law is needed.
Under the Help America Vote Act 2002 electronic voting machines appear 
to have the following audit requirement:

    TITLE III--UNIFORM AND NONDISCRIMINATORY ELECTION TECHNOLOGY AND
                       ADMINISTRATION REQUIREMENTS

                        Subtitle A--Requirements

SEC. 301. <<NOTE: 42 USC 15481>> VOTING SYSTEMS STANDARDS.

    (a) Requirements.--Each voting system used in an election for
Federal office shall meet the following requirements:
            (2) Audit capacity.--
                    (A) In general.--The voting system shall produce a
                record with an audit capacity for such system.
                    (B) Manual audit capacity.--
                          (i) The voting system shall produce a
                      permanent paper record with a manual audit
                      capacity for such system.
                          (ii) The voting system shall provide the voter
                      with an opportunity to change the ballot or
                      correct any error before the permanent paper
                      record is produced.
                          (iii) The paper record produced under
                      subparagraph (A) shall be available as an official
                      record for any recount conducted with respect to
                      any election in which the system is used.

(taken from http://www.fec.gov/hava/law_ext.txt )

So unless there is a amendment to that law (that I am obviously unaware 
of) it isn't up to individual States to add this as an additional 
requirement - its already required. perhaps someone could enlighten me?

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From lynn at garlic.com  Mon Sep 20 18:07:55 2004
From: lynn at garlic.com (Anne & Lynn Wheeler)
Date: Mon, 20 Sep 2004 16:07:55 -0600
Subject: Academics locked out by tight visa controls
In-Reply-To: <17894379.1095689037533.JavaMail.root@grover.psp.pas.earthl
 ink.net>
References: <17894379.1095689037533.JavaMail.root@grover.psp.pas.earthlink.net>
Message-ID: <6.1.2.0.2.20040920153228.0676a870@mail.comcast.net>

At 08:03 AM 9/20/2004, John Kelsey wrote:
>I guess I've been surprised this issue hasn't seen a lot more 
>discussion.  It takes nothing more than to look at the names of the people 
>doing PhDs and postdocs in any technical field to figure out that a lot of 
>them are at least of Chinese, Indian, Arab, Iranian, Russian, etc., 
>ancestry.  And only a little more time to find out that a lot of them are 
>not citizens, and have a lot of hassles with respect to living and working 
>here.  What do you suppose happens to the US lead in high-tech, when we 
>*stop* drawing in some large fraction of the smartest, hardest-working 
>thousandth of a percent of mankind?


in '94 there was report (possibly sjmn?) that said at least half of all 
cal. univ. tech. PHDs were awarded to foreign born. during some of the tech 
green card discussions in the late '90s ... it was pointed out that the 
internet boom (bubble) was heavily dependent on all these foreign born .... 
since there was hardly enuf born in the usa to meet the demand.

in the late 90s there were some reports that many of these graduates had 
their education paid by their gov. with directions to enter an us company 
in strategic high tech areas for 4-8 years .... and then return home as 
tech transfer effort. i was told in the late 90s about one optical 
computing group in a high tech operation .... where all members of the 
group fell into this category (foreign born with obligation to return home 
after some period).

another complicating factor competing for resources during the late 90s 
high-tech, internet boom (bubble?) period was the significant resource 
requirement for y2k remediation efforts.

nsf had recent study on part of this
http://www.nsf.gov/sbe/srs/infbrief/ib.htm
graduate enrollment in science and engineering fields reaches new peak; 1st 
time enrollment of foreign students drops
http://www.nsf.gov/sbe/srs/infbrief/nsf04326/start.htm

--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/ 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Mon Sep 20 20:33:23 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Mon, 20 Sep 2004 20:33:23 -0400
Subject: FSTC Project Update
Message-ID: <p0611040dbd752739ef85@[66.149.49.5]>


--- begin forwarded text


Date: Mon, 20 Sep 2004 15:06:35 -0400
From: Jim Salters <jim.salters at fstc.org>
Subject: FSTC Project Update
To: members at ls.fstc.org
Thread-Index: AcRB0A9Y0sS8MgYzStq91o5SaD2dkAAAEYTwFfSLIoABaGIp8A==
List-Post: <mailto:members at ls.fstc.org>
List-Subscribe: <http://ls.fstc.org/subscribe>,
 <mailto:members-request at ls.fstc.org?body=subscribe>
List-Archive: <http://ls.fstc.org/archives/members/>
List-Help: <http://ls.fstc.org/elists/admin.shtml>,
 <mailto:members-request at ls.fstc.org?body=help>
List-Id: <members.ls.fstc.org>

To: FSTC Members and Friends
From: Jim Salters, Director of Tech Initiatives and Project Development

*** September Project Update ***

After a busy summer season of meetings and project development, a number of
FSTC projects are poised to launch, as well as a strong pipeline in
development.  Our Standing Committees (SCOMs), especially those in Business
Continuity, Security, and Check Imaging and Truncation, continue to broaden
their participation, and build upon a foundation of dialog and action that
leads to FSTC projects.  In the past few weeks, we issued two new calls for
participation: e-Authentication Proof-of-Concept, and Business Continuity
Compliance and Status Reporting.  See http://fstc.org/projects/new.cfm .

In addition, we have recently completed projects in Image Quality and
Usability Assurance Phase I, Technology Recovery Best Practices, and
Survivability of Check Security Features.  Details on these recent projects
can be found at: http://fstc.org/projects/past.cfm .

FSTC provides an action-oriented, collaborative forum for our members to
address shared business opportunities and challenges through technology
projects and knowledge-sharing.  We view our projects as our core activity,
and one of the key benefits of FSTC membership is eligibility to participate
in these projects.  In our efforts to keep our members and friends
up-to-date on the latest developments in these active and developing
initiatives, we provide our colleagues this periodic project update  As
always, please contact me or Zach Tumin, FSTC Executive Director, for more
information.  Or visit our website at http://fstc.org.

Active Projects:

1.  Counter-Phishing Phase I

Projects in Formation:

1.  e-Authentication: Business and Technology Proof-of-Concept (call for
participation issued 9/8)
2.  Business Continuity: Compliance and Status Reporting (call for
participation issued 9/8)

Projects in Development:

1.  Image Quality and Usability Assurance Phase II
2.  Survivability of Check Security Features Phase II
3.  Treasury Services Integration: Data Exchange and Customer Connectivity
through Web Services
4.  Transformation to Open Mission Critical Systems
5.  Minimum Essential Finance (MEF)
______________

ACTIVE PROJECTS:

1.  Counter-Phishing Phase I (launched July 2004, expected to complete in
December)

http://fstc.org/projects/counter-phishing-phase-1/

FSTC has launched a phased initiative to address the problem of phishing and
related threats in financial services, as it affects the relationship
between customer and firm.  In collaboration with other industry groups,
FSTC will focus on defining the unique technical and operating requirements
of financial institutions (FIs) for counter-phishing measures; investigating
counter-phishing technical solutions, proving and piloting solution sets
enabled by technology to determine their fit against FI criteria and
requirements; and clarifying the infrastructure fit, requirements, and
impact of these technologies when deployed in concert with customer
education, enforcement, and other industry initiatives.  The benefits to
participants are: industry-vetted due diligence and scaling of the current
problem and its future evolution; insight into peer institution strategies
and assessments; and definition of an industry response that may be best
undertaken with collaboration between key industry segments.

12 financial institutions and over 15 technology companies are participating
in the 5-month first phase.  This project originates from the Security SCOM:
co-chaired by Mike McCormick of Wells Fargo, and Mike Versace of NEC.
Please contact FSTC Managing Executive Gene Neyer for more information
(gene.neyer at fstc.org).  (http://fstc.org/advisory/security.cfm)
______________

PROJECTS IN FORMATION:

1.  e-Authentication: Business and Technology Proof-of-Concept (call for
participation issued 9/8/04)

http://fstc.org/projects/new.cfm#eauth

This 5-month project will assess the viability of the potential business
opportunity that exists for financial institutions to leverage their online
customer relationships and provide an authentication service to government
agencies, and to integrate these services into financial institutions'
online applications. FSTC, jointly with the GSA's E-Authentication
Initiative Project Management Office (EAI PMO), propose to launch a
three-track project to ascertain the business model, legal framework, and
technical viability of using institutions' identity credentials to permit
consumers and businesses to access secure online government applications.

The GSA is funding the business track of the initiative. There is no cost to
financial institutions, and a $5,000 fee for associate and advisory members.
In addition, a resource commitment is required for all participants, as
outlined in the prospectus. Participation commitments are requested by Sept
24th, and the target kickoff is the week of October 4th.

______________

2.  Business Continuity: Compliance and Status Reporting (call for
participation issued 9/8/04)

http://fstc.org/projects/new.cfm#compliance

The FSTC Business Continuity Standing Committee proposes an initiative to
assist the financial industry in coming to a common understanding on the
meaning of continuity regulation, prioritization of compliance related
activities, and creating efficiencies in documenting regulatory compliance
status. To establish a clear understanding of the regulatory environment, a
list of continuity related guidance will be pulled together along with the
name of the agency responsible. Each regulation will be reviewed and a
clearly worded summary of the continuity requirements will be developed.
Where possible the regulatory agencies will be contacted for clarification
on specific points. Common themes and requirements will be documented and
prioritized.

>From the continuity regulation summary, a questionnaire will be developed
which will allow a FI to provide or collect continuity compliance status.
The project will focus on providing straight forward interpretations of what
is needed for an FI to comply with current regulations.

This project is sponsored by the Business Continuity SCOM, co-chaired by Tom
Hirsch of US Bank, and Damian Walch of IBM.  Please contact FSTC Managing
Executive Charles Wallen for more information (charles.wallen at fstc.org).
______________

PROJECTS IN DEVELOPMENT:

1.   Image Quality and Usability Assurance: Phase II (proposal being
finalized)

http://fstc.org/projects/new.cfm#iqa2

In Phase I, more than 20 companies, representing 2/3 of US check volume,
most major vendors, and key industry associations, undertook a 90-day effort
to assess the impact of poor quality check images, and defined 16 technical
metrics and 4 usability levels that can be used to measure image quality and
usability in a standard and interoperable way.  The findings of the Phase I
project team justified further development, to test these metrics in a
real-world scenario, on millions of images, to determine the quantitative
thresholds for the 16 metrics that will define a minimum baseline "standard"
for acceptable quality images for the industry.

The business objectives are to maximize efficiencies, cost savings, and
ensure strong adoption of image exchange. The project will undertake a
robust, "real-world" analysis and test to provide actionable specifications
and direction to the industry to allow financial institutions, technology
vendors, standards organizations, and other key partners to collectively
implement baseline image quality and usability through industry
collaboration under the FSTC umbrella.

This project originates from the Check Truncation SIG
(http://fstc.org/advisory/check-truncation.cfm), co-chaired by Katrina
Brown, Wells Fargo; Glen Ulrich, US Bank; and Ian Goodall, NCR.  A call for
participation is expected during the month of September.
______________

2.  Survivability of Check Security Features Phase II

As a follow-on to the recently completed Phase I
(http://fstc.org/projects/csf/), this initiative will seek to develop
interoperability specifications for automated security feature verification
engines.  As a growing number of vendors offer security features targeted at
surviving the imaging process, institutions face a growing number of
proprietary verification engines that must be installed and configured to
validate these features during processing.  The objective of this initiative
is to make is less expensive and easier to manage the implementation of
these security feature verification products.

This project originates from the Check Truncation SIG
(http://fstc.org/advisory/check-truncation.cfm).  More information on this
project will be published in the next month or so.
______________

3.  Treasury Services Integration: Data Exchange and Customer Connectivity
through Web Services (on hold)

http://fstc.org/projects/new.cfm#tsi

As a potential Phase II following the previous Web Services for Corporate
Cash Management effort, a core group of FSTC institutions and technology
companies have defined key business objectives and deliverables for a
discovery phase, and subsequent pilot-level project utilizing Web Services
in the Treasury Services / Cash Management area.  The project, as it
currently stands, will seek to further develop the Phase I set of web
services and associated definitions to create new and open-standards-based
connectivity options between banks, and between banks and their customers.
The business goals are to enable standards-based "plug-and-play" integration
capabilities between institutions and customer platforms, whether ERP,
Treasury Work Station (TWS), or desktop.

A core group of financial institutions and technology companies has
committed to launching this initiative in the second half of 2004.  This
project is considered on-hold until later this year.
______________

4.  Transformation to Open Mission Critical Systems

The transformation of systems from higher cost or proprietary delivery to
open systems is one of the most hotly debated and discussed topics in
financial services IT.  While there is great promise in the flexibility and
efficiencies gained, there is also risk and cost. An FSTC project will soon
form up to determine answers to such key questions as, "Are those
transformations viable?" and "What are the costs and processes by which a
successful transformation program will be run?" The vision of this
initiative is to bring together financial institutions to investigate the
needs, processes, best practices, technology issues, risk factors,
organizational issues and lessons-learned for transformation projects which
move core business processes from legacy IT assets to open systems.  We will
provide additional details shortly.  If you are interested in joining an
interest group around this topic, please contact us.
______________

5.  Minimum Essential Finance (MEF)

In its early stages, FSTC and its members are in dialog with numerous
government and industry organizations to explore interest in an initiative
to identify the minimum essential elements of our financial system, and to
develop a plan and process to ensure that it remains operational in the
event of a disruption to normal operations.  A workshop is currently being
planned for this fall for multiple public and private sector organizations
to develop this concept further.  If you are interested in joining this
dialog, please contact Zach Tumin at zachary.tumin at fstc.org .
______________

##








----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://ls.fstc.org/subscriber>

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From rah at shipwright.com  Mon Sep 20 21:09:10 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Mon, 20 Sep 2004 21:09:10 -0400
Subject: AOL to Sell Secure ID Tags to Fight Hackers
Message-ID: <p06110417bd752f5cd7c3@[66.149.49.5]>

<http://www.reuters.com/newsArticle.jhtml?type=internetNews&storyID=6284760>

Reuters



AOL to Sell Secure ID Tags to Fight Hackers
 Mon Sep 20, 2004 06:18 PM ET

  NEW YORK (Reuters) - America Online will begin offering to sell members a
security device and service that has been used to safeguard business
computer networks, the world's largest Internet service provider said on
Monday.

 AOL, a unit of Time Warner Inc. (TWX.N: Quote, Profile, Research) , signed
a deal with Internet security company RSA Security Inc. (RSAS.O: Quote,
Profile, Research) , to launch its new AOL PassCode, designed to add an
additional layer of protection to member accounts.

 PassCode users will be provided with a small handheld six-digit numeric
code key.

 To log onto an AOL account equipped with the service, users will have to
type in the six-digits, which refresh on the device every 60 seconds, on
top of using the regular password.

The code-key device will cost $9.95. Monthly service costs range from $1.95
to $4.95.

 "AOL PassCode is like adding a deadbolt to your AOL account by
automatically creating a new secondary password every 60 seconds," said Ned
Brody, senior vice president of AOL Premium Services.

 Hackers coined the term "phishing" in 1996 to refer to the act of
swindling unsuspecting AOL customers into giving up their passwords through
phony e-mails or instant messages.
-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From ianf at dreamscape.com.au  Mon Sep 20 22:14:48 2004
From: ianf at dreamscape.com.au (Ian Farquhar)
Date: Tue, 21 Sep 2004 12:14:48 +1000
Subject: Time for new hash standard
In-Reply-To: <20040920194356.EC32357E2B@finney.org>
References: <20040920194356.EC32357E2B@finney.org>
Message-ID: <6.1.2.0.2.20040921120551.03f21518@mail.cia.com.au>

At 05:43 AM 21/09/2004, Hal Finney wrote:
>I believe this is a MAC, despite the name.  It seems to be easier to
>create secure MACs than secure hash functions, perhaps because there are
>no secrets in a hash, while in a MAC there is a secret key that makes
>the attacker's job harder.

Interestingly, a crypto-specialist from DSD (Australian NSA-equivalent) 
said exactly this to me in 1997-1998.  He called them "strange" functions 
to design. I subsequently asked if they - which in the context meant the 
tier one UKUSA agencies - had many hash functions developed for classified 
uses.  He indicated that they had quite a few MAC-style keyed functions, 
but not many unkeyed hashes.

This was all over a lunch to discuss SENECA, Oz's VLSI proposal to replace 
DES for sensitive-but-unclassified applications (64 bit keys, produced on 
an otherwise moribund 1.5u fab in Sydney).  SENECA lost funding, basically 
due to internal politics and external commercial realities.  I was trying 
to get them to release the algorithm in SENECA publicly, knowing the 
hardware implementation was failing in the marketplace, but was told it 
wasn't going to happen as it incorporated design features that DSD 
considered sensitive.  The actual design came out of DSTO.

Ian. 


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From I.Brown at cs.ucl.ac.uk  Tue Sep 21 02:05:41 2004
From: I.Brown at cs.ucl.ac.uk (Ian Brown)
Date: Tue, 21 Sep 2004 07:05:41 +0100
Subject: They Said It Couldn't Be Done
In-Reply-To: <414F4A07.5060702@gmx.co.uk>
References: <p061104abbd7203207609@[66.149.49.5]> <414F4A07.5060702@gmx.co.uk>
Message-ID: <414FC4B5.3090103@cs.ucl.ac.uk>

 > [snip HAVA quote and Nevada news]
> So unless there is a amendment to that law (that I am obviously unaware 
> of) it isn't up to individual States to add this as an additional 
> requirement - its already required. perhaps someone could enlighten me?

I believe many e-voting machines "meet" this requirement by printing out 
a tally of votes *when the election has closed* -- and so the voter 
doesn't get to check that the paper record actually matches the vote 
they intended to cast :(
-- 
+44 7970 164 526 / http://www.cs.ucl.ac.uk/staff/I.Brown/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From djm at mindrot.org  Tue Sep 21 02:42:37 2004
From: djm at mindrot.org (Damien Miller)
Date: Tue, 21 Sep 2004 16:42:37 +1000
Subject: Time for new hash standard
In-Reply-To: <p06110460bd73d189d8a2@[66.149.49.5]>
References: <p06110460bd73d189d8a2@[66.149.49.5]>
Message-ID: <414FCD5D.8010207@mindrot.org>

R. A. Hettinga wrote:

>  Luckily, there are alternatives. The National Institute of Standards and
> Technology already has standards for longer - and harder to break - hash
> functions: SHA-224, SHA-256, SHA-384, and SHA-512. They're already
> government standards, and can already be used. This is a good stopgap, but
> I'd like to see more.

I haven't seen any discussion on constructions based on "universal
hashing", like the UHASH underlying UMAC[1]. Can any cryptographers
comment on this?

UMAC seems like a particularly nice MAC, because it is supposedly
provably-secure (to the extent that AES is) and benefits from hardware
speedups to AES.

-d

[1] http://www.cs.ucdavis.edu/~rogaway/umac/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Tue Sep 21 10:17:39 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Tue, 21 Sep 2004 10:17:39 -0400
Subject: America Online To Launch Secure Password Service
Message-ID: <p061104c8bd75e0c46ce6@[66.149.49.5]>

<http://online.wsj.com/article_print/0,,BT_CO_20040921_000016,00.html>

The Wall Street Journal


 September 21, 2004

 UPDATE: America Online To Launch Secure Password Service


DOW JONES NEWSWIRES
September 21, 2004


(Adds VeriSign announcement and comments from expert in paragraphs four
through nine, and additional comment in paragraphs 14-15.)
   By Riva Richmond
   Of DOW JONES NEWSWIRES

NEW YORK -- Password-generating devices long used by employees to securely
access corporate networks are finally coming to consumers.

Citing increased concerns among customers about rising identity theft
online, Time Warner Inc. (TWX) unit America Online said it will launch on
Tuesday a new, paid service that will allow members to log into their AOL
accounts using devices, or "tokens," made by RSA Security Inc. (RSAS).

The gadgets, which can be put on a keychain, display six-digit passcodes
that change every 60 seconds and are synchronized with AOL's servers,
making it nearly impossible for fraudsters to access accounts with stolen
passwords.

Also on Tuesday, VeriSign Inc. (VRSN) plans to launch two token products
that would compete with RSA. But the company, acknowledging that its rival
has largely wrapped up the corporate market for remote employees' use,
plans to market its devices to companies, particularly banks, as something
business partners and customers could use to access corporate networks more
safely.

For instance, VeriSign is in negotiations with two financial-services firms
that are interested in providing tokens to partner firms and high net worth
clients. It has also worked with i-SAFE, a non-profit group that promotes
safe Internet use for children, in a pilot program to provide students
tokens that allow them to enter age-restricted chat rooms and access
college Web sites where they can securely take tests. They hope to get
government funding to take the project nationwide.

Both of VeriSign's tokens plug into computers' USB ports and use smartcard
technology, which can store multiple digital credentials. One of the tokens
also has a screen that displays a changing six-digit passcode.

The new interest in bringing so-called "strong authentication" to consumers
reflects the significantly more hostile Internet they now face. Consumers
have found themselves under assault from a wave of viruses, phishing
attacks and spyware programs designed to steal their personal financial
information for use in identity-theft fraud.

"We've seen the threats now changing to target individuals because they're
not as sophisticated" as corporations, says Howard Schmidt, former White
House cybersecurity czar.

"The way to solve these (problems) in a fairly easy manner is by strong
authentication," he said. "Hacking can be reduced because people can't log
in as other people. Fraud goes down because you have the ability to do
instant validation.... If people can't harvest user IDs and passwords,
phishing becomes irrelevant."

AOL, Dulles, Va., said its main goal is to better protect its members, who
use their accounts to make financial transactions and take care of other
sensitive business, from such blights. AOL has been providing the devices
to customers who called its agents expressing fears about the security of
their accounts, making these members part of the company's testing effort.

"The impetus here really has to do with the deluge of spammers, scammers,
con artists, phishers, hackers and other malcontents that are trying to
dupe consumers into giving up their passwords or the security of their
accounts," said AOL spokesman Nicholas J. Graham. "It's another virtual
deadbolt on the front door of their online experience."

AOL already provides its members with free anti-spyware technology,
parental controls, pop-up blocking and spam filtering. It also scans
incoming and outgoing e-mail for viruses for free, while offering a
"premium" full-blown antivirus service. Both services are provided by
McAfee Inc. (MFE).

For now, however, AOL's service won't allow "single sign-on" into other Web
sites, such as banks and e-commerce sites, where members do business.
Members who sign up for AOL's service, dubbed AOL PassCode, will be
prompted when logging into AOL to enter the number shown on the token along
with their screen name and normal password. AOL will charge subscribers
$9.95 for each device and a monthly service fee of $1.95 to $4.95,
depending on how many devices are associated with account screen names.

But Schmidt thinks AOL's move will add momentum behind a move to this sort
of "federated identity," where one digital credential is recognized by
multiple companies' Web sites, particularly since Microsoft Corp. (MSFT) is
building support for RSA tokens into the next version of its Windows
operating system.

"That's the vision, and I think that's realistic sooner than later," he said.


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From dan at geer.org  Tue Sep 21 17:36:46 2004
From: dan at geer.org (dan at geer.org)
Date: Tue, 21 Sep 2004 17:36:46 -0400
Subject: Academics locked out by tight visa controls 
In-Reply-To: Your message of "Mon, 20 Sep 2004 16:07:55 MDT."
             <6.1.2.0.2.20040920153228.0676a870@mail.comcast.net> 
Message-ID: <20040921213646.7CBC641E0E@absinthe.tinho.net>


Lynn (or anyone) -- I have a small question of
history, viz., when Rome was in its heyday what
sort of rules and so forth did it have about
citizens versus non-citizens in the city?  This
is not to start a long thread, or so I hope, but
if there is a lesson of history rather than
speculation perhaps this would be a good moment
to call for it to be remembered.  Modify the 
"Rome" to any place else if the lesson thus
improves in predictive value.

--dan


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Tue Sep 21 17:27:38 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Tue, 21 Sep 2004 17:27:38 -0400
Subject: Airlines Told to Turn Over Passenger Data
Message-ID: <p06110433bd764d20d33a@[66.149.49.5]>

<http://apnews.myway.com/article/20040921/D8586D6G1.html>

My Way News

Airlines Told to Turn Over Passenger Data

Sep 21, 1:36 PM (ET)

By LESLIE MILLER


WASHINGTON (AP) - The Transportation Security Administration announced on
Tuesday that it will order domestic airlines to turn over personal
information about passengers to test a system that will compare their names
to those on terrorist watch lists.

 The system, called Secure Flight, replaces a previous plan that would have
checked passenger names against commercial databases and assigned a risk
level to each. That plan, which cost $103 million, was abandoned because of
privacy concerns and technological issues.

 The airlines will have 30 days to comment on the proposed order, which
Congress gave the TSA authority to issue. Air carriers will then have 10
days to turn over data that it gathered in June, called passenger name
records.

 The amount of data in passenger name records varies by airline, but it
typically includes name, flight origin, flight destination, flight time,
duration of flight and form of payment. It can also include credit card
numbers, address, telephone number and meal requests, which can indicate a
person's ethnicity.

 Justin Oberman, who heads the office that's developing Secure Flight, said
he hopes that the program can be implemented by mid to late spring. He said
he expects the airlines to cooperate.

 "We are going to work very closely with them," Oberman said.

 The TSA will also conduct a limited test in which they'll compare
passenger names with information from commercial databases to see if they
can be used to detect fraud or identity theft.


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From ben at algroup.co.uk  Wed Sep 22 09:40:08 2004
From: ben at algroup.co.uk (Ben Laurie)
Date: Wed, 22 Sep 2004 14:40:08 +0100
Subject: public-key: the wrong model for email?
In-Reply-To: <414CD2DF.6010002@nma.com>
References: <41488C5D.8050205@nma.com> <6.1.2.0.2.20040915181029.05be2ac0@mail.comcast.net> <41492278.3090303@nma.com> <6.1.2.0.2.20040916102815.04395c70@mail.comcast.net> <4149E13C.7060102@nma.com> <414C3E22.2010306@algroup.co.uk> <414CD2DF.6010002@nma.com>
Message-ID: <415180B8.3070308@algroup.co.uk>

Ed Gerck wrote:
> Ben Laurie wrote:
> 
>> Ed Gerck wrote:
>>
>>> If the recipient cannot in good faith detect a key-access ware, or a
>>> GAK-ware, or a Trojan, or a bug, why would a complete background
>>> check of the recipient help?
>>
>>
>> Let's assume for a moment that a solution exists that satisfies your 
>> requirements. Since the recipient _must_ be able to read the document 
>> in the end, and is assumed to be incapable of securing their software, 
>> then the document is still available to third parties without the 
>> consent of the sender, is it not?
> 
> 
> The recipient was not assumed to be entirely incapable of securing his
> software. The recipient can be trusted to do a number of things that are
> basic, for example, to operate an email software. In fact, we can even
> assume a pretty sophisticated recipient, trained to use all the security
> email software systems commercially available. Still, the recipient will
> be incapable of verifying whether his RSA private-key is weak or not. Thus,
> even fully unwillingly and under best efforts, the recipient can put the
> sender's message security at risk when using that recipient's RSA public-
> key.

Since they are using good software, the key is known to be strong, surely?

>> It seems to me that fixing the PK "problem" would in no way improve 
>> the senders situation given that threat model.
> 
> The sender's situation can be improved mostly when the sender trusts the
> least possible (ideally, nothing) regarding message security. In other
> words, the sender would like to avoid anything that is not under control or
> cannot be directly verified by the sender. Doing a background check of the
> recipient is orthogonal to the PK problem. It does not help nor solve it.

I didn't suggest a background check would help. I am suggesting that if 
you cannot rely on the recipient (or their machine) to manage keys 
properly, then you also cannot rely on them to manage decrypted emails 
properly.

Cheers,

Ben.

-- 
ApacheCon! 13-17 November! http://www.apachecon.com/

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"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 majordomo at metzdowd.com


From kelsey.j at ix.netcom.com  Wed Sep 22 10:08:42 2004
From: kelsey.j at ix.netcom.com (John Kelsey)
Date: Wed, 22 Sep 2004 10:08:42 -0400 (GMT-04:00)
Subject: Time for new hash standard
Message-ID: <2587396.1095862123465.JavaMail.root@ernie.psp.pas.earthlink.net>

>From: Ian Farquhar <ianf at dreamscape.com.au>
>Sent: Sep 20, 2004 10:14 PM
>To: "\"Hal Finney\"" <hal at finney.org>, cryptography at metzdowd.com, 
>	nelson at crynwr.com
>Subject: Re: Time for new hash standard

>At 05:43 AM 21/09/2004, Hal Finney wrote:
>>I believe this is a MAC, despite the name.  It seems to be easier to
>>create secure MACs than secure hash functions, perhaps because there are
>>no secrets in a hash, while in a MAC there is a secret key that makes
>>the attacker's job harder.

>Interestingly, a crypto-specialist from DSD (Australian NSA-equivalent) 
>said exactly this to me in 1997-1998.  He called them "strange" functions 
>to design. I subsequently asked if they - which in the context meant the 
>tier one UKUSA agencies - had many hash functions developed for classified 
>uses.  He indicated that they had quite a few MAC-style keyed functions, 
>but not many unkeyed hashes.

Note that in the open world, there are very nice security proofs for existing MACs based on combining universal hashing with strong crypto components (such as block ciphers).  I gather that the classified world isn't as enamored of security proofs as we are, but it's pretty easy to see that it's harder to find a colliding pair of messages when you don't know the internal state, for almost any nontrivial function.  Even if you're doing a differential attack on the function, you can choose message blocks to make sure that your differential clears some rounds with probability one, and you get to do all your trial hashes offline, on your own equipment, rather than online on your intended victim's equipment.  

>Ian. 

--John


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From egerck at nma.com  Wed Sep 22 10:55:08 2004
From: egerck at nma.com (Ed Gerck)
Date: Wed, 22 Sep 2004 07:55:08 -0700
Subject: public-key: the wrong model for email?
In-Reply-To: <415180B8.3070308@algroup.co.uk>
References: <41488C5D.8050205@nma.com> <6.1.2.0.2.20040915181029.05be2ac0@mail.comcast.net> <41492278.3090303@nma.com> <6.1.2.0.2.20040916102815.04395c70@mail.comcast.net> <4149E13C.7060102@nma.com> <414C3E22.2010306@algroup.co.uk> <414CD2DF.6010002@nma.com> <415180B8.3070308@algroup.co.uk>
Message-ID: <4151924C.9080402@nma.com>


Ben Laurie wrote:
> <snip> I am suggesting that if 
> you cannot rely on the recipient (or their machine) to manage keys 
> properly, then you also cannot rely on them to manage decrypted emails 
> properly.

Yes. This thread is about the observation that, even if the recipient
manages keys perfectly well, the recipient may not know he is
compromising the sender's security. The sender is in the recipient's
hands with PKC, whereas the sender usually has most (if not all) the
risk.

Cheers,
Ed Gerck

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From adam at homeport.org  Wed Sep 22 13:31:45 2004
From: adam at homeport.org (Adam Shostack)
Date: Wed, 22 Sep 2004 13:31:45 -0400
Subject: Academics locked out by tight visa controls
In-Reply-To: <20040921213646.7CBC641E0E@absinthe.tinho.net>
References: <6.1.2.0.2.20040920153228.0676a870@mail.comcast.net> <20040921213646.7CBC641E0E@absinthe.tinho.net>
Message-ID: <20040922173144.GB45471@lightship.internal.homeport.org>

Hi Dan,

   Not Rome, but in Athens, Pericles said, in his funeral oration:

"The freedom which we enjoy in our democratic government extends also
to our ordinary life. We throw open our city to the world, and never
by alien acts exclude foreigners from any opportunity of learning or
observing although the eyes of an enemy may occasionally profit by our
liberality. We live exactly as we please and yet are just as ready to
encounter every legitimate danger. If with habits not of labor but of
ease, and courage not of art but of nature, we are still willing to
encounter anger, we have the double advantage of not suffering
hardships before we need to, and of facing them in the hour of need as
fearlessly as those who are never free from them. The price of courage
will surely be awarded most justly to those who best know the
difference between hardship and pleasure and yet are never tempted to
shrink from danger. And it is only democratic people who, fearless of
consequences, confer their benefits not from calculations of
expediency but in the confidence of liberality. Judging happiness to
be the fruit of freedom and freedom of valor never decline the dangers
of war."

This has been at the top of my personal web page for most of the last
3 years.

Adam

On Tue, Sep 21, 2004 at 05:36:46PM -0400, dan at geer.org wrote:
| 
| Lynn (or anyone) -- I have a small question of
| history, viz., when Rome was in its heyday what
| sort of rules and so forth did it have about
| citizens versus non-citizens in the city?  This
| is not to start a long thread, or so I hope, but
| if there is a lesson of history rather than
| speculation perhaps this would be a good moment
| to call for it to be remembered.  Modify the 
| "Rome" to any place else if the lesson thus
| improves in predictive value.
| 
| --dan
| 
| 
| ---------------------------------------------------------------------
| The Cryptography Mailing List
| Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From perry at piermont.com  Wed Sep 22 13:31:02 2004
From: perry at piermont.com (Perry E. Metzger)
Date: Wed, 22 Sep 2004 13:31:02 -0400
Subject: Enigma-E
Message-ID: <87d60ecisp.fsf@snark.piermont.com>


Always wanted an Enigma but the finite supply on the open market a
bother? Well, now you can get a PC board kit for constructing an
electronic version of the old World War II favorite! You'll have to
make the wooden case yourself, though.

http://www.xat.nl/enigma-e/index.htm

Perry
PS Hat tip to J.I. for pointing this out to me.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From astiglic at okiok.com  Wed Sep 22 21:30:16 2004
From: astiglic at okiok.com (Anton Stiglic)
Date: Wed, 22 Sep 2004 21:30:16 -0400
Subject: Time for new hash standard
In-Reply-To: <20040920194356.EC32357E2B@finney.org>
Message-ID: <20040923013014.7D9A1B409B@mail.okiok.com>

I believe hash127 acts like an almost universal family of hash functions,
thus the word hash in it makes sense even though it is a MAC (but I might
not be recalling properly).

About MACs being easier to build, I agree it seems to be easier because of
the secret key involved.

If you don't like SHA1, I would suggest SHA-225/256/384/512, or something
based on a different design philosophy such as Tiger.  Another interesting
alternative is hash functions based on a block cipher such as AES.

--Anton

-----Original Message-----
From: owner-cryptography at metzdowd.com
[mailto:owner-cryptography at metzdowd.com] On Behalf Of "Hal Finney"
Sent: 20 septembre 2004 15:44
To: cryptography at metzdowd.com; nelson at crynwr.com
Subject: Re: Time for new hash standard

Bruce Schneier wrote:
>  Luckily, there are alternatives. The National Institute of Standards and
> Technology already has standards for longer - and harder to break - hash
> functions: SHA-224, SHA-256, SHA-384, and SHA-512. They're already
> government standards, and can already be used. This is a good stopgap, but
> I'd like to see more.

Russell Nelson suggested:
> http://cr.yp.to/antiforgery.html#hash127

I believe this is a MAC, despite the name.  It seems to be easier to
create secure MACs than secure hash functions, perhaps because there are
no secrets in a hash, while in a MAC there is a secret key that makes
the attacker's job harder.

Hal

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From hadmut at danisch.de  Thu Sep 23 04:58:16 2004
From: hadmut at danisch.de (Hadmut Danisch)
Date: Thu, 23 Sep 2004 10:58:16 +0200
Subject: M-209 broken in WWII
Message-ID: <20040923085815.GA21845@danisch.de>

Hi,

it is well known that british and polish scientists
had broken the german enigma in WWII. 

For those who can read german, there's an interesting
article on

  http://www.heise.de/tp/deutsch/inhalt/co/18371/1.html

about how the germans broke the M-209 used by the US.
They found a man who was involved.


regards
Hadmut



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Thu Sep 23 09:10:14 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Thu, 23 Sep 2004 09:10:14 -0400
Subject: Hack Attack Gums Up Authorize.Net
Message-ID: <p0611048bbd787b92b86d@[66.149.49.5]>

<http://www.wired.com/news/print/0,1294,65039,00.html>

Wired News

Hack Attack Gums Up Authorize.Net 
By Noah Shachtman

Story location: http://www.wired.com/news/infostructure/0,1377,65039,00.html

01:56 PM Sep. 21, 2004 PT

Hackers have crippled one of the internet's biggest credit card processors,
and tens of thousands of online merchants are losing business while the
company struggles to recover.

 Since last Wednesday, Authorize.Net has been relentlessly pounded by
distributed denial of service, or DDoS, attacks. The massive, coordinated
waves of internet traffic have repeatedly overwhelmed the company's
servers. Authorize.Net's customers have had to improvise: Some are
confirming their credit card orders over the phone, others have gone with
little or no sales for nearly a week.


 "I'm losing four grand a day in revenue," said David Hoekje, president of
PartsGuy.com, an online heating and air conditioning parts dealer. "My year
is a bell curve, and we're on the upwards slope now. This is 5 percent of
my year, gone."

 As of Tuesday afternoon, there still seemed to be no end in sight to the
hacker strikes against Authorize.Net. Security experts say that there's
little a company can do to defend itself against these kinds of attacks.

 But company officials insist they're trying. "We're actively trying to
deal with it. And we're working hard to minimize the disruptions to our
merchants," Authorize.Net marketing director David Schwartz said. The
company has turned to the FBI, as well as outside consultants, for help, he
added.

 With about 90,000 customers, Authorize.Net is one of the internet's
best-known, most widely used credit card processing services, focusing
mostly on smaller merchants. Earlier this year, the firm was bought by the
Burlington, Massachusetts, online payment and fraud-detection firm
Lightbridge for $82 million.

 But since the sale, Lightbridge has been hit by a series of body blows. In
August, CEO Pamela Reeve resigned; last week, the company announced it was
laying off 65 people -- a 12 percent cut in its workforce. And now, "these
unforeseen and malicious DDoS attacks," as a company message called them.

 "We know how hard it is," said Michael Adberg, co-founder of WeaKnees.com.
The site, which sells TiVo upgrades and DirecTV installations, was itself
the target of a DDoS attack last October. "But we're surprised that such a
large company wasn't better prepared than we were."

 He added, "They have really let us down."

 For the moment, Adberg and his associates have been phoning customers who
place orders over the website, confirming their information and only later
processing their payments with Authorize.Net.

 "But there will be a few customers who we'll ship their orders, and we
won't charge them," Adberg said. "Maybe 10 percent will slip through the
cracks."

 The lost revenue is only part of the problem, however. Even if sales are
saved, the company image can be scuffed by such a move.

 "Imagine placing an order with Amazon, but not being able to pay online,
and then having to call a customer support person so they can charge you,"
said a network chief at one of Authorize.Net's customers.

 The payment processor has been able to take care of some transactions,
through slight modifications to its domain name. But these tactics have
only been partially effective. And, in the long run, wholesale changes to
web addresses are bad for business, explains Drew Copley, a senior research
engineer at eEye Digital Security. "You can lose money, lose customers,
because they can't find you."

 Information from attacking PCs can be slowed down; internet protocol
addresses of other offending computers can be blocked. But, in the face of
a large-scale strike, there's little that can be done, observed Copley, who
built one of the first DDoS tools for Windows.

 "When you get 10,000, 50,000 computers all firing at once, for attacks
like that, there is no simple solution," he added.


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From fw at deneb.enyo.de  Thu Sep 23 17:50:19 2004
From: fw at deneb.enyo.de (Florian Weimer)
Date: Thu, 23 Sep 2004 23:50:19 +0200
Subject: AOL to Sell Secure ID Tags to Fight Hackers
In-Reply-To: <p06110417bd752f5cd7c3@[66.149.49.5]> (R. A. Hettinga's message
	of "Mon, 20 Sep 2004 21:09:10 -0400")
References: <p06110417bd752f5cd7c3@[66.149.49.5]>
Message-ID: <87llf0bqp0.fsf@deneb.enyo.de>

* R. A. Hettinga:

>  PassCode users will be provided with a small handheld six-digit numeric
> code key.
>
>  To log onto an AOL account equipped with the service, users will have to
> type in the six-digits, which refresh on the device every 60 seconds, on
> top of using the regular password.

AOL appears to allow you to disable PassCode for your account, so this
is only of limited usability against phishing scams.  AOL even fails
to stress that you must never enter the PassCode serial number during
the normal login process. 8-(

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From PaulLambert at AirgoNetworks.Com  Fri Sep 24 17:54:48 2004
From: PaulLambert at AirgoNetworks.Com (Paul Lambert)
Date: Fri, 24 Sep 2004 14:54:48 -0700
Subject: Enigma-E
Message-ID: <3FFBC907DD03A34CA4410C5C745DEB1204673A35@wnimail.WoodsideNet.Com>


I've always thaought that the same groups software version 
was pretty cool:
http://www.xat.nl/enigma/sim/

It has an excellent graphical simulation of several versions of Enigma
and is claimed to actually interoperate with real machines.

It only runs on 'RISC OS', so you need to run a virtual Acorn (RISC OS)
Machine: http://www.virtualacorn.co.uk/dloadpage/va5k.htm to run
the very graphical Enigma simulation ....

Paul 


> -----Original Message-----
> From: owner-cryptography at metzdowd.com 
> [mailto:owner-cryptography at metzdowd.com] On Behalf Of Perry E. Metzger
> Sent: Wednesday, September 22, 2004 10:31 AM
> To: cryptography at metzdowd.com
> Subject: Enigma-E
> 
> 
> Always wanted an Enigma but the finite supply on the open 
> market a bother? Well, now you can get a PC board kit for 
> constructing an electronic version of the old World War II 
> favorite! You'll have to make the wooden case yourself, though.
> 
> http://www.xat.nl/enigma-e/index.htm
> 
> Perry
> PS Hat tip to J.I. for pointing this out to me.
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to 
> majordomo at metzdowd.com
> 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From pgut001 at cs.auckland.ac.nz  Sat Sep 25 01:03:03 2004
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Sat, 25 Sep 2004 17:03:03 +1200
Subject: An interesting "new" computer security problem
Message-ID: <E1CB4i7-0005sA-00@medusa01>

A few days ago I was chatting with some people working on a government IT
project who had a rather complex security problem that they needed help with.
They have a large number of users with Windows dumb terminals (think Xterms
but for Windows) connected to a central ASP server, which runs various
mutually untrusted apps from different vendors.  Their problem was that they
needed a means of securing the individual apps from each other.

I told them that they were in luck, and this exact problem had already been
addressed before.  I'd drop off the detailed technical specs for the solution
when I next saw them, they could recognise it by its bright orange cover.

Peter.

(Actually it wasn't quite that simple and easily solveable: The ASP server is
 untrusted as well, it just acts as a middleman for back-ends located at
 various locations, and only the back-ends are trusted.  I figured giving them
 the Orange Book would be easier than trying to explain that they had an
 unsolveable problem on their hands).

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Sat Sep 25 08:21:01 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Sat, 25 Sep 2004 08:21:01 -0400
Subject: Linux-based wireless mesh suite adds crypto engine support
Message-ID: <p0611040cbd7b12ea9dda@[66.149.49.5]>

<http://www.linuxdevices.com/news/NS1975038466.html>

Linux Devices

The leading embedded hardware
& software design magazine


Linux-based wireless mesh suite adds crypto engine support

Sep. 24, 2004
The first commercial software product to exploit the cryptographic
acceleration engine in newer Via processors has hit the market, according
to Via. LocustWorld's MeshAP-Pro is a commercial version of MeshAP, Linux
software for self-organizing networks of wireless access points. MeshAP-Pro
targets larger mesh network operators such as urban service providers.

In addition to selling and supporting MeshAP-Pro software, LocustWorld also
offers blackbox hardware platforms for wireless routers, such as the
MeshBox, a Linux-based mini-ITX system based on Via mini-ITX boards.

LocustWorld sells Linux-based blackboxes for wireless routers based on Via
mini-ITX boards

The processors in newer Via mini-ITX boards based on C5P Nehemiah cores
include the PadLock Hardware Security Suite, which includes the PadLock RNG
(random number generator) and the PadLock ACE (advanced cryptography
engine). PadLock ACE performs low-level processing of the algorithms used
in AES (advanced encryption standard), a kind of cryptography defined by US
government standards.

According to LocustWorld CEO Richard Lander, PadLock engines enabled
LocustWorld to write software that achieves extremely high throughputs of
encrypted data, when run on Via boards or boards from vendors such as
WinSystems, VersaLogic, Yamashita and many others that use Via Centaur
processors. "Using the on-die AES encryption from the latest VIA processors
we can achieve an encryption layer with hardly any overhead on the CPU.
Network performance using the VIA PadLock ACE is close to the speed of
un-encrypted communications, achieving high-strength encryption without the
associated performance impact, even on large networks with high traffic.
The result is virtually transparent encryption," Lander stated.

Via last week released a PadLock SDK (software development kit) for those
interested in using the security-oriented x86 instructions available on Via
processors with PadLock Hardware Security Suite. The kit includes tools,
documentation, and example code that developers can "directly copy into
other programs." Example code includes zip compression utilities, and a
data-scrubber said to make deleted files "virtually unrecoverable."

Via has launched a PadLock Certification Program to assist ISVs
(independent software vendors) in adding PadLock support to their
applications. More details about VIA PadLock initiative are available
online.

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From rah at shipwright.com  Sat Sep 25 11:30:04 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Sat, 25 Sep 2004 11:30:04 -0400
Subject: Passports: al-Qaeda's terror weapons
Message-ID: <p06110416bd7b3f36011f@[66.149.49.5]>

<http://www.abs-cbnnews.com/NewsStory.aspx?section=Focus&oid=56434>

   ABS-CBNNEWS.COM

Sunday, August 1, 2004 11:31 PM

Passports: al-Qaeda's terror weapons

 Vienna, Austria - They're just little embossed rectangles in burgundy,
forest green or navy blue, but they can lay a nation bare to a terrorist
plot.

 Passports, not box cutters or even jetliners, may be al-Qaeda's most
powerful weapons. Stolen and legitimate, doctored and untouched, they have
enabled Osama bin Laden's network and other terror groups to plan and carry
out attacks worldwide.

 In its final report, the US commission investigating the Sept.11 attacks
touts high-tech biometric passports, still in the developmental stage, and
better border guard training as key ways to tighten the United States'
defenses.

 But antiterrorism experts, mindful of the ingenuity demonstrated by
Islamic militants, told The Associated Press they feel humbled and helpless.

 "One of the hidden criticisms [in the report] is that not only were we not
prepared on Sept. 11, but the measures we've taken from Sept. 11 to today
have not improved the matter that much," said Michael Greenberger, who was
a Justice Department official during the Clinton administration.

 "Our databases are a mess. Change a person's middle initial and he doesn't
show up," said Greenberger, who now directs the University of Maryland's
Center for Health and Homeland Security. "By and large, we've not been
terribly successful."

 The commission offers no argument. "No one can hide his or her debt by
acquiring a credit card with a slightly different name," said its report,
released last week. "Yet today, a terrorist can defeat the link to
electronic records by tossing away an old passport and slightly altering
the name in the new one."

 Conceding it has only "fragmentary" evidence of the travels of the Sept.
11 organizers and hijackers, the commission's 567-page report nonetheless
is packed with detailed accounts of how the terrorists obtained and
modified the passports that got them into the United States.

 A key panel recommendation points up the seriousness of the threat:
"Targeting travel is at least as powerful a weapon against terrorists as
targeting their money. The United States should combine terrorist travel
intelligence, operations, and law enforcement in a strategy to intercept
terrorists, find terrorist travel facilitators, and constrain terrorist
mobility."

 That, experts say, is far easier said than done. "If you have someone who
is determined to evade immigration controls, they'll do it -- or at least
they'll have a good chance," said Alex Standish, editor of Jane's
Intelligence Digest. "I don't see any evidence to suggest that we've had
any success in making [al-Qaeda] any less of a threat."

 Al-Qaeda once brazenly operated its own passport office at the airport in
Kandahar, Afghanistan, where the group "altered papers, including
passports, visas and identification cards" before the Sept. 11 attacks on
the World Trade Center and the Pentagon, the commission notes.

 Although the US-led war in Afghanistan ended such Taliban-protected
operations, there are plenty of terrorists worldwide who are skilled in
doctoring documents, the panel warns. It says al-Qaeda and others have
refined half a dozen simple yet highly effective techniques.

 Among the most popular is obtaining stolen passports, which authorities
say are available on a lucrative black market that stretches from Eastern
Europe to Southeast Asia and South Africa.

 There are up to 10 million lost or stolen passports in circulation
worldwide, according to Interpol estimates.

 "You can find all sorts of fake passports in the Balkans, including stolen
or fake American documents, a former high-ranking police official in Serbia
told AP on condition of anonymity.Experts say they're being sold for as
little as US$75, although US passports can fetch US$3,000 or more.

 Al-Qaeda militants and other terrorists intercepted in Europe had obtained
South African passports they apparently got from crime syndicates operating
within the government agency that issues the documents, officials disclosed
to AP last week.

 Another commonly used technique involves adding or removing visa cachets
and entry and exit stamps. By doing so, experts say, terrorists can delete
any evidence of their travel to suspicious destinations such as Afghanistan
or Pakistan. They also can create false trails to throw authorities off
track.

 Two of the Sept. 11 hijackers, Nawaf al Hazmi and Khalid al Mihdhar,
apparently flew to Bangkok because "they thought it would enhance their
cover as tourists to have passport stamps from a popular tourist
destination such as Thailand," the commission says.

 Some simply would turn in passports filled with suspicion-arousing visas
and stamps from countries where al-Qaeda operated -- even if the documents
were still valid for another year -- and get new, clean ones. Fourteen of
the 19 suicide hijackers, exhorted by Sept. 11 mastermind Khalid Sheikh
Mohammed, obtained new passports. Others work to acquire as many passports
as possible, reasoning that a Canadian or Belgian passport is less likely
to prompt scrutiny from US border guards than one from Saudi Arabia.

 In one case cited by the commission, convicted terrorist Ahmed Ressam
obtained a blank baptismal certificate that a document vendor had stolen
from a Roman Catholic Church in Montreal, and used it to get a genuine
Canadian passport. Saudi hijackers had a problem: If they traveled to
Afghanistan via Pakistan, and the Pakistanis stamped their passports, they
risked having them confiscated back in Saudi Arabia.

 "So operatives either erased the Pakistani visas from their passports or
traveled through Iran, which did not stamp visas directly into passports,"
the commission says. Tehran has angrily denied any complicity in the Sept.
11 attacks, even though the panel contends up to 10 of the hijackers passed
through Iran en route to the United States.

 Al-Qaeda operative Tawfiq bin Attash indicated that Malaysia repeatedly
was used as a place to plot attacks "because its government did not require
citizens of Saudi Arabia or other Gulf states to have a visa." Bin Attash,
better known as Khallad, helped bomb the USS Cole in Yemen in October 2000,
killing 17 American sailors.

 Greenberger is among many pushing for the swift consolidation of travel
databases "so these names start popping up." He and others also are
pressing for the introduction of supposedly tamper-proof biometric
passports that will contain digital photographs and fingerprints.

 The European Union agreed in March to fast track the inclusion of
biometric data in passports by the end of 2006. Belgium has vowed to be
among the first by introducing its new travel documents next year, and
Austria, Denmark and Slovenia have developed working prototypes.

 "We've got to adopt the technology and get away from purely paper
documents," Greenberger said. "Nothing is going to be foolproof, but by
altering the technology, I think it's possible to raise our defenses," he
said. "The harder we make it to forge documents, the greater our gains in
protecting the borders. You're really upping the ante."

 But Standish, of Janes' Intelligence Digest, is skeptical. "The basic
problem is that if a document of any kind can be produced, it can be
falsified or forged," he said. "As an IRA terrorist once famously said to
the authorities: `You have to be lucky all the time. I only have to be
lucky once."'


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From rah at shipwright.com  Sat Sep 25 20:32:19 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Sat, 25 Sep 2004 20:32:19 -0400
Subject: Now we are 8 (and this token proves it)
Message-ID: <p061104aebd7bbe55cd27@[66.149.49.5]>

<http://www.theregister.co.uk/2004/09/24/verisign_age_verification_token/print.html>

The Register


 Biting the hand that feeds IT

 The Register ? Security ? Identity ?

 Original URL:
http://www.theregister.co.uk/2004/09/24/verisign_age_verification_token/

Now we are 8 (and this token proves it)
By Thomas C Greene (thomas.greene at theregister.co.uk)
Published Friday 24th September 2004 14:02 GMT

VeriSign announced a new USB token that verifies the ages and sexes of
children using a computer, and claimed that this will make it easier for
innocent sprouts to avoid online predators, Reuters reports.

"Chatroom lurkers who can't prove their age will stick out like sore thumbs
as more kids adopt the tokens," the wire service explained.

The so-called i-Stik USB token will provide verification of a child's age
and sex. School administrators will provide lists of students, with their
dates of birth and sexes, and VeriSign will encode that information onto
the i-Stick tokens.

The scheme will begin with a handful of schools for testing this Fall, and,
if all goes according to plan, be extended to thousands of schools starting
next Spring.

That is, assuming its glaring flaws don't become painfully evident by that
time. Most obviously, the token will not verify age or sex of the person
using it, but only of the person to whom it was issued. Anyone might be
using it, and no doubt paedos will be scrambling to get their hands on one
of their own, either through loss, theft, or bribery. Once the tokens
become popular and widely available, one can expect a brisk trade in them
on paedo bulletin boards.

(Naturally, the Feds will have to be supplied with plenty of these gizmos,
so that they can spend their days hanging out in kids' chatrooms with
better cover.)

Meanwhile, parents will be lulled further into foolish notions that an
Internet-connected PC makes for an adequate electronic babysitter. The
Internet is adult space, and there is no substitute for parental
supervision. If this scheme does anything to produce a false sense of
security among parents, then it's worse than nothing; it's actually
dangerous.

One thing that the tokens will be good for is online marketing to children.
Marketers will be able to get a more accurate sense of the ages and sexes
of young visitors to various online venues, and target them more precisely.

It will also make for decent PR and corporate image-making for VeriSign,
suggesting that the company takes the safety of children seriously. Most
importantly, it will produce a nice revenue stream from a basically
worthless product that school districts will purchase with tax dollars.

In all, it's a win/win gimmick and publicity stunt, so long as child safety
is not a criterion for judging its success. ?

Thomas C Greene is the author of Computer Security for the Home and Small
Office (http://basicsec.org), a comprehensive guide to system hardening,
malware protection, online anonymity, encryption, and data hygiene for
Windows and Linux.

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From rah at shipwright.com  Sat Sep 25 21:03:27 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Sat, 25 Sep 2004 21:03:27 -0400
Subject: Mystification of Identity: You Say Yusuf, I Say Youssouf...
Message-ID: <p061104bfbd7bc4052267@[66.149.49.5]>

Gilmore, et al., are right, as always.

If you've been all-but cavity-searched -- okay, virtually
cavity-searched, given the state of modern X-Ray airport passenger
scanning technology -- and you don't have a weapon, exactly *how* is
knowing *who* you are going to affect your ability to hijack an
airplane?

I see nothing but the continuation of the privatization of air travel
from all this nonsense. More NetJet owners, more Marquis
Card-carrying business travellers, more investment capital for
companies like Eclipse Aviation.

Geodesic aviation, anyone? ;-)

Cheers,
RAH
-------

<http://www.time.com/time/nation/printout/0,8816,702062,00.html>

TIME.com Print Page: Nation --


 Saturday, Sep. 25, 2004
You Say Yusuf, I Say Youssouf...
The Cat Stevens incident has its origins in a spelling mistake
By  SALLY B. DONNELLY

 The Yusuf Islam incident earlier this week, in which the former Cat
Stevens was denied entry into the U.S. when federal officials
determined he was on the government's "no-fly" antiterror list,
started with a simple spelling error. According to aviation sources
with access to the list, there is no Yusuf Islam on the no-fly
registry, though there is a "Youssouf Islam." The incorrect name was
added to the register this summer, but because Islam's name is
spelled "Yusuf" on his British passport, he was allowed to board a
plane in London bound for the U.S. The Transportation Safety
Administration alleges that Islam has links to terrorist groups,
which he has denied, British foreign minister Jack Straw said the TSA
action "should never have been taken."

 The incident points up some of the real problems facing security
personnel as they try to enforce the "no-fly" list. One issue is
spelling; many foreign names have several different transliterations
into English. And the sheer size of the list is daunting; thousands
of names have been added in the last couple months, says one
government official, bringing the total up to more than 19,000 people
to look out for. That makes it difficult for airlines and government
agencies to check all passengers. Within the past six months, several
people on the no fly list have been mistakenly allowed to fly.

 Still, the TSA is learning. It recently acknowledged that a Federal
Air Marshall, unable to fly for weeks when his name was mistakenly
put on the "no-fly" list, was in fact not a threat, and removed his
name from the list.



-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From rah at shipwright.com  Sun Sep 26 18:57:21 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Sun, 26 Sep 2004 18:57:21 -0400
Subject: Under the hood of FIPS 140-2 Validations
Message-ID: <p0611048abd7cf98dafc5@[66.149.49.5]>

<http://www.cr80news.com/library/2004/09/26/under-the-hood-of-fips-1402-validations/>

 : CR80 News

Under the hood of FIPS 140-2 Validations
Sunday, September 26 2004

by John Morris, president and co-founder of Corsec Security, Inc.

In our last article (SecureIDNews, August 2004) we covered what FIPS 140-2
and Common Criteria are at a high level. We introduced you to what these
standards are, why we need them, who the players are, what the process is,
as well as some of the common terms that you will need to know along the
way. Now let's delve into what's actually involved in getting FIPS 140-2.
In the next article, we'll do the same for Common Criteria.



What is FIPS 140-2 again?

As we learned last time, FIPS 140-2 dictates that the cryptographic parts
of a product are designed, documented, and can be operated in a secure
manner to the government's satisfaction. So FIPS 140-2 is a standard
mandated for US federal government purchases, strictly enforced in Canada,
and followed in various forms by many other governments worldwide. Widely
adopted among financial institutions, the standard is becoming an
international mark for cryptographic quality.

But who sets the rules and who measures results?

 FIPS 140-2 is short for "Federal Information Processing Standards
Publication." The documents are published by the National Institutes of
Standards and Technologies (NIST) in the US. In particular FIPS 140-2 was
published by NIST with the cooperation of the Communications Security
Establishment (CSE) in Canada. NIST and CSE created a joint effort called
the Cryptographic Module Validation Program (CMVP) to specifically manage
the FIPS 140-2 process.

What is the purpose of this program?

CMVP, issues validation certificates that let purchasers know if products
(cryptographic modules) actually meet the FIPS 140-2 requirements. It is
important to understand that this program focuses only on the parts of the
product that utilize cryptography. These are the "cryptographic engines"
that power the security in all types of products. It's often difficult or
impossible for an end consumer to lift the product's hood and examine the
cryptographic engine and ensure it truly works the way it is supposed to.
Therefore, the CMVP program ensures that detailed testing an analysis is
performed, and only those products that meet the claims are listed on the
validation lists.

How does CMVP do this?

 CMVP accredits independent labs (commercial companies) to run a specific
set of tests and report to the government on the output of those tests. The
body that accredits the testing labs is called the National Voluntary
Laboratory Accreditation Program, or NVLAP. Initially NVLAP accredited
three laboratories to ensure commercial competition (one of which I
managed). However, as industry demand and international interest has grown,
so to has the number of labs. Currently, CMVP oversees nine testing labs
across the US, Canada, and United Kingdom.

How do the testing labs work?

 Testing labs are independent, for-profit organizations, so they compete
for the vendors' business. They are all governed by the same sets of rules
and regulations and hopefully produce the same end result in judging
cryptographic engines. However, the process and procedures they use to
achieve the results and how they evaluate documentation, design, and
products vary. This is part of the reason that CMVP provides multiple
laboratories to satisfy the needs of the competitive commercial
marketplace, allowing vendors to compare laboratories on location, prices,
responsiveness, resources, etc. But to ensure consistent quality testing
the CMVP periodically monitors laboratory quality and prohibits testing
labs from consulting on product design or creating documents for products
they test. While laboratories can offer some guidance as to what the
standard requires, they may not advise a vendor on how to relate that
guidance to their specific product. There are separate consultants (such as
my company, Corsec) that specialize in helping vendors in these areas.

Vendors complain FIPS 140-2 is too hard - is it necessarily?

A FIPS 140-2 validation entails significant effort for a vendor before,
during and after the vendor chooses the lab. They must verify that their
product design is compliant to the requirements in the standard. If not,
then design changes will have to be made before the product goes through
testing. Next, the vendor has to produce a large body of documentation that
explains how the product meets cryptographic security requirements, how its
design complies with them, and how it will behave in specific situations.
The CMVP program requires very specific documents be submitted in
particular formats. This means the vendors or their consultants must spend
significant efforts producing documentation for FIPS 140-2 that they would
not otherwise produce. Most vendors are not practiced in producing FIPS
140-2 Security Policies, Finite State Machines, or Vendor Evidence
documents and may either spend more effort than laboratories require under
FIPS 140-2, or include the wrong information. However, with the right focus
in the documents, a vendor's product can be quickly evaluated by a
laboratory, and efforts significantly reduced.

The documents have been submitted, the testing has been done - so now what?

Once the commercial testing has been performed, the CMVP reviews the test
report and Security Policy as part of their quality control. Assuming the
vendor responds promptly and correctly to government questions, CMVP will
sign a validation certificate for the tested version of the product, and
post it on their web site. In the past, lack of staffing and funding, and
sharp growth in FIPS 140-2 testing has caused delays in the government's
ability to process test reports - another source of vendor complaints.
Although still woefully under-funded despite the recent focus on
communications security, the CMVP has avoided the huge delays folks like
INS have suffered, and continues to streamline the process.

 What does this mean to the purchaser?

Government or Financial Services industry purchasers who are required to
purchase only FIPS 140-2 validated products have begun using validated
lists as shopping lists. They help narrow the playing field when comparing
similar types of products. If one has been validated and another has not,
the purchaser must choose the one with the FIPS 140-2 certificate.

Thus, the validated products lists show which products have proven they
meet FIPS 140-2 requirements for cryptographic security. It tells you that
qualified, independent cryptographic "mechanics" have looked under the hood
of the product and ensured the engine is soundly designed, well
implemented, and running smoothly. More and more, this assurance is
becoming a basic requirement of purchasers inside and outside the
government. Vendors have noted this, and the list of validated vendors
reads like a who's who of serious players in the market. These days,
gaining a FIPS 140-2 validation also tells purchasers that a vendor is
committed to security, as validations are typically far from cheap, fast,
or easy.

Next month, we will cover the testing process for Common Criteria and how
it relates to FIPS 140-2 validation. In the meantime, you can read more
about FIPS 140-2 requirements at  www.corsec.com/fips_center.php, or
contact me at jmorris at Corsec dot com.



About the author

John Morris is president and co-founder of Corsec Security, which offers
consulting services for Common Criteria and FIPS 140-2 product validations.
Mr. Morris is the former manager of a NVLAP-accredited testing laboratory,
and has worked for the last decade in cryptography, public key
infrastructure and security engineering with a focus on government security
validations. You can read a Q/A by Mr. Morris in Corsec's monthly
e-newsletter by visiting www.corsec.com/news.php. Questions can be
submitted to info at corsec.com.

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From lynn at garlic.com  Mon Sep 27 14:58:31 2004
From: lynn at garlic.com (Anne & Lynn Wheeler)
Date: Mon, 27 Sep 2004 12:58:31 -0600
Subject: An interesting "new" computer security problem
In-Reply-To: <E1CB4i7-0005sA-00@medusa01>
References: <E1CB4i7-0005sA-00@medusa01>
Message-ID: <6.1.2.0.2.20040927125349.0330ffb8@mail.comcast.net>

note that was being done with virtual machines in the 60s .... well before 
the orange book

there were also a number of commercial time-sharing companies offering 
services based on virtual machine technology where possibly mutually 
antagonistic clients were using the services.

we had a service that had some of the most sensitive corporate secrets 
there were .... on the same machine with all sorts of BU, MIT, and harvard 
students.

random past references to some of the in-house as well as commerical 
(virtual machine based) time-sharing services from the 60s & 70s:
http://www.garlic.com/~lynn/subtopic.html#timeshare


At 11:03 PM 9/24/2004, Peter Gutmann wrote:
>A few days ago I was chatting with some people working on a government IT
>project who had a rather complex security problem that they needed help with.
>They have a large number of users with Windows dumb terminals (think Xterms
>but for Windows) connected to a central ASP server, which runs various
>mutually untrusted apps from different vendors.  Their problem was that they
>needed a means of securing the individual apps from each other.
>
>I told them that they were in luck, and this exact problem had already been
>addressed before.  I'd drop off the detailed technical specs for the solution
>when I next saw them, they could recognise it by its bright orange cover.
>
>Peter.
>
>(Actually it wasn't quite that simple and easily solveable: The ASP server is
>  untrusted as well, it just acts as a middleman for back-ends located at
>  various locations, and only the back-ends are trusted.  I figured giving 
> them
>  the Orange Book would be easier than trying to explain that they had an
>  unsolveable problem on their hands).
>
>---------------------------------------------------------------------
>The Cryptography Mailing List
>Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/
   
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Mon Sep 27 16:59:19 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Mon, 27 Sep 2004 16:59:19 -0400
Subject: Saluting the data encryption legacy
Message-ID: <p061104ecbd7e2f6f522b@[66.149.49.5]>

<http://news.com.com/2102-1029_3-5381232.html?tag=st.util.print>

CNET News
     http://www.news.com/


 Saluting the data encryption legacy

 By  Bruce Schneier

http://news.com.com/Saluting+the+data+encryption+legacy/2010-1029_3-5381232.html


 Story last modified September 27, 2004, 9:00 AM PDT


The Data Encryption Standard, or DES, was a mid-'70s brainchild of the
National Bureau of Standards: the first modern, public, freely available
encryption algorithm. For over two decades, DES was the workhorse of
commercial cryptography.

Over the decades, DES has been used to protect everything from databases in
mainframe computers, to the communications links between ATMs and banks, to
data transmissions between police cars and police stations. Whoever you
are, I can guarantee that many times in your life, the security of your
data was protected by DES.

 Just last month, the former National Bureau of Standards--the agency is
now called the National Institute of Standards and Technology, or
NIST--proposed withdrawing DES as an encryption standard, signifying the
end of the federal government's most important technology standard, one
more important than ASCII, I would argue.

 Today, cryptography is one of the most basic tools of computer security,
but 30 years ago it barely existed as an academic discipline. In the days
when the Internet was little more than a curiosity, cryptography wasn't
even a recognized branch of mathematics. Secret codes were always
fascinating, but they were pencil-and-paper codes based on alphabets. In
the secret government labs during World War II, cryptography entered the
computer era and became mathematics. But with no professors teaching it,
and no conferences discussing it, all the cryptographic research in the
United States was conducted at the National Security Agency.
 In the days when the Internet was little more than a curiosity,
cryptography wasn't even a recognized branch of mathematics.

 And then came DES.

 Back in the early 1970s, it was a radical idea. The National Bureau of
Standards decided that there should be a free encryption standard. Because
the agency wanted it to be non-military, they solicited encryption
algorithms from the public. They got only one serious response--the Data
Encryption Standard--from the labs of IBM. In 1976, DES became the
government's standard encryption algorithm for "sensitive but unclassified"
traffic. This included things like personal, financial and logistical
information. And simply because there was nothing else, companies began
using DES whenever they needed an encryption algorithm. Of course, not
everyone believed DES was secure.

 When IBM submitted DES as a standard, no one outside the National Security
Agency had any expertise to analyze it. The NSA made two changes to DES: It
tweaked the algorithm, and it cut the key size by more than half.

The strength of an algorithm is based on two things: how good the
mathematics is, and how long the key is. A sure way of breaking an
algorithm is to try every possible key. Modern algorithms have a key so
long that this is impossible; even if you built a computer out of all the
silicon atoms on the planet and ran it for millions of years, you couldn't
do it. So cryptographers look for shortcuts. If the mathematics are weak,
maybe there's a way to find the key faster: "breaking" the algorithm.

 The NSA's changes caused outcry among the few who paid attention, both
regarding the "invisible hand" of the NSA--the tweaks were not made public,
and no rationale was given for the final design--and the short key length.

 But with the outcry came research. It's not an exaggeration to say that
the publication of DES created the modern academic discipline of
cryptography. The first academic cryptographers began their careers by
trying to break DES, or at least trying to understand the NSA's tweak. And
almost all of the encryption algorithms--public-key cryptography, in
particular--can trace their roots back to DES. Papers analyzing different
aspects of DES are still being published today.

 By the mid-1990s, it became widely believed that the NSA was able to break
DES by trying every possible key. This ability was demonstrated in 1998,
when a $220,000 machine was built that could brute-force a DES key in a few
days. In 1985, the academic community proposed a DES variant with the same
mathematics but a longer key, called triple-DES. This variant had been used
in more secure applications in place of DES for years, but it was time for
a new standard. In 1997, NIST solicited an algorithm to replace DES.

 The process illustrates the complete transformation of cryptography from a
secretive NSA technology to a worldwide public technology. NIST once again
solicited algorithms from the public, but this time the agency got 15
submissions from 10 countries. My own algorithm, Twofish, was one of them.
And after two years of analysis and debate, NIST chose a Belgian algorithm,
Rijndael, to become the Advanced Encryption Standard.

It's a different world in cryptography now than it was 30 years ago. We
know more about cryptography, and have more algorithms to choose among. AES
won't become a ubiquitous standard in the same way that DES did. But it is
finding its way into banking security products, Internet security
protocols, even computerized voting machines. A NIST standard is an
imprimatur of quality and security, and vendors recognize that.

So, how good is the NSA at cryptography? They're certainly better than the
academic world. They have more mathematicians working on the problems,
they've been working on them longer, and they have access to everything
published in the academic world, while they don't have to make their own
results public. But are they a year ahead of the state of the art? Five
years? A decade? No one knows.

It took the academic community two decades to figure out that the NSA
"tweaks" actually improved the security of DES. This means that back in the
'70s, the National Security Agency was two decades ahead of the state of
the art.

 Today, the NSA is still smarter, but the rest of us are catching up
quickly. In 1999, the academic community discovered a weakness in another
NSA algorithm, SHA, that the NSA claimed to have discovered only four years
previously. And just last week there was a published analysis of the NSA's
SHA-1 that demonstrated weaknesses that we believe the NSA didn't know
about at all.

 Maybe now we're just a couple of years behind.


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From bill.stewart at pobox.com  Mon Sep 27 20:08:49 2004
From: bill.stewart at pobox.com (Bill Stewart)
Date: Mon, 27 Sep 2004 17:08:49 -0700
Subject: An interesting "new" computer security problem
In-Reply-To: <E1CB4i7-0005sA-00@medusa01>
References: <E1CB4i7-0005sA-00@medusa01>
Message-ID: <20040928000907.AB14EF296@red.metdow.com>

At 10:03 PM 9/24/2004, Peter Gutmann wrote:
>I told them that they were in luck, and this exact problem had already been
>addressed before.  I'd drop off the detailed technical specs for the solution
>when I next saw them, they could recognise it by its bright orange cover.

Unless it's been radically updated in the decade or so since I last read it,
don't you need the book with the Red cover as well?  And maybe the purple one,
or whatever color the multi-level database stuff was?


----
Bill Stewart  bill.stewart at pobox.com 


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From bill.stewart at pobox.com  Tue Sep 28 02:00:10 2004
From: bill.stewart at pobox.com (Bill Stewart)
Date: Mon, 27 Sep 2004 23:00:10 -0700
Subject: Linux-based wireless mesh suite adds crypto engine support
In-Reply-To: <p0611040cbd7b12ea9dda@[66.149.49.5]>
References: <p0611040cbd7b12ea9dda@[66.149.49.5]>
Message-ID: <6.0.3.0.0.20040927183458.03da2cc0@pop.idiom.com>

In the past, there have been two main problems with the Via crypto sets
- availability of convenient software
- sufficient documentation and really transparent provable details
         so that users could trust and verify that the hardware and software
         were doing what they claimed to be doing and
         weren't doing anything evil that they didn't admit to,
         such as including backdoors or bad random number generators.

For typical applications, this is probably fine,
though I haven't looked at Via's licenses to see if they can
easily be used with a GPL license or if they need LGPL+Weaselwords or worse.

The hard part is trust - Cryptography Research did a study last year
about the quality of the random number generator, and found that you
get about 0.75 bits of entropy per output bit, or 0.99 if you do
Von Neumann whitening, so it's fine for feeding your crypto-based whitener.

But their report indicates that they were mainly working from
design documentation and testing actual equipment,
so their tests doesn't show what the RNG does if you execute
         SET MSR UNDOCUMENTED_EVIL_WIRETAP_MODE
first, much less what happens to the AES keying info or IVs.

Disclaimer:  I'd be really surprised if UNDOCUMENTED_EVIL_WIRETAP_MODE exists -
the folks who built the crypto features in say good pro-privacy things,
and I'm inclined to trust them.  I'm much less sure about the
nonexistence of OBSCURE_BUGGY_RNG_CONDITION_MODE.
It's very hard to test for these things when you've got complete documentation,
even if Ken Thompson wasn't helping write your compilers.

                 Bill Stewart



At 05:21 AM 9/25/2004, R. A. Hettinga wrote:
><http://www.linuxdevices.com/news/NS1975038466.html> ...
>Sep. 24, 2004
>The first commercial software product to exploit the cryptographic
>acceleration engine in newer Via processors has hit the market, according
>to Via. LocustWorld's MeshAP-Pro is a commercial version of MeshAP, Linux
>software for self-organizing networks of wireless access points. MeshAP-Pro
>targets larger mesh network operators such as urban service providers.
>
>In addition to selling and supporting MeshAP-Pro software, LocustWorld also
>offers blackbox hardware platforms for wireless routers, such as the
>MeshBox, a Linux-based mini-ITX system based on Via mini-ITX boards.
>
>LocustWorld sells Linux-based blackboxes for wireless routers based on Via
>mini-ITX boards
>
>The processors in newer Via mini-ITX boards based on C5P Nehemiah cores
>include the PadLock Hardware Security Suite, which includes the PadLock RNG
>(random number generator) and the PadLock ACE (advanced cryptography
>engine). PadLock ACE performs low-level processing of the algorithms used
>in AES (advanced encryption standard), a kind of cryptography defined by US
>government standards.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Tue Sep 28 12:22:27 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Tue, 28 Sep 2004 12:22:27 -0400
Subject: 10-Fold Increase in Quantum Cryptography Key Generation Rate
Message-ID: <p061104f9bd7f3ffd34e0@[66.149.49.5]>

<http://www.convergedigest.com/PacketSystems/packetsysarticle.asp?ID=12445>




Packet Systems News 


 NEC Achieve

10-Fold Increase in Quantum Cryptography Key Generation Rate

 Researchers in Japan succeeded in realizing the world's fastest 100 kbps
40-km-long quantum cryptography key generation, surpassing previous
records. Achieved through a newly developed quantum cryptography system
adopting a novel method, this key generation enables secure network
communication supported by the principles of quantum mechanical physics.
The technology could be used for quantum cryptography transmissions in
optical networks in metropolitan areas.

 The research was conducted by NEC, the National Institute of Information
and Communications Technology (NiCT), and the Japan Science and Technology
Agency (JST).
 http://www.nec.co.jp
 28-Sep-04


	* 	 In June 2004, BBN Technologies announced what it describes as
"the world's first quantum cryptography network." The DARPA Quantum
Network, which links BBN's campus in Cambridge, Massachusetts to Harvard
University and soon Boston University, uses quantum cryptography to provide
extremely high-levels of security for Internet traffic.
	* 	 Quantum cryptography, invented by Charles Bennett and Giles
Brassard in the 1980s, prepares and transmits single photons of light,
through either fiber optic cable or the atmosphere, to distribute
cryptographic keys that are used to encrypt and decrypt messages. BBN said
this method of securing information is radically different from methods
based on mathematical complexity, relying instead on fundamental physical
laws. Because very small (quantum) particles are changed by any observation
or measurement, eavesdropping on a quantum cryptography system is always
detectable. BBN is developing protocols to pave the way for robust quantum
networks on a larger scale by providing "any to any" networking of quantum
cryptography through a mesh of passive optical switches and cryptographic
key relays.
	* 	 In March 2004, NEC claimed a new distance record of 150 km for a
single photon transmission -- a feat that might enable secure network
communication based on principles of quantum mechanical physics. The result
was achieved through a newly developed quantum cryptography system
consisting of optical planar circuits based on Planar Lightwave Circuit
(PLC) technology. NEC said quantum cryptography transmissions in optical
networks could some day to used metropolitan areas for truly secure
communications.

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From hadmut at danisch.de  Tue Sep 28 12:54:12 2004
From: hadmut at danisch.de (Hadmut Danisch)
Date: Tue, 28 Sep 2004 18:54:12 +0200
Subject: M-209 broken in WWII
In-Reply-To: <1096311663.d645ddbcanish@myrealbox.com>
References: <1096311663.d645ddbcanish@myrealbox.com>
Message-ID: <41599734.60407@danisch.de>

Anish wrote:
>  could you please translate atleast the abstract for the rest of us :-)
> http://www.heise.de/tp/deutsch/inhalt/co/18371/1.html

Sure, some of the first paragraphs:


As a german codebreaker in World War II

Klaus Schmeh 23.9.2004

For the first time a witness reported, who was involved in breaking the
US cipherdevice M-209

Even experts didn't know until some years ago that german deciphering
specialists broke ciphers of the allied in the second world war.
But several sources document, that the germans at that time succeeded
to decipher the US cipher device M-209. Telepolis associate Klaus
Schmeh, who is specialised on cryptology, has finally found a 
contemporary witness, who participated in the decryption of M-209
messages.

One of the most fascinating episodes of technical history happend in
World War II. At that time british experts on the manor Bletchley
Park near to London broke the famous german cipher device Enigma under
the strictest secrecy, where they used thousands of people and
for that time top modern data processing devices.

Until some years ago, the doctrine was, that the germans, in contrast
to the british, underestimated the potential of the science of 
deciphering and couldn't read the radio messages of their enemies.
It is known for just a few years, that this assessment is
'political correct' but wrong.For example, the former President
of the Bundesamt f?r Sicherheit in der Informationstechnik
BSI (German Federal Office of Security in Information Technology)
Dr. Otto Leiberich reported, that the germans broke the
US cipherdevice M-209 in the WWII, what was absolutely not an
easy untertaking. More documented successes in deciphering proof,
that the german code breakers were even among the best of the world.

The explanations of Otto Leiberich provided also an important source
of information for the author of this article, when he wrote his
recently published book "Die Welt der geheimen Zeichen - Die 
faszinierende Geschichte der Verschl?sselung" (The world of secret
signs - the fascinating history of encryption). An excerpt of this
book, that was published on Telepolis, caused a little sensation:
A 84 year old man from Frankfurt reported to the author and explained
that he was involved in breaking the aforesaid US cipherdevice M-209.
After there were only second-hand reports about german codebreakers
in WWII, for the first time an eye witness appeared, who furthermore
brought some completely new aspects to light. With this article the
memories of this contemporary witness are published for the very first 
time.



OK, these are the first few paragraphs. If you want to have more about
this you should ask the publisher for a translation, because under 
german copyright law even the translation is a right of the author.


regards
Hadmut




---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From hughejp at mac.com  Tue Sep 28 13:29:29 2004
From: hughejp at mac.com (james hughes)
Date: Tue, 28 Sep 2004 13:29:29 -0400
Subject: Illustrated DES Spreadsheet
In-Reply-To: <p061104bfbd7bc4052267@[66.149.49.5]>
References: <p061104bfbd7bc4052267@[66.149.49.5]>
Message-ID: <F3A6D9C6-1173-11D9-9CD6-000A95A27482@mac.com>

For anyone wondering, or teaching about DES, or interested in perverse 
uses for spreadsheets, I have created an "Illustrated DES spreadsheet". 
This is a vanilla spreadsheet (no VB or anything exotic) and should 
work on many excel and excel workalikes.
	http://www.stortek.com/hughes/illustratedDES.xls

Acknowledgements for this work goes to J. Orlin Grabbe for his The DES 
Algorithm Illustrated which can be found at
	http://www.aci.net/kalliste/des.htm

I have also stole many tricks including how to do XOR in generic excel 
which I can not find again to give proper credit. I haven't run this 
through the FIPS 140-2 level 1 test suite (but this could easily be 
certified :-)

Anyone interested in making one for MD-5?

Enjoy

jim


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From kayos at genetikayos.com  Tue Sep 28 19:57:32 2004
From: kayos at genetikayos.com (T.R. Fullhart)
Date: Tue, 28 Sep 2004 16:57:32 -0700
Subject: October meeting announcement for SV2600
Message-ID: <29C8263A-11AA-11D9-BFCF-000A95B920F6@genetikayos.com>

This Friday is the October meeting of the Silicon Valley chapter of 
2600.

2600 meetings are local gatherings to learn and discuss the information 
infrastructure of our society. This includes problems with the 
infrastructure and it's affects on our modern society. Chapters of 2600 
are registered with 2600 magazine, http://www.2600.com/.

Topics covered include: wired and wireless communications technology, 
secure computing platforms, open-source and free software movement, 
cryptography, how-tos, information security, and electronic civil 
rights.

The Silicon Valley chapter of 2600 meets at 6:00PM on the first Friday 
of each month.

We meet in the cafe patio at the Dr. Martin Luther King, Jr. Library at 
4th and E. San Fernando in downtown San Jose:
150 E. San Fernado St.
San Jose, CA 95112

Our web site is at http://www.sv2600.org/.

--
T.R. Fullhart
kayos at genetikayos.com
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Tue Sep 28 23:14:02 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Tue, 28 Sep 2004 23:14:02 -0400
Subject: Cryptography regulations threaten OSS in SA
Message-ID: <p061104ddbd7fd8a9fdad@[66.149.49.5]>

<http://www.ebcvg.com/news.php?id=3852>

eBCVG -

 Cryptography regulations threaten OSS in SA
Published on: Tuesday, 28 September 2004, 19:40 GMT

South Africa's Electronic Communications and Transactions (ECT) Act of 2002
is a controversial piece of legislation. It attempts to address a whole lot
of issues at once, without seeming to do a good job of any of them.
Sections include a national e-strategy, e-government, electronic documents,
cryptography, authentication, consumer protection, the .za domain name
authority, and cyber crime.

 Chapter 5 deals with cryptography. It specifies the compulsory
registration of all "cryptography providers" with the Department of
Communications. The Act states in 30(1): "No person may provide
cryptography services or cryptography products in the Republic until the
particulars ... in respect of that person have been recorded in the
register..."


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From rah at shipwright.com  Wed Sep 29 12:39:33 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Wed, 29 Sep 2004 12:39:33 -0400
Subject: Swiss on a Roll With Quantum Crypto
Message-ID: <p06110425bd8094950a0d@[66.149.49.5]>

<http://www.lightreading.com/document.asp?site=lightreading&doc_id=60160>

Light Reading - Networking the Telecom Industry

SEPTEMBER 29, 2004 ?


Swiss on a Roll With Quantum Crypto

GENEVA -- Deckpoint and id Quantique, two private companies active in the
field of information technology and based in Geneva, Switzerland, and the
University of Geneva announce, as a world premiere, the official opening of
a data archiving network secured using quantum cryptography technology. A
ceremony will take place on September 29th 2004, at 11 :00 am in Geneva.
Carlo Lamprecht, the Minister of Economy, Labor and Foreign Affairs of the
Republic and Canton of Geneva, as well as Professor Andr? Hurst, the Dean
of the University of Geneva, will attend this ceremony.

 In a world where the reliance on electronic data transmission and
processing is becoming every day more prevalent, data archiving plays a
critical role in the ability of an organization to operate continuously
under all circumstances. In order to guarantee the highest availability of
information, the use of remote backup solutions on several sites is
increasing strongly. In such a scenario, the confidentiality and the
integrity of sensitive information exchanged between two sites is of the
utmost importance.

 Current cryptographic techniques used to guarantee this confidentiality
are based on mathematical theories. In spite of the fact, that they are
very widespread, they do not offer a foolproof security. They are in
particular vulnerable to increasing computing power and theoretical
advances in mathematics. On the contrary, quantum cryptography exploits the
laws of quantum physics to guarantee in an absolute fashion the
confidentiality of data transmission. ? Quantum cryptography constitutes a
revolution in the field of information security ? says Professor Nicolas
Gisin, of the University of Geneva. ? It is the only solution offering long
term confidentiality and which cannot be compromised by scientific or
technological advances ?.

 The University of Geneva, where research on quantum cryptography started
in the early 90's, played a pioneer role in the development of this
technology. At the end of 2001, four researchers, who were convinced of the
potential of this technology, founded the company id Quantique to develop
commercial applications.

 id Quantique and Deckpoint joined forces to develop and implement the
first data archiving network secured using quantum cryptography. The data
saved on a farm of 30 servers of the Deckpoint Housing Center, in the
Acacias district of Geneva, are replicated on servers located at the Cern
Internet Exchange Point, in Meyrin, in the suburbs of Geneva. The distance
between the two sites is about 10 kilometers. This application, which will
initially last about one month, constitutes a world premiere.

 id Quantique, the first company to bring quantum cryptography to the
market, provided the hardware used in this application. ? This world
premiere is an excellent illustration of the of the potential of this
technology ? says Gregoire Ribordy, CEO. ? The company confirms thus its
leading position in applications of quantum technologies. ?

 ? We are convinced that security has become critical, in particular with
the implementation of the Basel II standards in the banking industry as of
2006. The economic world cannot afford anymore not to have a complete
information security strategy ? adds Dominique Perisset, director of
Deckpoint. Seduced by the ambitions and visionary nature of this project,
Deckpoint granted access to its infrastructure and offered technical
support to make the implementation of this network possible.


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From ben at algroup.co.uk  Wed Sep 29 08:05:52 2004
From: ben at algroup.co.uk (Ben Laurie)
Date: Wed, 29 Sep 2004 13:05:52 +0100
Subject: Customs and Excise Electronic Returns
Message-ID: <415AA520.7020301@algroup.co.uk>

Background, for non-Brits: Customs & Excise (C&E) is the government 
department responsible for collecting VAT (Value Added Tax), which is a 
European sales tax. Businesses report their VAT transactions quarterly 
to C&E, currently mostly on paper (a one page form, amazingly) - this is 
known as a VAT return.

For some time, C&E has been encouraging electronic VAT returns 
(cunningly named eVAT), but until recently required the use of an X509 
client certificate to submit.

Presumably this has proved unpopular, since they are now permitting good 
old username/password to be used. But they seem to be a little confused...

 From the eVAT FAQ 
(http://new.hmce.gov.uk/channelsPortalWebApp/channelsPortalWebApp.portal?_nfpb=true&_pageLabel=pageOnlineServices_ShowContent&id=HMCE_PROD_008287&propertyType=document):

"Which is more secure ? using a Digital Certificate or User ID & Password?

Both methods are secure, but they work in different ways."

 From the Government Gateway Help pages 
(http://www.gateway.gov.uk/help/help_template_non_secure.asp?content=%3A%2F%2Fwww.ukonline.gov.uk%2FGateway%2FGatewayArticle%2Ffs%2Fen%3FCONTENT_ID%3D4013333%26chk%3DBQAvk3&languageid=0):

"Certificates provide a higher level of security, which is required for 
certain services."

Nothing like singing from the same songsheet, eh?

Anyway, it gets better. Three types of certificate are permitted, 
SecureMark, SimplySign or Trust Services. Again from the eVAT FAQ:

"   * SecureMark and Chamber SimplySign certificates can be used with 
either Internet Explorer 5.01 or higher, or Netscape Navigator.
     * Trust Services? certificates work with Microsoft Internet 
Explorer 5.0 or later and Netscape v 4.6 or higher (but not v6 or 7).
     * certificates can be used with Internet Explorer 5.01 or higher or 
Netscape Navigator 4.08 or later (but not v6 or 7). "

I dunno about you, but this is not exactly clear to me. Leaving that 
aside, let's look at the various CAs...

SecureMark,  on a page amusingly titled "Does your Netscape Browser meet 
the minimum requirements?" 
(http://www.equifaxsecure.co.uk/digitalcertificates/Netscape_Response.html):

"the minimum system requirements are:

Windows 95 or NT 4 (SP3) or higher
Internet Explorer version 5.01 or above
128-bit cipher strength"

I guess the answe will be "no", then! (My browser was Firefox, 
incidentally).

SimplySign - seems they actually admit that "Netscape" might work. But...

http://www.simplysign.co.uk/support/ierootdownload.html

"To make sure that your browser works with Trustis certificates the 
'Trustis FPS Root CA' certificate should be installed. There is no 
danger in doing this and no programs will be downloaded to your computer."

No, of course, installing root CAs in your browser has no security 
implications whatever. And of course, you have to have the root CA to 
use a client cert. Not.

As for Trust Services. Well, I can't find them through Google (at least, 
not the one they had in mind) but much meandering around FAQs eventually 
yielded a link - turns out its BT and Verisign, but ... oops! "Note: 
Inland Revenue services have not yet been upgraded to allow the use of 
BT ID Certificates". So much for a simpler user experience.

Oh yeah, another gem from the eVAT FAQ:

"The Government Gateway and Digital Certificate authorities do not 
currently support the use of Digital Certificates on Apple Macintosh"

Well, of course not, because everyone knows that Apple X.509 is 
completely different from Microsoft X.509. Duh.

So, after all that, I totally understand why everyone thinks PKI is 
hard. I'm all for the username/password thing. Its free, too.

Cheers,

Ben.

-- 
ApacheCon! 13-17 November! http://www.apachecon.com/

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"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 majordomo at metzdowd.com


From rah at shipwright.com  Wed Sep 29 13:33:49 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Wed, 29 Sep 2004 13:33:49 -0400
Subject: Federal judge rejects part of Patriot Act
Message-ID: <p0611046ebd80a24b40bf@[66.149.49.5]>

<http://msnbc.msn.com/id/6131670/print/1/displaymode/1098/>
  MSNBC.com

Federal judge rejects part of Patriot Act
Provision giving FBI access to business records overturned
Reuters
Updated: 12:11 p.m. ET Sept. 29, 2004


NEW YORK - A federal judge Wednesday found unconstitutional a part of the
United States' anti-terror Patriot Act that allows authorities to demand
customer records from businesses without court approval.

 U.S. District Judge Victor Marreo ruled in favor of the American Civil
Liberties Union, which challenged the power the FBI has to demand
confidential financial records from companies as part of terrorism
investigations.

 The ruling was the latest blow to the Bush administration's anti-terrorism
policies.

 In June, the U.S. Supreme Court ruled that terror suspects being held in
places like Guantanamo Bay can use the American judicial system to
challenge their confinement. That ruling was a defeat for the president's
assertion of sweeping powers to hold "enemy combatants" indefinitely after
the Sept. 11, 2001, attacks.

 The ACLU sued the Department of Justice, arguing that part of the Patriot
legislation violated the Constitution because it authorizes the FBI to
force disclosure of sensitive information without adequate safeguards.

 The judge agreed, stating that the provision "effectively bars or
substantially deters any judicial challenge."

 Under the provision, the FBI did not have to show a judge a compelling
need for the records and it did not have to specify any process that would
allow a recipient to fight the demand for confidential information.

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From dahonig at cox.net  Wed Sep 29 21:38:51 2004
From: dahonig at cox.net (David Honig)
Date: Wed, 29 Sep 2004 18:38:51 -0700
Subject: An interesting "new" computer security problem
In-Reply-To: <6.1.2.0.2.20040927125349.0330ffb8@mail.comcast.net>
References: <E1CB4i7-0005sA-00@medusa01>
 <E1CB4i7-0005sA-00@medusa01>
Message-ID: <3.0.5.32.20040929183851.008b7580@pop.west.cox.net>

At 12:58 PM 9/27/04 -0600, Anne & Lynn Wheeler wrote:
>At 11:03 PM 9/24/2004, Peter Gutmann wrote:
>>A few days ago I was chatting with some people working on a government IT
>>project who had a rather complex security problem that they needed help
with.
>>They have a large number of users with Windows dumb terminals (think Xterms
>>but for Windows) connected to a central ASP server, which runs various
>>mutually untrusted apps from different vendors.  Their problem was that they
>>needed a means of securing the individual apps from each other.
>>
>>I told them that they were in luck, and this exact problem had already been
>>addressed before.  I'd drop off the detailed technical specs for the
solution
>>when I next saw them, they could recognise it by its bright orange cover.

Put each app on a separate machine, and don't put any networking
equiptment in the machines.  Simple.



=================================================
36 Laurelwood Dr
Irvine CA 92620-1299

VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP

ICBM: -117.7621, 33.7275
PGP PUBLIC KEY: by arrangement

Send plain ASCII text not HTML lest ye be misquoted.  Really.

------

"Don't 'sir' me, young man, you have no idea who you're dealing with"
Tommy Lee Jones, MIB



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From pgut001 at cs.auckland.ac.nz  Thu Sep 30 00:58:13 2004
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Thu, 30 Sep 2004 16:58:13 +1200
Subject: Customs and Excise Electronic Returns
In-Reply-To: <415AA520.7020301@algroup.co.uk>
Message-ID: <E1CCt1B-0005Rq-00@medusa01>

Ben Laurie <ben at algroup.co.uk> writes:

>Oh yeah, another gem from the eVAT FAQ:
>
>"The Government Gateway and Digital Certificate authorities do not currently
>support the use of Digital Certificates on Apple Macintosh"
>
>Well, of course not, because everyone knows that Apple X.509 is completely
>different from Microsoft X.509. Duh.

I've seen this one before, this happens when the CA generates your private key
and emails it to you, a relatively common practice.  Since the Mac can't
import the PFX/PKCS #12 files used by MSIE/CryptoAPI, you can't use them on
the Macintosh.

(This was pre-OS X, I don't know what the status is now, it may still be
 something that requires MS CryptoAPI to work, or maybe the web page is just
 out of date).

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From pgut001 at cs.auckland.ac.nz  Thu Sep 30 01:05:15 2004
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Thu, 30 Sep 2004 17:05:15 +1200
Subject: Linux-based wireless mesh suite adds crypto engine support
In-Reply-To: <6.0.3.0.0.20040927183458.03da2cc0@pop.idiom.com>
Message-ID: <E1CCt7z-0005TQ-00@medusa01>

Bill Stewart <bill.stewart at pobox.com> writes:

>In the past, there have been two main problems with the Via crypto sets
>
>- availability of convenient software

VIA AES support is included in Brian Gladman's AES implementation, which is
pretty much the de facto standard AES implementation.  The RNG code is pretty
easy to do, I did an implementation that worked out of the box without ever
having access to the hardware.

>- sufficient documentation and really transparent provable details so that
>users could trust and verify that the hardware and software were doing what
>they claimed to be doing and weren't doing anything evil that they didn't
>admit to, such as including backdoors or bad random number generators.

Tinfoil hat stuff - why trust any crypto hardware then?.  The only thing they
could fiddle is the RNG, and I just can't see them risking their reputation
over something as silly as this.  Besides, they're also going for government
markets, so I would imagine third parties have gone over the design in much
more detail than in any published analysis.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Wed Sep 29 19:03:13 2004
From: iang at systemics.com (Ian Grigg)
Date: Thu, 30 Sep 2004 00:03:13 +0100
Subject: Customs and Excise Electronic Returns
In-Reply-To: <415AA520.7020301@algroup.co.uk>
References: <415AA520.7020301@algroup.co.uk>
Message-ID: <415B3F31.6030001@systemics.com>

Ben Laurie wrote:
> So, after all that, I totally understand why everyone thinks PKI is 
> hard. I'm all for the username/password thing. Its free, too.

PKI, and the Customs & Excise's, mistake was to assume that a
key is only useful if it is signed by someone else.  From a
system point of view, this will require massive benefits to
make it work.  As there are few massive benefits if any over
a username / password combo, then that's what they'll use.

It might be worth pointing out to them that the US' Government
Accounting Office is downbeat on the use of PKI.

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From nmol010 at ec.auckland.ac.nz  Thu Sep 30 05:07:10 2004
From: nmol010 at ec.auckland.ac.nz (Nicolai Moles-Benfell)
Date: Thu, 30 Sep 2004 21:07:10 +1200
Subject: IBM's original S-Boxes for DES?
In-Reply-To: <E1CB4i7-0005sA-00@medusa01>
References: <E1CB4i7-0005sA-00@medusa01>
Message-ID: <1096535230.415bccbe98ef6@webmail1.ec.auckland.ac.nz>

Hi,

A number of sources state that the NSA changed the S-Boxes (and reduced the key
size) of IBM's original DES submission, and that these change were made to
strengthen the cipher against differential/linear/?? cryptanalysis.

Does anybody have a reference to, or have an electronic copy of these original
S-Boxes?

Nicolai.

[Moderator's note: Google for information on the original cipher,
called "Lucifer". --Perry]
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From ben at algroup.co.uk  Thu Sep 30 05:38:15 2004
From: ben at algroup.co.uk (Ben Laurie)
Date: Thu, 30 Sep 2004 10:38:15 +0100
Subject: Customs and Excise Electronic Returns
In-Reply-To: <E1CCt1B-0005Rq-00@medusa01>
References: <E1CCt1B-0005Rq-00@medusa01>
Message-ID: <415BD407.8070205@algroup.co.uk>

Peter Gutmann wrote:
> Ben Laurie <ben at algroup.co.uk> writes:
> 
> 
>>Oh yeah, another gem from the eVAT FAQ:
>>
>>"The Government Gateway and Digital Certificate authorities do not currently
>>support the use of Digital Certificates on Apple Macintosh"
>>
>>Well, of course not, because everyone knows that Apple X.509 is completely
>>different from Microsoft X.509. Duh.
> 
> 
> I've seen this one before, this happens when the CA generates your private key
> and emails it to you, a relatively common practice.  Since the Mac can't
> import the PFX/PKCS #12 files used by MSIE/CryptoAPI, you can't use them on
> the Macintosh.

I forgot to check for that (which would make the CA unusable from my 
POV), but circumstantial evidence leads me to believe that at least one 
of the supported CAs doesn't suffer from this fatal flaw.

Cheers,

Ben.

-- 
ApacheCon! 13-17 November! http://www.apachecon.com/

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"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 majordomo at metzdowd.com


From jthorn at aei.mpg.de  Thu Sep 30 07:20:08 2004
From: jthorn at aei.mpg.de (Jonathan Thornburg)
Date: Thu, 30 Sep 2004 13:20:08 +0200 (CEST)
Subject: Linux-based wireless mesh suite adds crypto engine support
In-Reply-To: <6.0.3.0.0.20040927183458.03da2cc0@pop.idiom.com>
Message-ID: <Pine.LNX.4.21.0409301314350.24577-100000@xeon14.aei.mpg.de>

On Mon, 27 Sep 2004, Bill Stewart wrote:
[[about the Via crypto sets]]
> The hard part is trust - Cryptography Research did a study last year
> about the quality of the random number generator, and found that you
> get about 0.75 bits of entropy per output bit, or 0.99 if you do
> Von Neumann whitening, so it's fine for feeding your crypto-based whitener.
> 
> But their report indicates that they were mainly working from
> design documentation and testing actual equipment,
> so their tests doesn't show what the RNG does if you execute
>          SET MSR UNDOCUMENTED_EVIL_WIRETAP_MODE
> first, much less what happens to the AES keying info or IVs.

UNDOCUMENTED_EVIL_WIRETAP_MODE can be just about impossible to spot
without full design oversight.  Even for a 3DES chip, where supposedly
you can use deterministic test vectors to verify things, the following
scheme due to Henry Spencer embeds an almost-impossible-to-spot-in-practice
backdoor:

(N.b. the original URL is now dead, but google on the quoted phrase
      "GOTCHA, YOU OPEN-SOURCE WEENIES -- NSA RULES!" found two other
      archived copies)

  ## http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/09/msg00240.html
       _________________________________________________________________
     
     [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread
     Index]
     
  Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet
       _________________________________________________________________
     
       * To: Linux IPsec <linux-ipsec at clinet.fi>
       * Subject: Re: linux-ipsec: Intel IPSEC accelerator gives 3DES
         protected 100Mbit Ethernet
       * From: Henry Spencer <henry at spsystems.net>
       * From: linux-ipsec at clinet.fi
       * Date: Thu, 16 Sep 1999 10:48:52 -0400 (EDT)
       * In-Reply-To: <199909161411.KAA02388 at tonga.xedia.com>
       * Reply-To: linux-ipsec at clinet.fi
       * Sender: owner-linux-ipsec-local at sandelman.ottawa.on.ca
       _________________________________________________________________
     
  William H Geiger writes:
  > I don't know if you still follow the CP list but we have
  > been having a long debate on the trustworthiness of Intel
  > hardware, especially their RNG...
  
  At first I thought this was pretty much a non-issue here.  The problem
  with the RNG is that it's so hard to decide whether its output is "really"
  random.  But 3DES is a deterministic transform which can be tested against
  other implementations, so you can easily establish whether the chip is
  really doing 3DES or not.
  
  Alas, then I got to thinking.  Suppose one built a 3DES accelerator chip
  so that, if and only if:
  
  (a) the chip is doing near-continuous encryptions at high speed, and
  (b) the keys are changing every packet or two, and
  (c) the chip detects -- via a simple mechanism like a little hash table --
          a key which has appeared before, recently, and
  (d) this key has not been marked "compromised" in the hash table, and
  (e) an internal 16-bit packet counter is all-1s,
  
  then
  
  (!) mark the key compromised in the hash table, XOR the key with the
  string "GOTCHA, YOU OPEN-SOURCE WEENIES -- NSA RULES!", prefix it with a
  random-looking constant bit pattern, and sprinkle the resulting bits into
  the encrypted data, in a haphazard but deterministic pattern.
  
  This is, of course, an encryption error.  But rules (a)-(e) make it
  essentially irreproducible, so it won't happen a second time (and will be
  quite difficult to reproduce even in a test setup).  Almost certainly it
  will get written off as a random error, and the affected packet will be
  re-processed correctly and re-sent, and all will be well.
  
  Except that an eavesdropper on the high-speed wire just looks for the
  constant bit pattern in the right places in a packet, and (almost) every
  time he sees it, he's nabbed an encryption key.
  
  There's no limit to the complexity that can be added -- especially if
  you're willing to consider active wiretapping, with the chip going into
  this mode only if it sees (say) an ICMP ping with the right data in it --
  to defeat attempts to find this sort of thing on the test bench.
  
  I fear I agree with William; nothing short of peer review of the hardware
  design makes such a device trustworthy.
  
                                                            Henry Spencer
                                                         henry at spsystems.net
                                                       (henry at zoo.toronto.edu)
  
  
  -
  This is the linux-ipsec-local at sandelman.ottawa.on.ca mailing list. It is a
  restrict-Post filtered version of linux-ipsec at clinet.fi.
       _________________________________________________________________
     
     Follow-Ups:
       * Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected
         100Mbit Ethernet
         
       * From: Richard Guy Briggs
         <rgb at conscoop.ottawa.on.ca>linux-ipsec at clinet.fi
         
     References:
       * Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected
         100Mbit Ethernet
         
       * From: Paul Koning <pkoning at xedia.com>linux-ipsec at clinet.fi
       _________________________________________________________________
     
       * Prev by Date: Re: linux-ipsec: Intel IPSEC accelerator gives 3DES
         protected 100Mbit Ethernet
       * Next by Date: linux-ipsec: IP Sec w/ dynamic IP addresses ?
       * Prev by thread: Re: linux-ipsec: Intel IPSEC accelerator gives
         3DES protected 100Mbit Ethernet
       * Next by thread: Re: linux-ipsec: Intel IPSEC accelerator gives
         3DES protected 100Mbit Ethernet
       * Index(es):
            + Main
            + Thread

-- 
-- Jonathan Thornburg <jthorn at aei.mpg.de>      
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html      
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From lindac at dimacs.rutgers.edu  Thu Sep 30 10:27:22 2004
From: lindac at dimacs.rutgers.edu (Linda Casals)
Date: Thu, 30 Sep 2004 10:27:22 -0400 (EDT)
Subject: DIMACS Workshop on Mobile and Wireless Security
Message-ID: <200409301427.KAA22768@dimacs.rutgers.edu>


*************************************************
     
DIMACS Workshop on Mobile and Wireless Security 
          
     November 3 - 4, 2004
     DIMACS Center, Rutgers University, Piscataway, NJ

Organizers: 
      Bill Arbaugh, University of Maryland, waa at cs.umd.edu 
     
Presented under the auspices of the Special Focus on Communication
Security and Information Privacy.


    ************************************************

The rapid growth of both voice and data wireless communications has
resulted in several serious security problems in both the voice and 
data spaces. Unfortunately, many of the early security mistakes made 
with wireless voice communications were repeated with data
communications, i.e. the use of flawed authentication and
confidentiality algorithms. For example, the standards committee for 
802.11 left many of the difficult security issues such as key
management and a robust authentication mechanism as open problems. 
This has led many organizations to use either a permanent fixed
cryptographic variable or no encryption with their wireless networks. 
Since wireless networks provide an adversary a network access point
that is beyond the physical security controls of the organization, 
security can be a problem. Similarly, attacks against WEP, the
link-layer security protocol for 802.11 networks can exploit design 
failures to successfully attack such networks. This workshop will 
focus on addressing the many outstanding issues that remain in
wireless cellular and WLAN networking such as (but not limited to):
Management and monitoring; ad-hoc trust establishment; secure roaming
between overlay networks; availability and denial of service
mitigation; and network and link layer security protocols. We will 
seek to extend work on ad hoc networking from a non-adversarial
setting, assuming a trusted environment, to a more realistic setting
in which an adversary may attempt to disrupt communication. We will
investigate a variety of approaches to securing ad hoc networks, in 
particular ways to take advantage of their inherent redundancy 
(multiple routes between nodes), replication, and new cryptographic 
schemes such as threshold cryptography.

**************************************************************

Call for Participation:

Advances in wireless technology as well as several other areas are
changing the way the world does business and as a result computing is
becoming more mobile, and users are demanding continuous access to the
Internet. At the same time, the number of devices with embedded
networking technology is growing exponentially--from boxes with RFID
tags to Wi-Fi capable refrigerators since they destroy the notion of a
static defensive perimeter. Furthermore, these trends make the ease of
use and management of wireless based networks more important since
naive consumers in the future will be establishing and using wireless
networks on a scale significantly larger than today. This workshop
will focus on identifying the current and future problems in wireless
security and privacy and discuss possible solutions.

The three day workshop will be organized around a series of talks on
subjects related to mobility, wireless, and security and privacy
technologies. There will be a mix between invited talks and talks
selected from extended abstracts with plenty of discussion time
between talks.


************************************************************
Workshop Program:
Wednesday, November 3, 2004

 9:00 - 10:00  Breakfast and Registration

10:00 - 10:15  Welcome and Overview of Program	
               Fred Roberts, DIMACS Director

10:15 - 11:00  Wireless Authentication Overivew	
               William Arbaugh

11:00 - 11:45  TBD	
               DJ Johnston, Intel (tentatively confirmed)

11:45 - 12:30  Role of Authorization in Wireless Network Security	
               Pasi Eronen, Nokia

12:30 -  2:00  Lunch	

 2:00 -  2:45  Network Access Control Schemes Vulnerable to Covert Channels	
               Florent Bersani

 2:45 -  3:30  TBD	
               Jesse Walker, Intel 
 
 3:30 -  4:00  Break	

 4:00 -  5:00  Secure and Efficient Network Access	
               Jari Arkko, Ericsson

 5:00	       Social Event

Thursday, November 4, 2004

 8:30 -  9:00  Breakfast and Registration	
 
 9:00 -  9:45  Extending the GSM/3G Key Infrastructure	
               Scott Guthery

 9:45 - 10:30  Wireless Security and Roaming Overview	
               Nidal Aboudagga, UCL

10:30 - 11:00  Break	

11:00 - 11:45  TBD	
               James Kempf, DoCoMo USA Labs

11:45 - 12:30  TBD	
               Nancy Cam-Winget, Cisco 

12:30 -  2:00  Lunch	

 2:00 -  2:45  Securing Wireless Localization	
               Zang Li, Rutgers

 2:45 -  3:30  Discussion Period- how to move forward, hard problems?	
               William Arbaugh

 3:30	       Closing

**************************************************************
Registration:

Pre-registration deadline: October 27, 2004

Please see website for registration information.

*********************************************************************
Information on participation, registration, accomodations, and travel 
can be found at:

http://dimacs.rutgers.edu/Workshops/MobileWireless/

   **PLEASE BE SURE TO PRE-REGISTER EARLY**

********************************************************************

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From smb at research.att.com  Thu Sep 30 12:25:20 2004
From: smb at research.att.com (Steven M. Bellovin)
Date: Thu, 30 Sep 2004 12:25:20 -0400
Subject: IBM's original S-Boxes for DES? 
In-Reply-To: Your message of "Thu, 30 Sep 2004 21:07:10 +1200."
             <1096535230.415bccbe98ef6@webmail1.ec.auckland.ac.nz> 
Message-ID: <20040930162520.16E341AE84@berkshire.research.att.com>

In message <1096535230.415bccbe98ef6 at webmail1.ec.auckland.ac.nz>, Nicolai Moles
-Benfell writes:
>Hi,
>
>A number of sources state that the NSA changed the S-Boxes (and reduced the ke
>y
>size) of IBM's original DES submission, and that these change were made to
>strengthen the cipher against differential/linear/?? cryptanalysis.
>
>Does anybody have a reference to, or have an electronic copy of these original
>S-Boxes?
>

It was only to protect against differential cryptanalysis; they did not 
know about linear cryptanalysis.  See Don Coppersmith, The Data Encryption
Standard (DES) and its strength against attacks, IBM Journal of Research
and Development, Vol. 38, n. 3, pp. 243-250, May 1994.


		--Steve Bellovin, http://www.research.att.com/~smb



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From dirkx at webweaving.org  Thu Sep 30 14:22:53 2004
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Thu, 30 Sep 2004 11:22:53 -0700 (PDT)
Subject: Customs and Excise Electronic Returns
In-Reply-To: <415B3F31.6030001@systemics.com>
References: <415AA520.7020301@algroup.co.uk> <415B3F31.6030001@systemics.com>
Message-ID: <20040930110554.E54121@skutsje.san.webweaving.org>



On Thu, 30 Sep 2004, Ian Grigg wrote:

> PKI, and the Customs & Excise's, mistake was to assume that a
> key is only useful if it is signed by someone else.  From a

Right; that is often forgotten and very useful - as the dutch root PKI was
signed under rather dubious circumstances (and its safeguarding even more
circumspect) we recently guided a customer through essentially accepting
any customer key (plain, self signed or 3random rd party signed) and
simply got them into the habit of keeping lists of keys accepted (and the
mapping to -their- idea what identity it represents).

And all in all that maked things a lot more practical; and fitted
exactly with the existing paper work flow where they would accept based
on caller-ID and a password list.

Dw.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Thu Sep 30 17:39:24 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Thu, 30 Sep 2004 17:39:24 -0400
Subject: QC Hype Watch: Quantum cryptography gets practical
Message-ID: <p061104f7bd822d38d257@[66.149.49.5]>

<http://www.computerworld.com/printthis/2004/0,4814,96111,00.html>

 - Computerworld


 Quantum cryptography gets practical

 Opinion by Bob Gelfond, MagiQ Technologies Inc.


 
 
 
  SEPTEMBER 30, 2004  (COMPUTERWORLD)  -  In theory and in labs, quantum
cryptography -- cryptography based on the laws of physics rather than
traditional, computational difficulty -- has been around for years.
Advancements in science and in the world's telecommunications
infrastructure, however, have led to the commercialization of this
technology and its practical application in industries where high-value
assets must be secure.

 Protecting information today usually involves the use of a cryptographic
protocol where sensitive information is encrypted into a form that would be
unreadable by anyone without a "key." For this system to work effectively,
the key must be absolutely random and kept secret from everyone except the
communicating parties. It must also be refreshed regularly to keep the
communications channel safe. The challenge resides in the techniques used
for the encryption and distribution of this key to its intended parties to
avoid any interception of the key or any eavesdropping by a third party.

 Many organizations are advancing quantum technology and bringing it
outside academia. Research labs, private companies, international alliances
such as the European Union and agencies such as the Defense Advanced
Research Projects Agency are investing tens of millions of dollars in
quantum research, with projects specifically focused on the challenge of
key distribution.

 The trouble with key distribution

Huge investment in the late 1990s through 2001 created a vast
telecommunications infrastructure resulting in millions of miles of optical
fiber laid across the country and throughout buildings to enable high-speed
communications. This revolution combined a heavy reliance on fiber-optic
infrastructure with the use of open network protocols such as Ethernet and
IP to help systems communicate.

 Although this investment delivers increased productivity, dependence on
optical fiber compounds key distribution challenges because of the relative
ease with which optical taps can be used. With thousands of photons
representing each bit of data traveling over fiber, nonintrusive, low-cost
optical taps placed anywhere along the fiber can siphon off enough data
without degrading the signal to cause a security breach. The threat profile
is particularly high where clusters of telecommunications gear are found in
closets, the basements of parking garages or central offices. Data can be
tapped through monitoring jacks on this equipment with inexpensive handheld
devices. This enables data to be compromised without eavesdroppers
disclosing themselves to the communicating parties.

 Another important aspect of this problem is the refresh rate of the keys.
Taking large systems off-line to refresh keys can cause considerable
headaches, such as halting business operations and creating other security
threats. Therefore, many traditional key-distribution systems refresh keys
less than once per year. Infrequent key refreshing is detrimental to the
security of a system because it makes brute-force attacks much easier and
can thereby provide an eavesdropper with full access to encrypted
information until the compromised key is refreshed.

 Adding quantum physics to the key distribution equation

Companies are now in a position to use advancements in quantum
cryptography, such as quantum key distribution (QKD) systems, to secure
their most valued information. Two factors have made this possible: the
vast stretches of optical fiber (lit and dark) laid in metropolitan areas,
and the decreasing cost in recent years of components necessary for
producing QKD systems as a result of the over-investment in
telecommunications during the early 2000s.

 Based on the laws of quantum mechanics, the keys generated and
disseminated using QKD systems have proved to be absolutely random and
secure. Keys are encoded on a photon-by-photon basis, and quantum mechanics
guarantees that the act of an eavesdropper intercepting a photon will
irretrievably change the information encoded on that photon. Therefore, the
eavesdropper can't copy or read the photon -- or the information encoded on
it -- without modifying it, which makes it possible to detect the security
breach. In addition to mitigating the threat of optical taps, QKD systems
are able to refresh keys at a rate of up to 10 times per second, further
increasing the level of security of the encrypted data.

 Not for everyone

Quantum key distribution systems aren't intended for everyday use: You
won't find a QKD system in the home office anytime soon. One reason is that
a QKD system requires a dedicated fiber-optic line. Also, because the loss
of photons over longer distances, these systems have current distance
limitations of approximately 120 kilometers (nearly 75 miles) which is
common with optical infrastructure equipment. Quantum repeaters are under
development to extend that range much farther. Finally, the end points of
these QKD systems must reside in secure locations. However, since they are
tamper-proof, if attempts are made to compromise them, they will stop
running or fire off an alarm, thus ensuring ultimate information protection.

 The practical development of QKD systems has made them applicable for a
number of industries such as financial services, biotech and
telecommunications along with government sectors such as intelligence and
the military. They don't require a physicist or an engineer to administer
them. These appliances fit in standard racks, plug into existing networks,
and are reliable around the clock. QKD systems interoperate with security
standards such as IPsec-based VPNs providing an added layer of security to
networks.

 Ask the right questions

As you look for better ways to protect your company's most important
information, QKD may be an option. However, be sure you understand the
strengths and drawbacks of quantum key distribution by asking the right
questions:

	1.  	 What does your organization's security policy say about the
threat profile for high-value assets?

	2.  	How frequently are your encryption keys changed and by what method?

	3.  	What is the total cost of ownership for QKD products? Are there
additional costs in support and training?

	4.  	Are your competitors implementing QKD systems?

	5.  	What infrastructure requirements must be met?

	6.  	What personnel/staffing levels are required?

	7.  	How does this QKD system work with existing cryptography systems?

	8.  	What are the distance limitations of this system?

QKD isn't an everyday desktop tool, but the technology makes sense for
those organizations that have the resources and the capacity to use it
effectively.

 Bob Gelfond is founder and CEO of MagiQ Technologies Inc., a vendor of
quantum information processing services and products in New York.





 



Additional Content

 White Papers


 Read up on the latest ideas and technologies from companies that sell
hardware, software and services.


View all whitepapers
Research Report

 This IDC white paper demonstrates growth in value of distributed
applications accessed over the Web, especially for eCommerce applications,
and analyses the requirements needed for performance management of
distributed applications in today's complex heterogeneous environments.
 Distributed Applications Performance Management: The VERITAS i3 Approach


Featured Webcast


Network Computing Web Event
 See the latest innovations, including Sun servers and workstations based
on AMD Opteron[tm], new Sun StorEdge[tm] solutions, and breakthrough
technologies in Solaris[tm] 10.





Sponsored Links

A smart plan for assuring application quality:    New webcast from Compuware
Distributed Applications Performance Management: The VERITAS i3 Approach
  Download this free white paper from IDC



Enterprise Solutions for Federal Government     An IT infrastructure starts
with robust technology.




The IP migration    A wake-up call



Enterprise Grid Alliance    Helping make grid computing work for you

About Us Contacts Editorial Calendar Help Desk Advertise  Privacy Policy
 



 

 
 Copyright ? 2004 Computerworld Inc. All rights reserved.  Reproduction in
whole or in part in any form or medium without express  written permission
of Computerworld Inc. is prohibited. Computerworld and Computerworld.com
and the respective logos are trademarks of International Data Group Inc.


 

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com


From gnu at toad.com  Thu Sep 30 18:25:57 2004
From: gnu at toad.com (John Gilmore)
Date: Thu, 30 Sep 2004 15:25:57 -0700
Subject: Linux-based wireless mesh suite adds crypto engine support 
In-Reply-To: Message from pgut001@cs.auckland.ac.nz (Peter Gutmann) 
   of "Thu, 30 Sep 2004 17:05:15 +1200." <E1CCt7z-0005TQ-00@medusa01> 
References: <E1CCt7z-0005TQ-00@medusa01> 
Message-ID: <200409302225.i8UMPv8P001170@new.toad.com>

> >- sufficient documentation and really transparent provable details so that
> >users could trust and verify that the hardware and software were doing what
> >they claimed to be doing and weren't doing anything evil that they didn't
> >admit to, such as including backdoors or bad random number generators.
> 
> Tinfoil hat stuff - why trust any crypto hardware then?

I don't -- do you?

Crypto hardware that does algorithms can be tested by periodically
comparing its results to a software implementation.  Production
applications should probably be doing this -- maybe 1% of the time.

Crypto hardware that generates "random" numbers can't be tested in
production in many useful ways.  My suggestion would be to XOR a
hardware-generated and a software-generated random number stream.  If
one fails, whether by accident, malice, or design, the other will
still randomize the resulting stream.  Belt AND suspenders will keep
your source of randomness from being your weakest link.

	John

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From bill.stewart at pobox.com  Thu Sep 30 16:43:10 2004
From: bill.stewart at pobox.com (Bill Stewart)
Date: Thu, 30 Sep 2004 13:43:10 -0700
Subject: Linux-based wireless mesh suite adds crypto engine support
In-Reply-To: <Pine.LNX.4.21.0409301314350.24577-100000@xeon14.aei.mpg.de
 >
References: <6.0.3.0.0.20040927183458.03da2cc0@pop.idiom.com>
 <Pine.LNX.4.21.0409301314350.24577-100000@xeon14.aei.mpg.de>
Message-ID: <20040930225334.A5009E76A@red.metdow.com>

Peter Gutmann wrote:
 > Tinfoil-hat mode.
Agreed, but some people want to be thorough, or pedantic, or paranoid.

At 04:20 AM 9/30/2004, Jonathan Thornburg wrote:
>UNDOCUMENTED_EVIL_WIRETAP_MODE can be just about impossible to spot
>without full design oversight.  Even for a 3DES chip, where supposedly
>you can use deterministic test vectors to verify things, the following
>scheme due to Henry Spencer embeds an 
>almost-impossible-to-spot-in-practice backdoor:

A somewhat simpler backdoor could be used in block chaining modes.
Occasionally output the data you're leaking instead of one or a few blocks
of cyphertext, and the CBC will glitch on it and then resync a few blocks 
later;
in many environments the application layer will correct for it,
e.g. IPSEC will lose a few packets, TCP will timeout and retransmit,
and 3 seconds later it's as if nothing happened except that
the private keypart has been leaked for the passive eavesdropper.


Bill Stewart  bill.stewart at pobox.com 


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Thu Sep 30 21:24:52 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Thu, 30 Sep 2004 21:24:52 -0400
Subject: CFP: Privacy Enhancing Technologies (PET 2005)
Message-ID: <p06110436bd8262273a9d@[66.149.49.5]>


--- begin forwarded text


To: sec-lists: ;
Cc: George.Danezis at cl.cam.ac.uk
Subject: CFP: Privacy Enhancing Technologies (PET 2005)
From: George Danezis <George.Danezis at cl.cam.ac.uk>
Sender: nymip-rg-interest-admin at nymip.org
List-Id: Open NymIP-RG discussion list <nymip-rg-interest.nymip.org>
List-Post: <mailto:nymip-rg-interest at nymip.org>
List-Help: <mailto:nymip-rg-interest-request at nymip.org?subject=help>
List-Subscribe: <http://www.nymip.org/mailman/listinfo/nymip-rg-interest>,
	<mailto:nymip-rg-interest-request at nymip.org?subject=subscribe>
List-Archive: <http://www.nymip.org/pipermail/nymip-rg-interest/>
Date: Mon, 27 Sep 2004 13:11:22 +0100

5th Workshop on Privacy Enhancing Technologies
Dubrovnik, Croatia    May 30 - June 1, 2005

C A L L   F O R   P A P E R S

http://petworkshop.org/2005/

Important Dates:
Paper submission: February 7, 2005
Notification of acceptance: April 4, 2005
Camera-ready copy for preproceedings: May 6, 2005
Camera-ready copy for proceedings: July 1, 2005

Award for Outstanding Research in Privacy Enhancing Technologies
Nomination period: March 4, 2004 through March 7, 2005
Nomination instructions: http://petworkshop.org/award/

-----------------------------------------------------------------------

Privacy and anonymity are increasingly important in the online world.
Corporations, governments, and other organizations are realizing and
exploiting their power to track users and their behavior, and restrict
the ability to publish or retrieve documents. Approaches to
protecting individuals, groups, but also companies and governments
from such profiling and censorship include decentralization,
encryption, distributed trust, and automated policy disclosure.

This 5th workshop addresses the design and realization of such privacy
and anti-censorship services for the Internet and other communication
networks by bringing together anonymity and privacy experts from
around the world to discuss recent advances and new perspectives.

The workshop seeks submissions from academia and industry presenting
novel research on all theoretical and practical aspects of privacy
technologies, as well as experimental studies of fielded systems.  We
encourage submissions from other communities such as law and business
that present their perspectives on technological issues.  As in past
years, we will publish proceedings after the workshop in the Springer
Lecture Notes in Computer Science series.

Suggested topics include but are not restricted to:

* Anonymous communications and publishing systems
* Censorship resistance
* Pseudonyms, identity management, linkability, and reputation
* Data protection technologies
* Location privacy
* Policy, law, and human rights relating to privacy
* Privacy and anonymity in peer-to-peer architectures
* Economics of privacy
* Fielded systems and techniques for enhancing privacy in existing systems
* Protocols that preserve anonymity/privacy
* Privacy-enhanced access control or authentication/certification
* Anonymous credentials
* Election schemes
* Privacy threat models
* Models for anonymity and unobservability
* Attacks on anonymity systems
* Traffic analysis
* Profiling and data mining
* Privacy vulnerabilities and their impact on phishing and identity theft
* Deployment models for privacy infrastructures
* Novel relations of payment mechanisms and anonymity
* Usability issues and user interfaces for PETs
* Reliability, robustness and abuse prevention in privacy systems

Stipends to attend the workshop will be made available, on the basis
of need, to cover travel expenses, hotel, or conference fees.  You do
not need to submit a technical paper and you do not need to be a
student to apply for a stipend.  For more information, see
http://petworkshop.org/2005/stipends.html

General Chair:
Damir Gojmerac (damir.gojmerac at fina.hr), Fina Corporation, Croatia

Program Chairs:
George Danezis (George.Danezis at cl.cam.ac.uk), University of Cambridge, UK
David Martin (dm at cs.uml.edu), University of Massachusetts at Lowell, USA

Program Committee:

Martin Abadi, University of California at Santa Cruz, USA
Alessandro Acquisti, Heinz School, Carnegie Mellon University, USA
Caspar Bowden, Microsoft EMEA, UK
Jean Camp, Indiana University at Bloomington, USA
Richard Clayton, University of Cambridge, UK
Lorrie Cranor, School of Computer Science, Carnegie Mellon University, USA
Roger Dingledine, The Free Haven Project, USA
Hannes Federrath, University of Regensburg, Germany
Ian Goldberg, Zero Knowledge Systems, Canada
Philippe Golle, Palo Alto Research Center, USA
Marit Hansen, Independent Centre for Privacy Protection Schleswig-Holstein,
  Germany
Markus Jakobsson, Indiana University at Bloomington, USA
Dogan Kesdogan, Rheinisch-Westfaelische Technische Hochschule Aachen, Germany
Brian Levine, University of Massachusetts at Amherst, USA
Andreas Pfitzmann, Dresden University of Technology, Germany
Matthias Schunter, IBM Zurich Research Lab, Switzerland
Andrei Serjantov, University of Cambridge, England
Paul Syverson, Naval Research Lab, USA
Latanya Sweeney, Carnegie Mellon University, USA
Matthew Wright, University of Texas at Arlington, USA

Papers should be at most 15 pages excluding the bibliography and
well-marked appendices (using an 11-point font), and at most 20 pages
total.  Submission of shorter papers (from around 4 pages) is strongly
encouraged whenever appropriate.  Papers must conform to the Springer
LNCS style.  Follow the "Information for Authors" link at
http://www.springer.de/comp/lncs/authors.html.

Reviewers of submitted papers are not required to read the appendices
and the paper should be intelligible without them.  The paper should
start with the title, names of authors and an abstract.  The
introduction should give some background and summarize the
contributions of the paper at a level appropriate for a non-specialist
reader.  A preliminary version of the proceedings will be made
available to workshop participants.  Final versions are not due until
after the workshop, giving the authors the opportunity to revise their
papers based on discussions during the meeting.

Submit your papers in Postscript or PDF format.  To submit a paper,
compose a plain text email to pet2005-submissions at petworkshop.org
containing the title and abstract of the paper, the authors' names,
email and postal addresses, phone and fax numbers, and identification
of the contact author (to whom we will address all subsequent
correspondence).  Attach your submission to this email and send it.
By submitting a paper, you agree that if it is accepted, you will sign
a paper distribution agreement allowing for publication, and also that
an author of the paper will register for the workshop and present the
paper there.  Our current working agreement with Springer is that
authors will retain copyright on their own works while assigning an
exclusive 3-year distribution license to Springer.  Authors may still
post their papers on their own Web sites.  See
http://petworkshop.org/2004/paper-dist-agreement-5-04.html for the 2004
version of this agreement.

Submitted papers must not substantially overlap with papers that have
been published or that are simultaneously submitted to a journal or a
conference with proceedings.

Paper submissions must be received by February 7.  We acknowledge all
submissions manually by email.  If you do not receive an
acknowledgment within a few days (or one day, if you are submitting
right at the deadline), then contact the program committee chairs
directly to resolve the problem.  Notification of acceptance or
rejection will be sent to authors no later than April 4 and authors
will have the opportunity to revise for the preproceedings version by
May 6.

We also invite proposals of up to 2 pages for panel discussions or
other relevant presentations.  In your proposal, (1) describe the
nature of the presentation and why it is appropriate to the workshop,
(2) suggest a duration for the presentation (ideally between 45 and 90
minutes), (3) give brief descriptions of the presenters, and (4)
indicate which presenters have confirmed their availability for the
presentation if it is scheduled.  Otherwise, submit your proposal by
email as described above, including the designation of a contact
author.  The program committee will consider presentation proposals
along with other workshop events, and will respond by the paper
decision date with an indication of its interest in scheduling the
event.  The proceedings will contain 1-page abstracts of the
presentations that take place at the workshop.  Each contact author
for an accepted panel proposal must prepare and submit this abstract
in the Springer LNCS style by the "Camera-ready copy for
preproceedings" deadline date.



_______________________________________________
NymIP-rg-interest mailing list
NymIP-rg-interest at nymip.org
http://www.nymip.org/mailman/listinfo/nymip-rg-interest

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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 majordomo at metzdowd.com