Cryptography-Digest Digest #15, Volume #14 Mon, 26 Mar 01 15:13:01 EST
Contents:
Re: Deny Anon Remailers access to this newsgroup (Darren New)
Re: Kill-filter expression for script weenie (Marc)
Re: Deny Anon Remailers access to this newsgroup (Paul Rubin)
Re: Popularity of AES (David Hopwood)
Re: Encrypt then HMAC or HMAC then Encrypt? (David Hopwood)
Re: TEA, Blowfish with non-random data? ("Paul Pires")
Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged
("Roger Schlafly")
Re: Kill-filter expression for script weenie ("Paul Pires")
RC4 ("Ryan M. McConahy")
ECDSA question ("Cristiano")
Re: Deny Anon Remailers access to this newsgroup (Joe H Acker)
Re: New stream cipher ("Paul Pires")
Re: Kill-filter expression for script weenie ("Ryan M. McConahy")
Please read. ("Paul Pires")
Re: Please read. (John Savard)
Re: RC4 ("Paul Pires")
Re: Please read. ("Paul Pires")
Kill-file entries for TRN to nuke the weenie! (was Re: Kill-filter expression for
script weenie) (Ben Cantrick)
Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged ("Sam
Simpson")
----------------------------------------------------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Deny Anon Remailers access to this newsgroup
Date: Mon, 26 Mar 2001 18:10:32 GMT
David A Molnar wrote:
> There are at least two reasons why cryptography discussion groups, sci.crypt
> in particular, might be a good place for the use of anon remailers.
You forgot number three: Your ex-blood relatives might be trying to deport
you to Finland.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
A million monkeys in a room with a million typewriters
will only yield half a million pregnant monkeys.
------------------------------
From: [EMAIL PROTECTED] (Marc)
Crossposted-To: alt.security.pgp
Subject: Re: Kill-filter expression for script weenie
Date: 26 Mar 2001 18:36:30 GMT
>For Xnews (and slrn?):
>
> Score: -9999
> Expires: 4/25/2001
> Subject: (love|need|ask|require|use(s|d)|want)
> From: (anonymous|melon|frog2|remailer|steeleye|nescio)
Doesn't work for me. I'm using XNews 3.08.28. First it complains about
the data format and when re-ordering it it keeps quiet but does not
score anything.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Deny Anon Remailers access to this newsgroup
Date: 26 Mar 2001 10:36:39 -0800
[EMAIL PROTECTED] (John Joseph Trammell) writes:
> [3] You pays your money, you takes your choice. If the only
> alternative is banning all anon posting, I still think it's
> the right response.
Doing some selective filtering against the SK at the m2n gateway might
be appropriate. Filtering all anonymous posts is precisely what the
SK wants, so doing it would be surrendering to him/her/it. We should
not meekly hand control of our newsgroup over to some spamming idiot
that way.
------------------------------
Date: Sun, 25 Mar 2001 15:37:12 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Re: Popularity of AES
=====BEGIN PGP SIGNED MESSAGE=====
Paul Crowley wrote:
> Thomas Boschloo <[EMAIL PROTECTED]> writes:
> > Will the final AES e.g. have extra rounds on it like they did with
> > Square
>
> No. The NIST team stated their reasons for not extending the rounds
> in the paper explaining their choice of AES, and the draft FIPS has
> the same number of rounds as the Rijndael specification.
>
> It's pretty much certain that the final AES cipher will be the same
> one as the cipher in the draft FIPS, which is the same cipher as that
> specified in the original Rijndael paper.
There was a minor error in the original Rijndael paper (in the description
of key scheduling, IIRC). You mean the corrected Rijndael paper
(http://www.esat.kuleuven.ac.be/~rijmen/rijndael/rijndaeldocV2.zip).
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOr4QiTkCAxeYt5gVAQFjjgf/TgCStXZa1Fq95VM6R/efeus4jzzAVXZs
lcdpbbObRblpTcGrJBVSgGQ58CgfdwV0XzuGS9dcr5EOmKfAL9Rpibgs39cE8HFG
6cq3mNlDWvWsg/qNkQQCx/g+cFaOr3qO/wUC3WgQNS+ORgGVYuwShBtdzkoV0AoL
n+IWobfVobxHxxucnVDIJmXaA3iZR89hpC8HSqY+CiNIBfoYWlM7q7M5GFxuYNbz
gxG0eAs6M/kB3HVvUoJbqSVQ66ubrXvIUKGi6swPDQPC82lb5q/dPdH21vYB0rYY
MMwWGncUbrGPLu2P9P/MocSj8W1svSCX/zpR4pNGmJgHqf3PnlkG4Q==
=x8Nt
=====END PGP SIGNATURE=====
------------------------------
Date: Sun, 25 Mar 2001 16:26:35 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Re: Encrypt then HMAC or HMAC then Encrypt?
=====BEGIN PGP SIGNED MESSAGE=====
Bjorn Forsberg wrote:
> I am storing an encrypted data packet. Typically small (less than 1K
> FWIW). I am encrypting the data, then taking an HMAC of the encrypted
> data plus other plain text data. The HMAC is appended to the plain text
> data and cipher text data over which it operates on.
That seems perfectly reasonable. Make sure you include a format version
number in the authenticated plain text data. If the cipher is variable,
then an ID for it and any parameters should go in as well.
> I know SSL takes an HMAC of data then encrypts everything including the
> HMAC. I can't see anything really definitive that would say that one
> method is better over the other?
>
> Can someone please give me some good reasons to pick one way vs the
> other?
See:
Mihir Bellare, Chanathip Nampremprey,
"Authenticated Encryption: Relations among notions and analysis of the
generic composition paradigm,"
Preliminary version in in Advances in Cryptology - ASIACRYPT '00,
Lecture Notes in Computer Science Vol. 1976 (T. Okamoto ed.),
Springer-Verlag, 2000.
Full version (September 25, 2000) available from
http://www-cse.ucsd.edu/users/mihir/
This shows that, under the assumptions that the cipher is semantically
secure against chosen plaintext attack, and the MAC is strongly unforgeable
(see the paper for what that means), Encrypt-then-MAC can be formally
proven semantically secure against adaptive chosen ciphertext attack,
but MAC-then-Encrypt can't.
Note that this doesn't in itself constitute an attack against
MAC-then-Encrypt for typical choices of cipher and MAC; the paper is
simply about what can be proven when making only standard assumptions
about the cipher and MAC. IMHO, it's a good enough reason to choose
Encrypt-then-MAC in preference to MAC-then-Encrypt in new protocol
designs, though.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOr4bxzkCAxeYt5gVAQFTSgf9EtqyEOGh9qKmbH+71few7PrzNtChHkR0
oqNPVDMkJtRPb1iX5Pg9t3jh9C9rz7Zmr81v3WU3Wt3RB+lHxc4bOXeOK2HBRAX7
uRKM92JtyleFRa1pvPjjbwZshOsiIVzs1mVbbbae0hjCvfP7rtCJ6g24V10fHznb
z4ZWt9mgkfQ+JmYKqu7meZOm91+YrRlRUPXqOjl/H9hYtC6oV3JzAoZtxSBbgel2
DTG4oCPvx86vjin0iPgXV0jAtnK4oYaJ6xI7jyme+SZ+QEqe9VRQFMgWSR+gbEzD
AGefV1wT4lPd5J5FmuW4YKrVe9XIRvzxggatPpg4iI9x4FoUvkWQFQ==
=bbar
=====END PGP SIGNATURE=====
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: TEA, Blowfish with non-random data?
Date: Mon, 26 Mar 2001 10:49:36 -0800
Dan Hargrove <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I have a layman's question about the security of certain implementations of
> cryptography which are offered as freeware.
>
> The problem is that there is no information given for either one regarding
> how pseudo-random data is produced. This would lead one to believe that
> the implementation is less than secure.
No, it is not any such indication.
> The quality of the pseudo-random
> data produced by the software is less than assured, in my view.
<Snip>
The Unpredictable and uncorrelated (without knowledge of the key)
output is the result of the proper function of the algorythm. It isn't an
add-on process to the encryption process. A DETAILED description
of Blowfish is availiable via the counterpane.com website. How do
you know it's working properly? Test vectors can be run to assure
that the code within is probably the one advertized. How do you know
Blowfish is good? You don't. All that can be determined is that after a
fair ammount of attention, no fatal flaws have been found.
Don't confuse statistically random looking output with good encryption.
Bad stats and it's probably bad. (Note: this is not always true)
Good stats and it's not obviously bad but could be trivial to break.
Just because one effect is observed with good algorythms doesn't
mean that the presence or absense of the effect is an indicator of
good or bad.
Paul
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Crossposted-To:
alt.privacy.anon-server,alt.security.pgp,comp.security.pgp.discuss,comp.security.pgp.resources,comp.security.pgp.tech
Subject: Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged
Date: Mon, 26 Mar 2001 19:16:25 GMT
"Imad R. Faiad" <[EMAIL PROTECTED]> wrote in message
> The Klima & Rosa attack may sound good in theory,
> but in practice it is not workable.
> Here is what the attacker has to do:-
> 1) Get your private key.
> 2) Change certain public key parameters in such a way
> so that your secret key may be derived from a signed
> message.
> 3) Wait for you to sign a message.
> 4) Capture the message in 3).
> 5) Restore your private key to it's original state.
> 6) Use the signature in 4) to derive your secret key.
> 7) Build your secret key.
> 8) Sign messages on your behalf.
If the attack has access to my private machine to do all that,
wouldn't it be easier for him to patch my PGP.exe in some way
to make it insecure?
This "attack" just looks like a cheap publicity stunt to me.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Kill-filter expression for script weenie
Date: Mon, 26 Mar 2001 11:23:45 -0800
Works for me.
Now, if we could just get everybody to stop replying
and therefore jumping these obnoxious headers past
the killfile, life would be good.
Paul
filterguy <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> A filter expression that kills the Script Kiddie posts:
>
> for (Forte) Agent:
>
> subject: (love*|need*|ask*|require*|uses*|want*|used) and from:
> (anonymous|melon|frog2|remailer|steeleye|nescio)
>
>
> For Xnews (and slrn?):
>
> Score: -9999
> Expires: 4/25/2001
> Subject: (love|need|ask|require|use(s|d)|want)
> From: (anonymous|melon|frog2|remailer|steeleye|nescio)
>
>
> fg
------------------------------
From: "Ryan M. McConahy" <[EMAIL PROTECTED]>
Subject: RC4
Date: Mon, 26 Mar 2001 14:31:12 -0500
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Ok, I'm assuming RC4 is 128bit.
So, lets say I tell the user to give me a 16byte key. If they don't,
I just ignore it. I split the key in half, generating K1 and K2. I
hash these to get HK1 and HK2. I encrypt the plaintext with HK1, then
re-encrypt that with HK2. Would this be 256 bit encryption? Would it
be strong? Could I call it 2RC4?
I'm making a program to "compete" with ShyFile (www.shyfile.de). I
want to prove that I can make a better one. The only advantage theirs
has over that little RC4 program I threw together last night is that
t's 256 bit and that it can generate self-decrypting HTML pages. My
program wouldn't do that, but it could be downloaded in about five
seconds.
Oh, and if anyone has any AES code that would work in VB4, let me
know. :)
Thanks in advance,
Ryan M. McConahy
=====BEGIN PGP SIGNATURE=====
Version: 6.5.8ckt http://www.ipgpp.com/
Comment: KeyID: 0xA167F326A5BE3536
Comment: Fingerprint: 838C 815E 5147 2168 5A76 16F1 A167 F326 A5BE 3536
iQA/AwUBOr+Y/KFn8yalvjU2EQJahgCgnmiGbErKKJRN3lxl6lLVOCDUegUAniSy
CD7awgu9R8P8yQw9Ba5rFNLb
=MjSR
=====END PGP SIGNATURE=====
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: ECDSA question
Date: Mon, 26 Mar 2001 19:25:25 GMT
In Elliptic Curve DSA:
"[...] Compute s = k^-1 {SHA1(m) + dr} mod n [...]" (m is the message).
Is there any problem if I use "m" instead of "SHA1(m)" (the signature
validation works fine)?
Cristiano
------------------------------
From: [EMAIL PROTECTED] (Joe H Acker)
Subject: Re: Deny Anon Remailers access to this newsgroup
Date: Mon, 26 Mar 2001 21:29:55 +0200
Frank Gerlach <[EMAIL PROTECTED]> wrote:
> I cannot find a good reason why anon remailers should be allowed to
> post to sci.crypt. If someone needs pseudo-anonymity, just change your
> name in the news client.
Just because bath-towels can be used to suffocate someone, that doesn't
mean that the use of bath-towels should be restricted in general.
Regards,
Erich
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: New stream cipher
Date: Mon, 26 Mar 2001 11:28:32 -0800
Frank Gerlach <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> MarinaP wrote:
> >
> > Hi, all!
> > I would like to analyze a new stream cipher.
> > Where can I find it?
> > Where can I find RC4-like ciphers?
> > What stream ciphers are used in practice? -RC4, A5, PKZIP ( It is clear.)
> > Thank you.
> try google.com
>
> A5 and PKZIP are erm, not "military-strenght" :-)
Your probably not going to take this well but.....
"military-strenght" or "military-strength" are meaningless terms.
If you don't know the answer, wait for someone else to answer
instead of posting less than helpful or non-responsive replies.
Paul
------------------------------
From: "Ryan M. McConahy" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Kill-filter expression for script weenie
Date: Mon, 26 Mar 2001 14:34:19 -0500
Gary Woods wrote in message ...
>[EMAIL PROTECTED] (filterguy) wrote:
>
>>A filter expression
>
>It would be best to discuss this off-group, since the person trying to
>disrupt things clearly feeds on any talk about them.
>
>(I have one that works pretty well for agent).
>
>The flooding has spread, primarily because in alt.privacy.anon-server it's
>being ignored, with occasional thanks for the cover traffic {:-)
LOL!
>
>--
>Gary Woods O- K2AHC Public keys at www.albany.net/~gwoods, or get
0x1D64A93D via keyserver
>[EMAIL PROTECTED] [EMAIL PROTECTED]
>fingerprint = E2 6F 50 93 7B C7 F3 CA 1F 8B 3C C0 B0 28 68 0B
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Please read.
Date: Mon, 26 Mar 2001 11:33:46 -0800
In a perfect world...
If life were fair.....
Too bad.
Fact:
Someone is pooping in our pool.
There is little that can be done.
Solution:
Use a killfile. And do NOT reply or comment.
You are just pushing these headers past the killfiles
of those who are using them and giving this turd
a certain amount of satisfaction.
Paul
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Please read.
Date: Mon, 26 Mar 2001 19:43:04 GMT
On Mon, 26 Mar 2001 11:33:46 -0800, "Paul Pires" <[EMAIL PROTECTED]>
wrote, in part:
>Someone is pooping in our pool.
>There is little that can be done.
Of course there is. The anonymous remailers they are using can be
notified of the problem. They can then turn around and block the
offender, and then notify the offender's ISP.
There is nothing wrong with anonymous remailers, as long as they
behave in a responsible fashion, and do not permit themselves to be
used for any kind of abusive behavior.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: RC4
Date: Mon, 26 Mar 2001 11:52:33 -0800
Ryan M. McConahy <[EMAIL PROTECTED]> wrote in message
news:3abf98aa$0$88182$[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ok, I'm assuming RC4 is 128bit.
128 bit what?
RC4 is a stream cipher with a 2048 bit internal state.
>
> So, lets say I tell the user to give me a 16byte key. If they don't,
> I just ignore it. I split the key in half, generating K1 and K2. I
> hash these to get HK1 and HK2. I encrypt the plaintext with HK1, then
> re-encrypt that with HK2. Would this be 256 bit encryption? Would it
> be strong? Could I call it 2RC4?
Let's say we did and then don't. You have to covey this special process
to the recipient or provide it in the code. If it is kept secret, it is security
through obscurity. If it is known, it adds nothing. An attacker knowing the
process just pushes the 16 byte guesses through this front end. 16*8=128.
No, it's not the same as 256 bit encryption. The only "surprise" an attacker
has to overcome is 128 bits worth...IF ALL ELSE IS DONE WELL.
Designing the proper process to key
a cipher could be seen as a more demanding challenge than developing
a cipher. If your gonna go through all that, why not write a super-strength
home brew cipher to use with it?.... :-)
Paul
>
> I'm making a program to "compete" with ShyFile (www.shyfile.de). I
> want to prove that I can make a better one. The only advantage theirs
> has over that little RC4 program I threw together last night is that
> t's 256 bit and that it can generate self-decrypting HTML pages. My
> program wouldn't do that, but it could be downloaded in about five
> seconds.
>
> Oh, and if anyone has any AES code that would work in VB4, let me
> know. :)
>
> Thanks in advance,
>
> Ryan M. McConahy
>
> -----BEGIN PGP SIGNATURE-----
> Version: 6.5.8ckt http://www.ipgpp.com/
> Comment: KeyID: 0xA167F326A5BE3536
> Comment: Fingerprint: 838C 815E 5147 2168 5A76 16F1 A167 F326 A5BE 3536
>
> iQA/AwUBOr+Y/KFn8yalvjU2EQJahgCgnmiGbErKKJRN3lxl6lLVOCDUegUAniSy
> CD7awgu9R8P8yQw9Ba5rFNLb
> =MjSR
> -----END PGP SIGNATURE-----
>
>
>
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Please read.
Date: Mon, 26 Mar 2001 11:58:16 -0800
John Savard <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Mon, 26 Mar 2001 11:33:46 -0800, "Paul Pires" <[EMAIL PROTECTED]>
> wrote, in part:
>
> >Someone is pooping in our pool.
> >There is little that can be done.
>
> Of course there is. The anonymous remailers they are using can be
> notified of the problem. They can then turn around and block the
> offender, and then notify the offender's ISP.
A resonable thing to do.
Pardon. There is little that can be done through reasoning with this
genetic anomality or by ranting amongst ourselves.
Thanks,
Paul
>
> There is nothing wrong with anonymous remailers, as long as they
> behave in a responsible fashion, and do not permit themselves to be
> used for any kind of abusive behavior.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Ben Cantrick)
Crossposted-To: alt.security.pgp
Subject: Kill-file entries for TRN to nuke the weenie! (was Re: Kill-filter expression
for script weenie)
Date: 26 Mar 2001 13:04:34 -0700
In article <[EMAIL PROTECTED]>,
filterguy <[EMAIL PROTECTED]> wrote:
>A filter expression that kills the Script Kiddie posts:
>
>for (Forte) Agent:
>
>subject: (love*|need*|ask*|require*|uses*|want*|used) and from:
>(anonymous|melon|frog2|remailer|steeleye|nescio)
>
>
>For Xnews (and slrn?):
>
> Score: -9999
> Expires: 4/25/2001
> Subject: (love|need|ask|require|use(s|d)|want)
> From: (anonymous|melon|frog2|remailer|steeleye|nescio)
Excellent kill expressions!
In killfiles, as in crypto, the key is finding exploitable patterns.
Our ph33r-less script kiddy has been quite stupid in his choice of posting
material; all his posts contain dead giveaways. Here are some trn killfile
entries that I'm using to nuke him...
- He always has either "X-DumbAss: Arnold Boschloo" or "X-AirHead: Arnold
Boschloo" in his posts. These two killfile entires auto-kill posts with
"X-AirHead" pr "X-Dumbass" header lines:
/^X-DumbAss/h:j
/^X-AirHead/h:j
These two lines alone seem to nuke 99% of his crap, and are probably
sufficient by themselves. However, there are additional patterns we can
exploit to shut him down too...
- He seems to like to cross-post his junk to three specific newsgroups,
soc.men, alt.security.pgp and sci.crypt. I consider the chances of someone
legitimately cross-posting to all three of these newgroups vanishingly
small. Hence I kill any post that goes to all three of them:
/^Newsgroups:.*soc.men,alt.security.pgp,sci.crypt/h:j
(Note: This killfile entry is order-sensitive to the order of the
newsgroups. So if he starts randomizing the order of the groups in this
line, you'll have to type in all six permutations, like so:
/^Newsgroups:.*alt.security.pgp,soc.men,sci.crypt/h:j
/^Newsgroups:.*alt.security.pgp,sci.crypt,soc.men/h:j
/^Newsgroups:.*sci.crypt,alt.security.pgp,soc.men/h:j
/^Newsgroups:.*sci.crypt,soc.men,alt.security.pgp/h:j
/^Newsgroups:.*soc.men,alt.security.pgp,sci.crypt/h:j
/^Newsgroups:.*soc.men,sci.crypt,alt.security.pgp/h:j
It's a little annoying, but not too bad.)
- Lastly, he seems to have some kind of fanatic hard-on for Arnold
Boschloo, as mentioned above. He likes to CC his posts to Arnold and
Arnold's ISP. I consider the chances of anyone legitimately CC'ing
something to Arnold small, so I kill any posts that has a CC to Arnold's
e-mail address:
/^CC:.*[EMAIL PROTECTED]/h:j
If you use the trn newsreader, then, well, you probably don't need me
telling you how to make kilfile entries! But if you're a newbie using trn,
here's how to use these: First, start reading sci.crypt. Then, start reading
an article - any article will do. Read it through to the end so you get to
the "end of" article prompt. This is the one that says "Article #xxxxx", not
the one that says "More".
Once you get to that prompt, hit ^K to directly edit the killfile for
the newsgroup. You should be punted into an editor (maybe vi) and allowed
to enter killfile entries. Type in the above killfile entries and off you
go! Now every time you start reading sci.crypt, the newsreader will use
the above entries to auto-junk posts from our ever-so-l33t s/<ript kiddie.
-Ben
--
Ben Cantrick ([EMAIL PROTECTED]) | Yes, the AnimEigo BGC dubs still suck.
BGC Nukem: http://www.dim.com/~mackys/bgcnukem.html
The Spamdogs: http://www.dim.com/~mackys/spamdogs
"Of COURSE I'm on topic. (Which group is this again?)" -Scott Hagie
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy.anon-server,alt.security.pgp,comp.security.pgp.discuss
Subject: Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged
Date: Mon, 26 Mar 2001 21:03:55 +0100
Less not be overprotective of OpenPGP here: if Netscape of Microsoft had
such a stupid hole, we'd jump all over them.
I like your proposals and hope they are swiftly included in the standard.
--
Regards,
Sam
http://www.scramdisk.clara.net/
Imad R. Faiad <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Greetings,
>
> The Klima & Rosa attack may sound good in theory,
> but in practice it is not workable.
>
> Here is what the attacker has to do:-
>
> 1) Get your private key.
> 2) Change certain public key parameters in such a way
> so that your secret key may be derived from a signed
> message.
> 3) Wait for you to sign a message.
> 4) Capture the message in 3).
> 5) Restore your private key to it's original state.
> 6) Use the signature in 4) to derive your secret key.
> 7) Build your secret key.
> 8) Sign messages on your behalf.
>
> The authors have abstained from furnishing the PGP keys
> which they hacked, for some obvious reasons.
>
> The reason, is that, even a PGP novice will not fall
> for their scheme. To start with, that hacked key
> will look very odd, and will have all sort of attribute
> to alarm even the most naive PGP user.
>
> The problem is not a serious one, it may be remedied
> by validating the key parameters prior to using
> the secret key.
>
> Better still, if the OpenPGP format standard is ever
> revised, I propose that all the public key parameters
> be stored and protected together with the secret ones.
> This is a simple solution, and it works. Whenever
> the secret key is used, the trusted public parameters
> which were protected should be used in OpenPGP
> implementations.
>
> my 2c
>
> Best Regards
>
> Imad R. Faiad
>
>
> On Sat, 24 Mar 2001 20:10:58 +0100, in alt.security.pgp [EMAIL PROTECTED]
> (Joe H. Acker) wrote:
>
> >Frank Gerlach <[EMAIL PROTECTED]> wrote:
> >
> >
> >> > There shall be no reason to store your private key, which is properly
> >> > encrypted, in the deposit. We have shown that in the case of the
> >> > OpenPGP format the encrypted private key MUST NOT be stored in the
> >> > place, where the attacker can access and modify it. From here we
> >> > conclude that private keys are NOT PROPERLY ENCRYPTED in the OpenPGP
> >> > format and derived applications.
> >>
> >> They are not secured against TAMPERING.
> >
> >Look, Tomas Rosa has claimed that he and his colleague can obtain the
> >secret key although it is encrypted. If this claim is true, then clearly
> >OpenPGP's private key encryption is "broken" or "compromised" or however
> >you call the ability of the attacker to obtain the private key without
> >knowing the correct key for the decrypting the private key.
> >
> >> > Moreover it is also realistic. In the networked systems users usually
> >>> would
> >> > like to store their containers with private keys in some shared place
> >> >to be
> >> > able to have their keys ready to use on any workstation in the
> >> > network.
> >>
> >> Yeah, anytime. Too difficult to store some kilobytes on a floppy.
> >> >Too heavy, to
> >> bulky, those 3.5 inch floppies.
> >
> >Most PGP users do not store private keys on portable disks. The
> >encryption of the private key was supposed to be secure. If it was a
> >necessary security requirement to put the private key in a secure place,
> >then there was no need to encrypt it. But it is encrypted.
> >
> >> > Note
> >> > that this is the default option in the PGP. In such scenario it is
> >> > clear that the user has very little or no control on the encrypted
> >> > private key. Anybody who can modify this information when it is going
> >> > through the network can carry out the attack. Of course your network
> >> > administrator is the first person who can be the attacker.
> >>
> >> Your network adimistrator will most probably replace PGP itself with a
> >> trojan-horsed version, if he wants your key.
> >
> >He can't because PGP is on your PC. The attack scenario described does
> >not require direct access to your PC.
> >
> >> > We think that users shall not have to care
> >> > about such thinks (when their private keys are properly encrypted, of
> >> > course). Btw: wasn't it the main idea behind the whole PGP to give
its
> >> > users
> >> > "Pretty Good Privacy" in such environments?
> >>
> >> >
> >> > So, from the practical point of view, the attack is pretty realistic.
> >>
> >> Maybe *you* are storing your secret key on a shared drive.
> >> Security-concious people store it on a floppy disk, which the
physically
> >> control.
> >
> >I doubt that you are able to reliably destroy the key disk or even keep
> >it safe. That's as unrealistic as writing all your passphrases on a
> >piece of paper you keep in your wallet. This does only work as long as
> >someone isn't *seriously* interested in obtaining them.
> >
> >> >
> >> >
> >> > More information will be available in the crypto-paper, which will be
> >> > released soon at www.i.cz.
> >>
> >> Next time, please clearly state the THREAT MODEL. Telling people that
> >> write access to the secret key is necessary would have been easily
> >> possible.
> >
> >I had no problems understanding this. Perhaps you should read more
> >carfully next time.
> >
> >Regards,
> >
> >Erich
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
