Re: PGP & GPG compatibility

[Derek Atkins]

Will Price <[EMAIL PROTECTED]> writes:

> The SDK (which still includes little bits of your code Derek, and all
> other crypto/network/passphrase and even all the UI code which
> interacts with the crypto related code) has been published up through
> 7.1.1. The Windows GUI was last published at 6.5.8.

Does this include the Unix CLI?  (And yes, I know a lot of my code is
in there.. I was amused when I ported 6.5.8 to Tru64.  I was also
surprised (but relieved) at the re-write of the Ascii Parser).

> > Worse, there are a couple of bugs I found in 6.5.8 when
> > I was porting it to Tru64, but who knows if anyone is
> > listening over at NAI.
> 
> I don't know who you sent these to. You could always have sent diffs
> directly to me to make sure they get handled. The official address
> for these things remains [EMAIL PROTECTED] I am on that list so you
> couldn't have sent it to that one either since I haven't seen any
> diffs from you ever as far as I can recall.

I sent patches to [EMAIL PROTECTED]  Is [EMAIL PROTECTED] documented
anywhere?  The particular bug is the COMMENT handling in the binary
parser.

> Side note, this may all be a moot point if a "transition agreement
> with a purchasing vendor" is not worked out RSN.

So, um, what happens then?  If NAI cannot find a buyer, will they bury
the code?  Or will NAI donate the code to the OpenSource community?
If they cannot find a buyer will they relinguish the commercial rights
to the OpenSource version (i.e. so that commercial entities can use
the freeware)?

> -- Will
> 
> Will Price, Director of Engineering
> PGP Security, Inc.
> a division of Network Associates, Inc.

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   [EMAIL PROTECTED]PGP key available



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

Re: PGP & GPG compatibility

[Will Price]

Werner Koch wrote:
> According to the bug reports I receive for GnuPG, it seems that
> even the latest versions of PGP (7.0.3?) are still not OpenPGP
> compatible.  

No, the latest version for Win32 is 7.1.1, and for MacOS 9 it is
7.1.0. I think it should be pointed out what a loaded statement the
above is as well. That's like saying, "have you stopped beating your
wife?" I would encourage some objectivity on that.

> At least they still don't understand version 4 signatures on data
> packets (only on keys).  I had in mind that this was fixed some
> time ago, but obviously this isn't the case.

I'm fairly sure we support that in 7.1.0 and up.

> There is a problem wrt text mode signatures: [..]

That's not the only problem with text mode signatures. International
characters present an even larger challenge. Most of this is not
PGP/GPG's problem technically. The plethora of mail clients out there
don't handle it well either. Going forward, UTF8 migration is likely
to cause some growing pains for everybody.

> Interoperability tests should have happened last summer but for
> unknown reasons they didn't.  It is very sad to see that after 3
> years we have not achieved to get OpenPGP into draft status :-(.

It is a mystery to us as well what happened with that... We were
ready to proceed, but we were not the organizer so it was out of our
hands.

Derek Atkins wrote:
> Is there even development on the PGP (product) line?

Well, yes, but see:

http://www.pgp.com/other/jump/customer-faq.asp

The products you know as "PGP" are in a "maintenance mode" "until a
transition agreement is developed with a purchasing vendor". So, we
currently are in the process of working through that. We just
released PGP 7.1.1 last week, so development does continue in the
meantime.

> AFAIK they (NAI) have not release PGP 7.x in source form.

Not true. See:

http://www.pgp.com/downloads/pgpsdk-agreement.asp

The SDK (which still includes little bits of your code Derek, and all
other crypto/network/passphrase and even all the UI code which
interacts with the crypto related code) has been published up through
7.1.1. The Windows GUI was last published at 6.5.8.

> Worse, there are a couple of bugs I found in 6.5.8 when
> I was porting it to Tru64, but who knows if anyone is
> listening over at NAI.

I don't know who you sent these to. You could always have sent diffs
directly to me to make sure they get handled. The official address
for these things remains [EMAIL PROTECTED] I am on that list so you
couldn't have sent it to that one either since I haven't seen any
diffs from you ever as far as I can recall.

> I think people used to get better support when I personally
> answered [EMAIL PROTECTED]  I stopped providing that service due to
> lack of time, and I'm afraid that PGP support went out the window. 
> From my perspective, NAI never provided any support for PGP -- even
> when I submitting patches, they would ignore them.

It's always nice to find people willing and able to provide support
for free. In the real world, that rarely happens even for free
products (Cygnus, etc.). Outside firms have rated our PGP support 6.3
out of 7 based on customer surveys. Mind you, the people surveyed are
the people who pay for the software. Our support really is quite good
for enterprise customers, but admittedly can be considered weak or
non-existent for freeware users. Without a support contract, I can
see how some people could find PGP support frustrating. Many of our
developers lurk in PGP newsgroups/mailing lists though and regularly
help users out there on an informal basis.

A few weeks ago, I spent over $30 on a support call to Intuit. I was
incensed! I almost paid more to ask them why it doesn't work than I
did to buy their product. On the other hand, I don't see how else
they could do it and still make money. I don't really see any great
solutions to mass consumer tech support, and frankly there isn't much
of a paying market among consumers anyway. So, I applaud all those
who offer free support, I do it myself quite often, but there's only
so much time in a day.

Side note, this may all be a moot point if a "transition agreement
with a purchasing vendor" is not worked out RSN.

-- Will

Will Price, Director of Engineering
PGP Security, Inc.
a division of Network Associates, Inc.





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

Re: Linux-style kernel PRNGs and the FIPS140-2 test

[Jim Gillogly]

Thor Lancelot Simon wrote:
> 
> Many operating systems use "Linux-style" (environmental noise
> stirred with a hash function) generators to provide "random"
> and pseudorandom data on /dev/random and /dev/urandom
> respectively.
...
> The usual failure mode is "too many runs of 1 1s".  Using MD5
> instead of SHA1 as the mixing function, the Linux generator
> also displays "too many runs of 1 0s".  I have not yet seen
> other failure modes from these generators.
> 
> To reproduce my results, just compile the enclosed and do
> "a.out < /dev/urandom" on your platform of choice.

Last October in sci.crypt Greg Rose of Qualcomm reported:
- Furthermore, on October 10, a change notice was
- appended to the FIPS, to correct the false-alarm
- rate of the the Runs Test.

He went on to say:
- I believe that the reason the tests were updated
- was because the 1% error bound was too "loose".
- Basically, with about 10 independent tests being
- run, you could expect perfectly functional
- hardware to fail the power-on checks about one
- time in 20, for no good reason. The new bounds are
- still pretty good at detecting true
- non-randomness, particularly the kind that comes
- from typical hardware problems, but with a much
- smaller false-alarm rate. ...

- BTW, I've updated my fips140.c program to the new,
- correct, Runs Test values, and will send it to
- people if they want it. Hopefully we will soon

The internal date on the copy of Greg's fips140.c program
that you included with this message is 2000, so I imagine
you're using the old version.  Have you tried his newer
version, i.e. the one he believes reflects the current state
of FIPS140?
-- 
Jim Gillogly
Hevensday, 25 Afteryule S.R. 2002, 01:03
12.19.8.16.5, 13 Chicchan 3 Muan, First Lord of Night



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

Re: CFP: PKI research workshop

[Enzo Michelangeli]

> Here you're talking about "reputation of nyms", which doesn't require
> third parties or certs, just well-kept secret keys of a PK pair.
> If the remote entity keeps using the same PK keys, you can reasonably
> update reputation
> based on that alone.   (They're essentially signing their behaviors.)

On the other hand it must be said that, if reputation really worked as we
would like, some sloppy and deservingly accident-prone Certification
Authorities would be out of business by now.

Enzo





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

Re: Linux-style kernel PRNGs and the FIPS140-2 test

[Adam Fields]

"Arnold G. Reinhold" says:
> This result would seem to raise questions about SHA1 and MD5 as much 
> as about the quality of /dev/random and /dev/urandom.  Naively, it 
> should be difficult to create input to these hash functions that 
> cause their output to fail any statistical test.

I would think that this would only be relevant if there was a
correlation between inputs and outputs. Lack of entropic skew across
the bits of the output shouldn't give any clues to the specific input,
unless the outputs are clumping across the output
space. Theoretically, the hash functions ought to be able to output
every bit string in the output space, so you'd realistically expect a
fair number of runs.

You're right - it should be difficult to create inputs to the hash
functions that cause their output to fail a distribution test, but
doing so casts doubt on the randomness of the inputs, not the
distribution space of the hash.

At least I think that's right - it's been a while since I've thought
about this.



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

Re: Linux-style kernel PRNGs and the FIPS140-2 test

[[EMAIL PROTECTED]]

At 03:23 PM 1/15/2002 -0500, Thor Lancelot Simon wrote:
>Many operating systems use "Linux-style" (environmental noise
>stirred with a hash function) generators to provide "random"
>and pseudorandom data on /dev/random and /dev/urandom
>respectively.  A few modify the general Linux design by adding an
>output buffer which is not stirred so that bits which have already
>been output are not stirred into the pool of "new" "random" data
>(IMO, not doing this is insane, but that's a different subject).
>
>The enclosed implementation of the FIPS140-1/2 statistical test
>appears to show that such generators fail the "runs" test quite
>regularly.  Interestingly, the Linux generator seems to do better
>the longer you let it run (which, perhaps, suggests that quite a
>bit of data should be run through it at boot time and discarded)
>but other, related generators do not.
>
>The usual failure mode is "too many runs of 1 1s".  Using MD5
>instead of SHA1 as the mixing function, the Linux generator
>also displays "too many runs of 1 0s".  I have not yet seen
>other failure modes from these generators.
>
>To reproduce my results, just compile the enclosed and do
>"a.out < /dev/urandom" on your platform of choice.
>
>Thor
>

What happens when you do it to /dev/random?

My understanding was that /dev/random while on return data if it
has enough entrophy , otherwise it blocks. /dev/urandom will get its
values from /dev/random until it blocks then it continues by output psuedo 
garbage.

The use of /dev/urandom is for non-cryptographic stuff that can't block
on it's reads, like a read to /dev/random would.

Plus, shouldn't you only be using it as a seed to a Yarrow or a FIPS PRNG 
like X917?





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

Re: Linux-style kernel PRNGs and the FIPS140-2 test

[Arnold G. Reinhold]

This result would seem to raise questions about SHA1 and MD5 as much 
as about the quality of /dev/random and /dev/urandom.  Naively, it 
should be difficult to create input to these hash functions that 
cause their output to fail any statistical test.

Arnold Reinhold

At 3:23 PM -0500 1/15/02, Thor Lancelot Simon wrote:
>Many operating systems use "Linux-style" (environmental noise
>stirred with a hash function) generators to provide "random"
>and pseudorandom data on /dev/random and /dev/urandom
>respectively.  A few modify the general Linux design by adding an
>output buffer which is not stirred so that bits which have already
>been output are not stirred into the pool of "new" "random" data
>(IMO, not doing this is insane, but that's a different subject).
>
>The enclosed implementation of the FIPS140-1/2 statistical test
>appears to show that such generators fail the "runs" test quite
>regularly.  Interestingly, the Linux generator seems to do better
>the longer you let it run (which, perhaps, suggests that quite a
>bit of data should be run through it at boot time and discarded)
>but other, related generators do not.
>
>The usual failure mode is "too many runs of 1 1s".  Using MD5
>instead of SHA1 as the mixing function, the Linux generator
>also displays "too many runs of 1 0s".  I have not yet seen
>other failure modes from these generators.
>
>To reproduce my results, just compile the enclosed and do
>"a.out < /dev/urandom" on your platform of choice.
>
>Thor
>
>Attachment converted: Arnold's iMac:fips140.c (TEXT/ttxt) (0011EDDD)




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

Re: PGP & GPG compatibility

[Derek Atkins]

Matt Crawford <[EMAIL PROTECTED]> writes:

> > Is there even development on the PGP (product) line?  AFAIK
> > they (NAI) have not release PGP 7.x in source form.  Worse, there
> > are a couple of bugs I found in 6.5.8 when I was porting it
> > to Tru64, but who knows if anyone is listening over at NAI.
> 
> Years ago I bought a few copies of commercial PGP with support.  I
> sent in three separate bug reports, some of them dead simple to
> reproduce, and never got anything back except placebo talk.

I think people used to get better support when I personally answered
[EMAIL PROTECTED]  I stopped providing that service due to lack of
time, and I'm afraid that PGP support went out the window.  From my
perspective, NAI never provided any support for PGP -- even when I
submitting patches, they would ignore them.

Even worse, when I *DID* respond to someone on pgp-bugs, I'd get a
response from NAI saying that they couldn't help me!  Yes, those
bozos actually responded to my _answer_ with a "we cannot help you"
message.  Sigh.

So, no, I'm not surprised to hear this from an actual paying customer.

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   [EMAIL PROTECTED]PGP key available



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

Re: PGP & GPG compatibility

[Matt Crawford]

> Is there even development on the PGP (product) line?  AFAIK
> they (NAI) have not release PGP 7.x in source form.  Worse, there
> are a couple of bugs I found in 6.5.8 when I was porting it
> to Tru64, but who knows if anyone is listening over at NAI.

Years ago I bought a few copies of commercial PGP with support.  I
sent in three separate bug reports, some of them dead simple to
reproduce, and never got anything back except placebo talk.



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

Re: Linux-style kernel PRNGs and the FIPS140-2 test

[Adam Fields]

Thor Lancelot Simon says:
> Many operating systems use "Linux-style" (environmental noise
> stirred with a hash function) generators to provide "random"
> and pseudorandom data on /dev/random and /dev/urandom
> respectively.  A few modify the general Linux design by adding an
> output buffer which is not stirred so that bits which have already
> been output are not stirred into the pool of "new" "random" data
> (IMO, not doing this is insane, but that's a different subject).
[...]

Does the above description also apply to truerand, or is that subtly
different?
- Adam

-
Surgam, Inc. is a technology consulting firm with strong background in
delivering robust and scalable enterprise web and IT applications.
http://www.surgam.net



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

Linux-style kernel PRNGs and the FIPS140-2 test

[Thor Lancelot Simon]

Many operating systems use "Linux-style" (environmental noise
stirred with a hash function) generators to provide "random"
and pseudorandom data on /dev/random and /dev/urandom
respectively.  A few modify the general Linux design by adding an
output buffer which is not stirred so that bits which have already
been output are not stirred into the pool of "new" "random" data
(IMO, not doing this is insane, but that's a different subject).

The enclosed implementation of the FIPS140-1/2 statistical test
appears to show that such generators fail the "runs" test quite
regularly.  Interestingly, the Linux generator seems to do better
the longer you let it run (which, perhaps, suggests that quite a
bit of data should be run through it at boot time and discarded)
but other, related generators do not.

The usual failure mode is "too many runs of 1 1s".  Using MD5
instead of SHA1 as the mixing function, the Linux generator
also displays "too many runs of 1 0s".  I have not yet seen
other failure modes from these generators.

To reproduce my results, just compile the enclosed and do
"a.out < /dev/urandom" on your platform of choice.

Thor


/*
This software is free for commercial and non-commercial use
subject to the following conditions.

Copyright remains vested in QUALCOMM Incorporated, and Copyright
notices in the code are not to be removed.  If this package is used in
a product, QUALCOMM should be given attribution as the author this
software.  This can be in the form of a textual message at program
startup or in documentation (online or textual) provided with the
package.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

1. Redistributions of source code must retain the copyright notice,
   this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the
   distribution.

3. All advertising materials mentioning features or use of this
   software must display the following acknowledgement:  This product
   includes software developed by QUALCOMM Incorporated.

THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

The license and distribution terms for any publically available version
or derivative of this code cannot be changed, that is, this code cannot
simply be copied and put under another distribution license including
the GNU Public License.
*/

/* Run FIPS 140 statistical tests on a file */
/* written by Greg Rose, Copyright C 2000 QUALCOMM Incorporated */

/* FIPS 140-2 significantly tightens the bounds. */
#define VER2 1  /* undefine to get FIPS 140-1 */

#include 
#include 
#include 

char*myname;
int bitnum = 0;

typedef unsigned char   uchar;

#define NBITS 2
uchar   b[NBITS/8];
int poker[16];
int runs[2][7];
int nerrs;
int verbose = 0;

#ifdef  VER2
int minrun[7] = { 0, 2343, 1135, 542, 251, 111, 111 };
int maxrun[7] = { 0, 2567, 1365, 708, 373, 201, 201 };
#define LONGRUN 26
#define MINONES 9725
#define MAXONES 10275
#define MINPOKE 2.16
#define MAXPOKE 46.17
#else   /* VER2 */
int minrun[7] = { 0, 2267, 1079, 502, 223, 90, 90 };
int maxrun[7] = { 0, 2733, 1421, 748, 402, 233, 233 };
#define LONGRUN 34
#define MINONES 9654
#define MAXONES 10346
#define MINPOKE 1.03
#define MAXPOKE 57.4
#endif /* VER2 */

/* Population count of 1's in a byte */
unsigned char Popcount[] = {
 0, 1, 1, 2, 1, 2, 2, 3, 1, 2, 2, 3, 2, 3, 3, 4,
 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5,
 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5,
 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,
 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5,
 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,
 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,
 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7,
 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5,
 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,
 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,
 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7,
 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,
 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7,
 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7,
 4, 5, 5, 6, 5, 6, 6, 7, 5, 6, 6, 7, 6, 7, 7,

Re: PGP & GPG compatibility

[Derek Atkins]

Is there even development on the PGP (product) line?  AFAIK
they (NAI) have not release PGP 7.x in source form.  Worse, there
are a couple of bugs I found in 6.5.8 when I was porting it
to Tru64, but who knows if anyone is listening over at NAI.

It's a sad state of affairs.  Perhaps I should go into "PGP
consulting", but I don't know if anyone would pay me to support
PGP for them

-derek

Werner Koch <[EMAIL PROTECTED]> writes:

> On Sat, 3 Jan 1970 09:41:26 +1000, Nicholas Brawn said:
> 
> > What's the state of the game with PGP and GPG compatibility?
> 
> According to the bug reports I receive for GnuPG, it seems that even
> the latest versions of PGP (7.0.3?) are still not OpenPGP compatible.
> At least they still don't understand version 4 signatures on data
> packets (only on keys).  I had in mind that this was fixed some time
> ago, but obviously this isn't the case.
> 
> There is a problem wrt text mode signatures: no agreement was found on
> what a line ending consists of.  PGP translates a CR inside a line
> (well, what most non Apple programmers consider a line ending) into a
> CR,LF sequence for hashing.  The proper solution is not to use
> textmode signatures except for cleartext signed messages.
> 
> About two years ago we agreed on a way to implement MDC and defined
> new packet types for it.  I did some tests with Hal Finney and it used
> to work.  The OpenPGP draft was later changed to introduce key flags
> and use one to enable MDC mode.  However, GnuPG uses MDC mode with all
> ciphers of a block length other than 64 bits (i.e. Twofish and AES*).
> The draft has still not been released as a new RFC so this may change
> again :-(.
> 
> The flaw in the secret key protection mechanism was discussed for a
> short time but it seems that nobody is willing to continue with this.
> I made several suggestion on how to do it.
> 
> Interoperability tests should have happened last summer but for
> unknown reasons they didn't.  It is very sad to see that after 3 years
> we have not achieved to get OpenPGP into draft status :-(.
> 
> 
>   Werner
> 
> -- 
> Werner KochOmnis enim res, quae dando non deficit, dum habetur
> g10 Code GmbH  et non datur, nondum habetur, quomodo habenda est.
> Privacy Solutions-- Augustinus
> 
> 
> 
> 
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   [EMAIL PROTECTED]PGP key available



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

Re: CFP: PKI research workshop

[D. A. Honig]

>[The
>question isn't some sort of mystification of identity -- it is being
>able to know that you're talking to the same "Dear Abby" your friends
>have talked to and that you talked to last week. 

Here you're talking about "reputation of nyms", which doesn't require
third parties or certs, just well-kept secret keys of a PK pair.  
If the remote entity keeps using the same PK keys, you can reasonably
update reputation
based on that alone.   (They're essentially signing their behaviors.)

[Moderator's note: I fully agree. I was disputing only the notion that
unauthenticated connections were sufficient. Authentication does not
require certificates or third parties -- see the way SSH handles keys
for example. --Perry]


>Now that MIM attacks
>have been automated they don't even need sophistication to conduct. --Perry]

Since a signed cert is useful for recovering ZERO dollars from the signer,
if you've been defrauded by some entity, the end result is the same if a MIM 
defrauds you.  

A *trusted* signer would solve the confidentiality loss problem but not the
financial
liability problem.  But given that signers will sign *anything* (and why
not, they have no
financial liability and little useful reputation to lose) this is a small
difference.

dh














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

Re: CFP: PKI research workshop

[Eugene Leitl]

On Tue, 15 Jan 2002, D. A. Honig wrote:

> [Moderator's note: Except that's precisely the point: "Modulo MIM
> attacks" is like saying "we're all immortal, modulo death". The
> question isn't some sort of mystification of identity -- it is being
> able to know that you're talking to the same "Dear Abby" your friends
> have talked to and that you talked to last week. Now that MIM attacks
> have been automated they don't even need sophistication to conduct.
> --Perry]

It requires sophistication to do MIM on a large scale. Active realtime
manipulation of traffic on the global scale is currently beyond the scope
of TLAs (but they're probably rather good at passive listening by now).
Especially, if the initial key exchange is cached, as there's temporal
constraints on the window of vulnerability.

It's not a minor point, and hence needs repeating.

Plus, web of trust mechanisms can always be added later. Rolling out
crypto on a massive scale (MUA-MTA, MTA-MTA, IM, P2P) is where's it's at.

[Moderator's note: This is simply wrong in a commerce situation. I
cannot emphasize that strongly enough. There are tools to assist in
doing MIM attacks out there, and doing it globally isn't needed --
doing it in front of one of amazon.com's ssl servers is what you need
to do, and there are few large installations out there without even a
single vulnerable machine. You need authentication to trust an
encrypted connection, and if you use a connection in commerce you need
to trust it. Even if your one transaction is low value a large site
puts through huge numbers of those low value transactions. --Perry]

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

Re: PGP & GPG compatibility

[Werner Koch]

On Tue, 15 Jan 2002 09:42:32 +0100, Axel H Horns said:

> I'm using PGP 6.5.8 for my professional confidential e-mails and 
> sometimes I get complaints from GnuPG users saying they can't use my 
> Pubkey. 

So, you can't decrypt the attached message?  Or does this problem
only occur with another key?  I have never received a bug report
regarding such a problem.

BTW, even NAI says that PGP (before 7.0) is not OpenPGP compliant.

  Werner

-- 
Werner KochOmnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH  et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions-- Augustinus



x
Description: Binary data

Workshop on Economics and Information Security

[R. A. Hettinga]

http://www.cl.cam.ac.uk/users/rja14/econws.html




Workshop on Economics and Information Security

University of California, Berkeley

May 16-17, 2002


Do we spend enough on keeping `hackers' out of our computer systems? Do we
not spend enough? Or do we spend too much?

Many system security failures occur not so much for technical reasons but
because of failures of organisation and motivation. For example, the person
or company best placed to protect a system may be insufficiently motivated
to do so, because the costs of system failure fall on others. Such perverse
incentives raise many issues best discussed using economic concepts such as
externalities, asymmetric information, adverse selection and moral hazard.
They are becoming increasingly important now that information security
mechanisms are not merely used to protect against malicious attacks, but
also to protect monopolies, differentiate products and segment markets.
There are also interesting security issues raised by industry
monopolization and the accompanying reduction in product heterogenity. For
these and other reasons, the confluence between information security and
economics is of growing importance.

We are organising the first workshop on the topic, to be held in the School
of Information Management and Systems at the University of California,
Berkeley, on the 16th and 17th May 2002. In order to keep the event
informal and interactive, attendance will be limited to about 30-35
participants. If you would like to participate, please send us a position
paper (of 1-2 pages) by the 31st March 2002.

We welcome interest not just from economists and information security
professionals, but from people with relevant experience, such as in the
insurance industry, corporate risk management, or law enforcement agencies.

Program committee:

*   Hal Varian (program co-chair)
*   Ross Anderson   (program co-chair)
*   Doug Tygar (general chair)
*   Jean Camp
*   Li Gong
*   Larry Gordon
*   Marty Loeb
*   Andrew Odlyzko
*   Bruce Schneier

Position papers and expressions of interest should be sent to either
co-chair - Hal Varian [EMAIL PROTECTED] or Ross Anderson
[EMAIL PROTECTED]


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



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

Re: CFP: PKI research workshop

[D. A. Honig]

At 01:59 PM 1/14/02 -0800, Eric Rescorla wrote:
>Saying that SSL without certificates is fine as long as you
>don't have active attacks is kind of like saying that leaving
>your front door open is fine as long as noone tries to break
>in.

No, its more.  SSL sans certs is like using envelopes to write to
Dear Abby.  You have no authentication on who Dear Abby 
"really is" but your communications are private.

Since the entity who claims to be Dear Abby also gives
a communications address, writing to Dear Abby at that 
address is sufficient. (Modulo MIM attacks)

[Moderator's note: Except that's precisely the point: "Modulo MIM
attacks" is like saying "we're all immortal, modulo death". The
question isn't some sort of mystification of identity -- it is being
able to know that you're talking to the same "Dear Abby" your friends
have talked to and that you talked to last week. Now that MIM attacks
have been automated they don't even need sophistication to conduct. --Perry]

When you call a phone number listed with an advert, 
and give them your credit card number, you have less
confidentiality (you're speaking plaintext), but its the same model.





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

Re: High-tech Thieves Snatch Data From ATMs

[Jim Cheesman]

Something similar happened in England a few years back: Some "cybercrooks"* 
set up an entire false bank - only the shop frontage and the cash machine, 
which would display the customary "Sorry this service not available blah 
blah blah" message if the user tried to get cash out. I believe the bank 
was Nationwide, and that the scam run for at least a month before anyone 
caught on.

I currently have no web access, so no links, no details - sorry.


*Why "cyber"crooks?

Best,
Jim

At 09:32 PM 10/01/02, R. A. Hettinga wrote:
>http://dailynews.yahoo.com/htx/abc/20020110/bs/atmfraud020110_1.html
>
>
>
>Thursday January 10 03:26 PM EST
>
>High-tech Thieves Snatch Data From ATMs
>By Paul Eng ABCNEWS.com
...

--

   *   Jim Cheesman   *
 Trabajo: 
[EMAIL PROTECTED] - (34)(91) 724 9200 x 2360
   The shortest distance between 
two points is how far apart they are.





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

RAND Book; Networks and Netwars: The Future of Terror, Crime, andMilitancy"

[R. A. Hettinga]

http://www.rand.org/publications/news/releases/netwars.html

The book in .pdf: http://www.rand.org/publications/MR/MR1382/

News from RAND
Contact: John Warren
RAND
Tel: 310-393-0411, ext. 6293
Fax: 310-451-6996
Email: [EMAIL PROTECTED]
http://www.rand.org
RAND
1700 Main Street
P.O. Box 2138
Santa Monica, CA 90407-2138

1200 South Hayes Street
Arlington VA 22202-5050
703-413-1100


The Growing Power of Networks

The tragic events of September 11th made brutally clear that the fight for
the future is not between the armies of leading states, nor are its weapons
those of conventional armed forces. Rather, today's combatants come from
terrorist groups like Osama bin Laden's al-Qaeda, or drug smuggling cartels
like those ravaging Colombia and Mexico. On the positive side are
non-violent, civil-society activists fighting for the environment,
democracy and human rights. What all have in common is that they operate in
small, dispersed units that can deploy nimbly-anywhere, anytime. They know
how to penetrate and disrupt, as well as elude and evade. They all feature
network forms of organization, doctrine, strategy, and technology attuned
to the information age. And, from al-Qaeda to the Intifadah to the drug
war, they are proving very hard to beat...

Networks and Netwars: The Future of Terror, Crime, and Militancy, by John
Arquilla and David F. Ronfeldt, Editors, (RAND, 2001) examines this new
spectrum of conflict emerging in the wake of the information revolution.
Netwar includes conflicts waged, on the one hand, by terrorists, criminals,
gangs, and ethnic extremists; and by civil-society activists (such as cyber
activists or WTO protestors) on the other. What distinguishes netwar is the
networked organizational structure of its practitioners-with many groups
actually being leaderless-and their quickness in coming together in
swarming attacks.

Completed shortly before terrorists attacked New York and Washington, the
volume includes an Afterword analyzing the Attack on America. The events of
September 11, 2001, tragically reinforced Arquilla and Ronfeldt's
conclusion that in order to confront this new type of conflict, it is
crucial for governments, military, and law enforcement to begin networking
themselves.

"Just as a half century ago, researchers at RAND sought to understand the
profound changes in strategy brought about by nuclear weapons and
intercontinental ballistic missiles," says Brian Michael Jenkins, one of
the world's foremost experts on terrorism and crime, "Arquilla and Ronfeldt
explore the strategic implications of new information technologies in the
latest installment of their seminal work... Networks and Netwars obliges us
to think in new ways."

In Networks and Netwars, the editors and their colleagues examine the major
instances of netwar that have occurred over the past several years-from
Osama bin Laden's networked terrorists to the Battle of Seattle's social
activists-and find, among other things, that netwars have generally been
successful from the protagonists' perspective.

The authors also find that, despite their diversity, all networks built for
waging netwar may be analyzed in terms of a common analytic framework.
There are five critical levels of theory and practice: the technological,
social, narrative, organizational, and doctrinal levels. A netwar actor
must get all five right to be fully effective. The most potent netwarriors
will not only be highly networked and have the capacity for mounting
"swarming" attacks, they will also be held together by strong social ties,
have secure communications technologies, and project a common "story" about
why they are together and what they need to do. Like Osama Bin Laden's
al-Qaeda, these are the most serious adversaries. But even those networks
that are weak on some levels may pose stiff challenges to their
nation-state adversaries.

With this in mind, it is necessary to go beyond simply diagnosing the
nature of the networked nonstate opponent in a given conflict. "A
particular challenge for the cumbersome American bureaucracy will be to
encourage deep, all-channel networking among the military, law enforcement,
and intelligence elements whose collaboration is crucial for achieving
success," Arquilla and Ronfeldt explain in the Afterword. "U.S. agencies
have been headed in this direction for years-in the areas of
counter-narcotics as well as counterterrorism-but interagency rivalries and
distrust have too often slowed progress."

Writers who focus on the technological aspects of netwar often miss the
point. As the editors point out, "At its heart, Netwar is far more about
organization and doctrine than it is about technology. The outcomes of
current and future netwars are bound to confirm this."

Nathan Gardels, editor of New Perspectives Quarterly, and author of The
Changing Global Order, says "Arquilla and Ronfeldt are a rare breed:
strategic thinkers of the information age. In Networks and Netwars they
grasp an emerging real

Re: PGP & GPG compatibility

[Werner Koch]

On Sat, 3 Jan 1970 09:41:26 +1000, Nicholas Brawn said:

> What's the state of the game with PGP and GPG compatibility?

According to the bug reports I receive for GnuPG, it seems that even
the latest versions of PGP (7.0.3?) are still not OpenPGP compatible.
At least they still don't understand version 4 signatures on data
packets (only on keys).  I had in mind that this was fixed some time
ago, but obviously this isn't the case.

There is a problem wrt text mode signatures: no agreement was found on
what a line ending consists of.  PGP translates a CR inside a line
(well, what most non Apple programmers consider a line ending) into a
CR,LF sequence for hashing.  The proper solution is not to use
textmode signatures except for cleartext signed messages.

About two years ago we agreed on a way to implement MDC and defined
new packet types for it.  I did some tests with Hal Finney and it used
to work.  The OpenPGP draft was later changed to introduce key flags
and use one to enable MDC mode.  However, GnuPG uses MDC mode with all
ciphers of a block length other than 64 bits (i.e. Twofish and AES*).
The draft has still not been released as a new RFC so this may change
again :-(.

The flaw in the secret key protection mechanism was discussed for a
short time but it seems that nobody is willing to continue with this.
I made several suggestion on how to do it.

Interoperability tests should have happened last summer but for
unknown reasons they didn't.  It is very sad to see that after 3 years
we have not achieved to get OpenPGP into draft status :-(.


  Werner

-- 
Werner KochOmnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH  et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions-- Augustinus




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

[PLANNING FEB CPUNKS] Who's going to be in the Bay Area in February for RSA?

[Bill Stewart]

The RSA Conference will be in San Jose the week of Feb 18-22.
http://www.rsaconference.net/indexforrsa.html
As usual, that means a lot of cypherpunks will be in town,
and we move the meeting to whichever weekend works best.
This year, that's Saturday the 16th, and it's Presidents' Day Weekend.
It's also Codecon 2002  http://codecon.org/ , a conference on
peer-to-peer, crypto, and similar applications,
designed for presentations about actual working code.
The conference will be at the DNA Lounge, 375 11th St, San Francisco.

The not-totally-firm plans are to have the cypherpunks meeting
at Codecon on Saturday afternoon (the conference is Friday-Sunday).
Bram (the conference organizer) will probably be able to comp us attendance
(the full conference is $50), but he needs to do a schedule.
Some of the crypto projects being talked about include Cryptomail
and Zooko talking about Mojo Nation derivatives.

Who's going to be in town that weekend?
Would you like to speak at the Cypherpunks meeting,
either as an organized talk or as a works-in-progress session?

Thanks;  Bill Stewart




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

Re: PGP & GPG compatibility

[Axel H Horns]

On 3 Jan 2070, at 9:41, Nicholas Brawn wrote:

> What's the state of the game with PGP and GPG compatibility?

Interesting question.

I'm using PGP 6.5.8 for my professional confidential e-mails and 
sometimes I get complaints from GnuPG users saying they can't use my 
Pubkey. 

Currently I'm preparing an article on Internet security issues 
related to the businesses of attorneys-at-law and patent attorneys. 
In this context, it is already a hard job to promote usage of e-mail 
encryption, and such incompatibilities between various versions of 
PGP and GnuPG marke it even harder.  

Is there any URL available where I might get more detailed info?

Thanks.

Regards,

Axel H Horns

-- 
Patentanwalt Dipl.-Phys. Axel H Hornse-Mail [EMAIL PROTECTED]
Web www.ipjur.com  Voice ++49.89.30630112  Fax ++49.89.30630113
My PGP RSA Key ID = 0xD8433289 http://www.ipjur.com/pubkey.php3
PGP Pubkey Fingerprint C5D2 5E53 D241 4988  17E4 904D 9467 31BC




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