Cryptography-Digest Digest #547, Volume #12 Sun, 27 Aug 00 06:13:00 EDT
Contents:
Re: PGP Bug: A note from Ralf Senderek (Jonathan Thornburg)
Re: What is required of "salt"? (those who know me have no need of my name)
Re: PGP Bug: A note from Ralf Senderek ("Michel Bouissou")
Re: PGP Bug: A note from Ralf Senderek ("David Sternlight")
RSA Cryptography Today FAQ (1/1) ([EMAIL PROTECTED])
Re: SHA-1 program, wrongo ! (those who know me have no need of my name)
PGP ADK Bug: What we expect from N.A.I. ("Michel Bouissou")
Re: Steganography question ("Harris Georgiou")
Re: PRNG Test Theory (Mok-Kong Shen)
Re: stegonographic overuse (David Blackman)
Re: PGP ADK Bug: What we expect from N.A.I. (John Berger)
Re: 320-bit Block Cipher (Mack)
Re: You _DONT_ want a quantum computer. (John Bailey)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP Bug: A note from Ralf Senderek
Date: 27 Aug 2000 09:21:35 +0200
In article <8o9hbi$s5t$[EMAIL PROTECTED]>,
Harald Milz <[EMAIL PROTECTED]> pointed out the irony of a poster
quoting Ralf Senderek's advice to
"Use PGP-classic in a reliably secure environment."
in a message with a pgp 6.5.8 signature block.
Another similar irony: During much of the US government's prosecution
of Phil Zimmermann, CERT (funded by the US government) included in each
CERT advisory text such as the following:
> Using encryption
>
> We strongly urge you to encrypt sensitive information sent by email.
> Our public PGP key is available from
>
> http://www.cert.org/CERT_PGP.key
--
-- Jonathan Thornburg <[EMAIL PROTECTED]>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
Seen on usenet (dueling .signature quotes):
#1: "If we're not supposed to eat animals, why are they made of meat?"
#2: "If we're not supposed to eat people, why are they made of meat?"
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: What is required of "salt"?
Date: Sun, 27 Aug 2000 07:38:57 GMT
<[EMAIL PROTECTED]> divulged:
>The advantage of using username+servername [as the salt] is
>that those values need to be entered (known) anyway.
and is exactly why they shouldn't be used.
--
okay, have a sig then
------------------------------
From: "Michel Bouissou" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP Bug: A note from Ralf Senderek
Date: Sun, 27 Aug 2000 09:43:35 +0200
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
"Harald Milz" <[EMAIL PROTECTED]> a �crit dans le message news:
8o9hbi$s5t$[EMAIL PROTECTED]
>
> > -----BEGIN PGP PUBLIC KEY BLOCK-----
> > Version: PGPfreeware 6.5.8 for non-commercial use
> > <http://www.pgp.com> Comment: Corrigez le bug PGP ADK. Installez
> > PGP 6.5.8 ou plus recent.
>
> Is it just me, or is that ironic?
Let me clarify a point:
Ralf Senderek used PGP 2.6.3ia to sign his post, as his signature
shows:
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.3ia
>Charset: noconv
I added myself his public key to the end of the post, as I clearly
state it in the post, to help readers check Ralf's signature.
I (and not Ralf) was using PGP 6.5.8 that I was evaluating, and that
is why Ralf's public key, which I extracted from my own public
keyring, shows a 6.5.8 version stamp. This comes from me, not from
Ralf.
Sorry if this has leaded some of you to wrong conclusions.
[EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
Comment: Corrigez le bug PGP ADK. Installez PGP 6.5.8 ou plus recent.
iQA/AwUBOai4l47YarFcK+6PEQKT4wCgns5+q8tnn9JZ9RrEhdj+8PWAGIYAoODh
5hslgwfGIQQ0LY+P9+dTKAhV
=cbPk
=====END PGP SIGNATURE=====
------------------------------
From: "David Sternlight" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP Bug: A note from Ralf Senderek
Date: Sun, 27 Aug 2000 07:46:26 GMT
"Harald Milz" <[EMAIL PROTECTED]> wrote in message
news:8o9hbi$s5t$[EMAIL PROTECTED]...
> In comp.security.pgp.discuss Michel Bouissou <[EMAIL PROTECTED]> wrote:
> > "Use PGP-classic in a reliably secure environment." That would be my
> > advice if I had 49 characters left on the telegram.
> > Ralf Senderek
>
> ...
>
> > -----BEGIN PGP PUBLIC KEY BLOCK-----
> > Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
> > Comment: Corrigez le bug PGP ADK. Installez PGP 6.5.8 ou plus recent.
>
> Is it just me, or is that ironic?
What's ironic is the signature below:
>
> --
> "50 million potential S/Mime users can't be wrong.... But they can all be
> stupid!"
> - Sam Simpson in comp.security.pgp.discuss
>
------------------------------
Crossposted-To:
talk.politics.crypto,alt.security.ripem,sci.answers,talk.answers,alt.answers,news.answers
Subject: RSA Cryptography Today FAQ (1/1)
from: [EMAIL PROTECTED]
reply-to: [EMAIL PROTECTED]
Date: 27 Aug 2000 08:49:17 GMT
Archive-name: cryptography-faq/rsa/part1
Last-modified: 1997/05/21
An old version of the RSA Labs' publication "Answers to Frequently Asked
Questions about Today's Cryptography" used to be posted here until May
1997. These postings were not sponsored or updated by RSA Labs, and
for some time we were unable to stop them. While we hope the information
in our FAQ is useful, the version that was being posted here was quite
outdated. The latest version of the FAQ is more complete and up-to-date.
Unfortunately, our FAQ is no longer available in ASCII due to its
mathematical content. Please visit our website at
http://www.rsa.com/rsalabs/ to view the new version of the FAQ with your
browser or download it in the Adobe Acrobat (.pdf) format.
RSA Labs FAQ Editor
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: SHA-1 program, wrongo !
Date: Sun, 27 Aug 2000 08:54:09 GMT
<[EMAIL PROTECTED]> divulged:
> <<I second other comments that you should read the file once only.>>
>
>Well, this is basically not easy. I can't get the file length any other
>way.
doesn't your environment support stat or fstat?
>I don't see how any SHA-1 program *could* have endian problems.
same as any other error.
--
okay, have a sig then
------------------------------
From: "Michel Bouissou" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: PGP ADK Bug: What we expect from N.A.I.
Date: Sun, 27 Aug 2000 11:13:49 +0200
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
The disastrous ADK bug recently discovered by Ralf Senderek in
versions 5.x and 6.x of PGP has greatly compromised the trust that
all of us crypto and privacy activists had in N.A.I. PGP.
In this message, I express not only my personal opinion, but as well
the opinion of several crypto and privacy activists, long-time PGP
supporters in France.
This bug is the most serious and threatening one ever discovered in
PGP since its beginning.
Although N.A.I. quickly reacted to this bug by scanning and fixing
their keyservers, publishing a new PGP 6.5.8 version supposed to be
immune to the bug within 48 hours after its discovery, and also
released a PGPrepair program which is supposed to clean forged public
keys from keyrings, this still is far from enough.
(We write "supposed" not because we distrust the efforts made by
N.A.I., but because we estimate that these solutions cannot have been
tested enough in this short timeframe to put full confidence into
them).
We received information from N.A.I. stating that these
countermeasures were the first steps taken in emergency, and we
acknowledge that they shown quick and reactive and there was not much
more that they could have done in such a short timeframe.
We understand from N.A.I. employees statement that more comprehensive
and definitive solutions are yet to come and are looking forward for
these solutions.
Yet, we regret that N.A.I. and / or Phil Zimmermann didn't release so
far clearer explanations about what they thought of this bug and its
cause and consequences on a technical standpoint.
The fact that this bug can allow messages to be encrypted to somebody
(attacker) different than the intended message recipients makes it
one of the most disastrous things that can happen to a public-key
cryptosystem.
This bug being related to the "ADK / ARR" feature in PGP makes the
issue still hotter, as this ADK feature has been contested and
disapproved from the beginning by the vast majority of PGP
supporters, as well as a number of crypto specialists.
In any case, this "ADK / ARR" feature is a very sensible thing, as
incoporating such features in a cryptosystem creates one possible
weakness and attack path. Ralf's discovery recently proved we were
right being worried about it.
This ADK system being so sensible, we would have expected N.A.I. to
have put the highest care in implementing, testing, securing and
documenting it. Unfortunately, Ralf's work and our own tests proved
this wasn't the case.
=> The bug exists, can easily be exploited. This has been largely
debated these last days.
=> The "warning" messages do not behave as one would expect by
reading the manuals and options explanations.
=> The whole ADK concept and implementation is not explained nor
discussed in the PGP Freeware manual, maintaining ignorance and
confusion about sensible things which should be made very clear.
All this proves that this wasn't properly done, and, quoting Ralf
Senderek last public note:
<<<<<
>This is not a bug, this is a scandal, because NAI put ADKs into PGP
>without caring about simple manipulations. Obviously there has
>never been a well thought-out security strategy and most of the
>relevant information the public got from NAI concerning ADKs was
>completely untrue as my
>experiments reveal.
>>>>>
We regret to say that we must share and approve Ralf point of view
about this.
This weakness discovered in the v4 signature mechanism rises the
issues of possible other weaknesses that might have been introduced
in PGP when PGP5 was released, because it proves that things which
should have been carefully checked and designed were not. And such a
weakness stayed unnoticed for several years.
In light of this, we must acknowledge that Ralf Senderek advice to
trust only PGP 2.6.x version makes sense.
Seing that, and seing that several small but very visible bugs have
remained in the PGG G.U.I for a very long time (such as a bug in the
display of the main PGPkeys window, bug in the display of Keyserver
search results...) we really have to worry about the overall quality
and security of the PGP products.
Consequently, we suggest that:
- - N.A.I. should put the core of PGPFreeware under GNU/GPL licence.
This would probably have no or little impact on the ability of N.A.I.
to keep producing and selling commercial PGP versions and related
security services, and would help much in restoring confidence.
- - N.A.I. should start cooperating, and not competing, with current
PGP-compatible cryptosystems developments such as GnuPG.
- - N.A.I. should urgently have the current PGP versions and key
formats reviewed by independant competent, and well-known
cryptographers, and should ask them to publish an independant audit
report about their findings.
- - N.A.I. should communicate very clearly about the ADK issue, and the
possible consequences of the existence of a non-hashed area in the v4
signature format. Although details about this signature format may be
buried somewhere in a technical RFC or the like, N.A.I. should
publicly discuss this signature format and the reason why such
non-hashed areas were put into it.
- - N.A.I. should try its best to explain how this bug can have been
introduced unnoticed in PGP, and why the implementation of the ADK
feature has not been accompanied with security controls that meet the
quality standards expected for such a life-critical software.
- - N.A.I. should take appropriate measures to really kick this problem
off. If this means having to abandon the current DH/DSS keys or
signature format and developing a new, more robust format, this
should be undertaken according to indenpendant and competent
cryptographers advice.
- - N.A.I. should stop bundling PGP with other "security" features such
as a VPN or firewall or intrusion detector that have nothing to do
with the PGP core. PGP is PGP and can maybe be accompanied by
PGPdisk. The rest has nothing to do with PGP and could be sold by
N.A.I. in different, separated software packages if they want. The
more unnecessary and bulky things are included with PGP, the bigger
PGP grows, the harder it becomes to review and control, and higher
becomes the risk that security-threatening bugs remain unnoticed.
- - N.A.I. should integrate into the next PGP releases an option to
globally desactivate ADK encryption, even if this means refusing to
encrypt anything to a recipient key which has an attached ADK.
- - And we wish that N.A.I. should release a freeware PGP version which
is completely ADK-free.
Should N.A.I. choose to follow some of these advices, this would
greatly help in restoring confidence that has much suffered from this
regrettable event.
Should N.A.I. choose to ignore these comments, this would surely lead
many people to distrust the PGP software and move on to new systems
such as GnuPG, which many of us are already seriously considering.
[EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
Comment: Corrigez le bug PGP ADK. Installez PGP 6.5.8 ou plus recent.
iQA/AwUBOajNvY7YarFcK+6PEQIsfgCeItaFxuENITYwHyarFt6h3oX4dwwAn305
MezqixhI0VhEObdogHcJU3rO
=Jkhe
=====END PGP SIGNATURE=====
------------------------------
From: "Harris Georgiou" <[EMAIL PROTECTED]>
Subject: Re: Steganography question
Date: Sun, 27 Aug 2000 12:10:41 +0300
zapzing <[EMAIL PROTECTED]> wrote in message
news:8o6jdv$ehq$[EMAIL PROTECTED]...
> First of all I would like to say, personally, that
> I think it would be very very silly to rely on
> steganography alone to hide a message. It
> should always be encrypted first. Always.
>
Of course it is. Still, my question is even if someone knew the existence of
the message (encrypted or not), how could he devise a generic method of
retrieving it from the data block in a way that does not depend on details
of the steganographic algorithm? The issue here is not the message secrecy
but the strength of any given steganographic method and the difficulty of
cracking it.
> And, if your message is encrypted it will be
> indistinguishable from random numbers. So
> hiding random numbers in random numbers should
> not be all that difficult.
>
> An interesting case is when the random numbers you
> are trying to hide your message in have some
> other distribution, such as Gaussian for example.
> ..........
This is correct, it can be done theoretically if random data volume is much
much larger than the real data, but there are various problem in practice.
Since the random vs usable data ratio cannot be very large in real
applications, only little can be done in "fusing" real and random data into
one unified distribution. I 've tried implementing a variant of this: rather
than fusing the two distributions together, I "hide" the real data of
Gaussian distribution in another Gaussian of larger volume (mean, variance)
so that the statistical attributes of it overwrite the ones of the usable
data. Still, I have not found a solid theory in analyzing steganographic
data even for trivial cases such as this.
---
Harris
- 'Malo e lelei ki he pongipongi!'
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: PRNG Test Theory
Date: Sun, 27 Aug 2000 11:39:40 +0200
[EMAIL PROTECTED] wrote:
>
> There is no real problem. All you do is this
>
> 1. Start off with a state of 'n' bits.
> 2. Append a '1' to the state, Perform all 'x' tests on the bits.
> Record the results and remove the bit.
> 3. Append a '0' to the state, perform all 'x' tests on the bits.
> Record the result and remove the bit.
>
> Now if '1' behaves *closer* to what is random as determined by the
> tests, then output a 1 and append it to the state, etc.
>
> There is no reason why this PRNG would fail to output bits that are
> seemingly random as required by your battery of tests. The entropy of
> the output is determined solely by the entropy of the state.
>
> Perhaps this PRNG could be degenerative, slow, cumbersome, but it's a
> neat idea.
Paul Pires has already given a number of points showing
why the way isn't the one leading to goal. I like only
to repeat my suggestion that you try with a couple of
tests (the simplest seem to be the frequency test and
the lag-1 serial test), i.e. code your scheme with
these according to your idea and see what actually
comes out of that. That eliminates much unnecessary
discussions. Building a good PRNG has been persued by
lots of statisticians who are very familiar with all
kinds of tests and yet none has done anything near
to what you proposed in any degree, as far as I am
aware. Of course, it can certainly never be excluded
that a genious man discovers something they have never
hithertofore dreamed of. Anyway, Knuth, for one, who
devotes much space of his book to PRNG in both
practical and theoretical aspects, would have been
ashamed to find that such a straightforward and simple
way of obtaining an almost perfect PRNG has never
occured to his mind.
M. K. Shen
========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: David Blackman <[EMAIL PROTECTED]>
Subject: Re: stegonographic overuse
Date: Sun, 27 Aug 2000 20:31:35 +1100
Detonate wrote:
>
> embedding an encrypted message into a gif file is fine and all, but if
> somebody was eavesdropping on my email and i was repeatedly sending gifs,
> they'd realise soon enough that there are messages being stored in the
> gif's... embedding the message in various different formats probably won't
> help too much more either. im very new to all this, but would it be true
> that, like fatty foods, steganography is best used in moderation? :-) ...
> anyone want to throw their 2c at me?
Steganography probably works better if you overuse it. It would work
even better than that if you can persuade everyone else to overuse it as
well.
If you decide your prefered way to send secret messages is by
steganography in image files, send image files even when you don't have
a secret message to send. Make up a meaningless message, encrypt it with
a very secure method, then hide it in an image and send it to a friend.
That way, when you do have a secret message to send, it looks exactly
like normal. You send a image with apparently random noise embedded in
it, just like you do every day.
BTW, PNG is just as good as GIF for steganography, and has both legal
and technical advantages as an image format. Switch to it now if
possible.
JPEG is also nice for some types of images (and JPEG-2000 will be even
nicer). It's a bit harder to use for steganography, but still possible.
------------------------------
From: John Berger <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP ADK Bug: What we expect from N.A.I.
Date: Sun, 27 Aug 2000 04:34:32 -0500
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
In article <8oam4g$om$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1The disastrous ADK bug
> recently discovered by Ralf Senderek inversions 5.x and 6.x of PGP
> has greatly compromised the trust thatall of us crypto and privacy
> activists had in N.A.I. PGP.In this message, I express not only my
> personal opinion, but as wellthe opinion of several crypto and
> privacy activists, long-time PGPsupporters in France.This bug is
> the most serious and threatening one ever discovered inPGP since
> its beginning.
- ----------------------------------------------------
They 'did' write up something on the CERT webpage, and said that they
found nothing abused by this bug. It is simple to see 'now', because
it's been explained to us and those with more understanding about
this stuff see it as more <cough> disastrous, than say, someone like
me.
Since they say that it hasn't been exploited on any of the 1.3
million or so keys on the server, then a 'disaster' hasn't really
occurred, but maybe more like 'averted' before a dishonest person of
Ralf's knowledge found out what he did and used it for the wrong
thing.
We should be tickled that it showed up, (someone elses earlier post
mentioned a similar line to this), and *can* be fixed...now. Hey,
it's encryption, it's probably the hardest thing to perfect next to
quantum physics (or is that used in ecryption? <flail>).
Anyway, since I really don't carry the concern of some or the worry
they seem to have, my real worry is just getting help in figuring out
how to do command line stuff LOL. I'm DOS incompetant, and I'd like
to just get this 'repair' done, though I 'know' I don't have any keys
to fret about.
Anyway, I don't mean all this as a flame or nothing, I just wanted to
say my fill, and possibly get a little 'hand-holding walk through'
for this command line repair <g>.
Y'all be good and take care,
Johnny B
- --
- ----------------------------------------------------
If that don't fix it, get a bigger hammer
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
iQA/AwUBOajgoTdAp5vWTRQgEQK4DACfUerxdSOJjOXfw1xmE//xfM7Z3J8An2/P
twZW4bVSbtaDWQY9OLbS7IOI
=6pyQ
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: 320-bit Block Cipher
Date: 27 Aug 2000 10:03:54 GMT
>In article <[EMAIL PROTECTED]>,
>Mack <[EMAIL PROTECTED]> wrote:
><>For fun I made a 320-bit block cipher that uses SHA as the round
><>function. I did the inputs to SHA as the first 160 bits as one half of
><>the block and 352 bits of key material so it's really
><>
><>L = L xor SHA(R||K1)
><>R = R xor SHA(L||K2)
><>L = L xor SHA(R||K3)
><>
><>It runs at about 2.2mbyte/sec on my K6-2 (with the ref source code) and
><>only requires 132 bytes of ram. It's sorta like what they talked about
><>in the BEAR/LION paper except no stream cipher is involved.
><>
><>http://www.geocities.com/tomstdenis/tc7.c
><>
><>Tom
><>
><>
><>Sent via Deja.com http://www.deja.com/
><>Before you buy.
><>
><>
><>
><
><The key setup is a bit awkward. A better method is
><L2= L1 xor SHA(R1||K1||C1)
><R2=R1 xor SHA(L2||K1||C2)
><L3=L2 xor SHA(R2||K1||C3)
><
><where C1,C2, and C3 are constants. maybe strings of
><digits from PI.
><
><It is the basic Luby-Rackoff design.
><
><This is reinventing the wheel but it is a sound design.
>
>See also ShaZam (FSE'99, Sundaram and Patel IIRC).
Shazam is a four xor variant with 2 different hash functions
L2=L1 xor SQH(R1,K1)
R2=R1 xor SHA(C1,L2,K2)
L3=L2 xor SHA(C2,R2,K2)
R3=R2 xor SQH(L3,K3)
IIRC that is.
>
>Greg.
>--
>Greg Rose INTERNET: [EMAIL PROTECTED]
>QUALCOMM Australia VOICE: +61-2-9181 4851 FAX: +61-2-9181 5470
>Suite 410, Birkenhead Point http://people.qualcomm.com/ggr/
>Drummoyne NSW 2047 B5 DF 66 95 89 68 1F C8 EF 29 FA 27 F2 2A 94 8F
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: You _DONT_ want a quantum computer.
Date: Sun, 27 Aug 2000 10:05:22 GMT
On Sat, 26 Aug 2000 18:42:17 +0800, "Detonate" <[EMAIL PROTECTED]>
wrote:
>_NONE_ of your games will work. (!)
What, and spoil all the fun. Quantum logic really REALLY changes the
rules of game theory
QUANTUM STRATEGIES David A. Meyer
We consider game theory from the perspective of quantum algorithms.
Strategies in classical game theory are either pure (deterministic) or
mixed (probabilistic). We introduce these basic ideas in the context
of a simple example, closely related to the traditional MATCHING
PENNIES game. http://xxx.lanl.gov/abs/quant-ph/9804010
or
Quantum Games and Quantum Strategies
Jens Eisert, Martin Wilkens, and Maciej Lewenstein
We investigate the quantization of non-zero sum games. For the
particular case of the Prisoners'Dilemma we show that this game ceases
to pose a dilemma if quantum strategies are allowed for. We also
construct a particular quantum strategy which always gives reward if
played against any classical strategy.
http://xxx.lanl.gov/abs/quant-ph/9806088
and more: http://xxx.lanl.gov/abs/quant-ph/0004076
Besides, I expect a quantum computer will just be architecturally an
extended arithmetic unit a la array processors, possibly with a very
very heavy duty refrigerator atttached.
John
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
