Cryptography-Digest Digest #544, Volume #12 Sat, 26 Aug 00 18:13:00 EDT
Contents:
Re: Best way! (Guy Macon)
could someone post public key that is tempered & pgp will not detect it (jungle)
Re: Steganography question (Jani Store)
ZixMail? ("Big Boy Barry")
Re: PRNG Test Theory ([EMAIL PROTECTED])
Re: PGP bug ([EMAIL PROTECTED])
Re: ZixMail? ("Big Boy Barry")
Re: Steganography question (Guy Macon)
Re: PRNG Test Theory ("Paul Pires")
Re: ZixMail? ([EMAIL PROTECTED])
Re: ZixMail? (Jim Gillogly)
Re: New algorithm for the cipher contest ("Alexis Machado")
Re: 7 mil, how this usage of PGP has been calculated ? (those who know me have no
need of my name)
Re: Best way! (those who know me have no need of my name)
R: Test on pseudorandom number generator. ("Cristiano")
R: Test on pseudorandom number generator. ("Cristiano")
Re: New algorithm for the cipher contest ("Scott Fluhrer")
R: Test on pseudorandom number generator. ("Cristiano")
Re: 320-bit Block Cipher (Gregory G Rose)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Best way!
Date: 26 Aug 2000 19:07:25 GMT
Big Boy Barry wrote:
>
>I am a newbie to encryption. Am I right about PGP being insecure?
>
First, let me give you the 100% accurate answer, then the useful
answer.
The 100% accurate answer:
NOTHING is secure. Everything is either in the "known to be
insecure" or "not known whether it is or isn't secure" class.
Now the useful answer:
Who are you wanting to send secure email to? If you can manage
to give them a secret passphrase without anyone else seeing it,
then there is no known flaw in PGP. If you want to use any system
where you don't physically hand the secret passphrase over, you
are only as safe as the method you used to send it is. If you
choose to use a public key system with no secret passphrase handed
directly to your recipient, yuo will have to either study more and
really understand the issues involved, or wait a while while the
experts in sci.crypt hash it out, then ask for advice on what to
do and follow that advice.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: could someone post public key that is tempered & pgp will not detect it
Date: Sat, 26 Aug 2000 15:16:37 -0400
could someone post public key that is tempered & pgp will not detect it ?
------------------------------
From: Jani Store <[EMAIL PROTECTED]>
Subject: Re: Steganography question
Date: Sat, 26 Aug 2000 22:10:10 +0300
Guy Macon wrote:
>
> zapzing wrote:
>
> >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.
>
> There is no requirement that encrypted messages
> look like random numbers. It's a common practice,
> but often not done (especially in the header part).
Ok I'd like to post a follow-up on this. Is there a way to prove that
encryption is used (in england for instance) if I rip the PGP headers
and footers off? Let's assume that the receivers public key is available.
--
SS
------------------------------
From: "Big Boy Barry" <[EMAIL PROTECTED]>
Subject: ZixMail?
Date: Sat, 26 Aug 2000 19:29:34 GMT
Is Zixmail safe? Thanks...
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PRNG Test Theory
Date: Sat, 26 Aug 2000 19:23:01 GMT
In article <6rUp5.6797$[EMAIL PROTECTED]>,
"Paul Pires" <[EMAIL PROTECTED]> wrote:
>
> Tim Tyler <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> > [EMAIL PROTECTED] wrote:
> >
> > : Since any PRNG test can tell when a stream of bits is empiracly
random
> > : [...]
> >
> > Hmm. Personally, I'd have phrased it as: "no PRNG test alone is
likely to
> > tell you when a stream of bits is empirically random".
> >
> > If you use every test known to man - and they are all passed - that
might
> > qualify the resulting stream as "empirically random".
> >
> > : that should suggest that any PRNG test can be turned into a PRNG
itself.
> >
> > As you mention you might expect - since PRNG tests aren't designed
for
> > this job - unless you included a whole battery of such tests, the
results
> > would pass that particular test used well, and fail other ones
miserably.
> >
> > I expect using a whole battery of tests would probably result in an
> > extremely slow and cumbersome PRNG.
>
> Yes but there is an interesting question here. Can rejecting Non-
random
> (determined by any means) ever result in random? My Knee jerk
reaction is no
> but I never thought of it that way before.
Which is why I posed it.
Let's build a prng with the runs test, poker test, ones/zero test,
DNA/OPSO test, birthday test, that given 'n' prior bits will output the
better of the two bits. Technically the output must pass all the tests
better then any other output.
For simplicity I would limit this to a single bit output. One question
is how big of a memory is sufficient? 100 bits? 500 bits? 1,000,000
bits? Obviously you can't buffer an infinite number of previous bits,
but some tests can be done cummulatively such that the previous values
are not needed only the results (runs test, one/zero test for example).
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PGP bug
Date: Sat, 26 Aug 2000 19:25:09 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> A bug has been found in PGP that allows hackers to read
> encrypted messages, the BBC reports.
>
> Check out
> http://news.bbc.co.uk/hi/english/sci/tech/newsid_896000/896032.stm
>
> Bob Margolis
> rttyman at wwa dot com
And if you actually read this forum you would realize that this has
been discussed indepth already.
Here is a suggestion, you like your new found "send" button, how about
*reading* some posts first?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Big Boy Barry" <[EMAIL PROTECTED]>
Subject: Re: ZixMail?
Date: Sat, 26 Aug 2000 20:01:14 GMT
ZixIt encryption technology uses 1024-bit Public Keys.
ZixMail message encryption uses Triple-DES with three independent keys.
"Big Boy Barry" <[EMAIL PROTECTED]> wrote in message
news:yUUp5.192188$[EMAIL PROTECTED]...
> Is Zixmail safe? Thanks...
>
>
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Steganography question
Date: 26 Aug 2000 20:09:15 GMT
Jani Store wrote:
>
>Guy Macon wrote:
>>
>> zapzing wrote:
>>
>> >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.
>>
>> There is no requirement that encrypted messages
>> look like random numbers. It's a common practice,
>> but often not done (especially in the header part).
>
>Ok I'd like to post a follow-up on this. Is there a way to prove that
>encryption is used (in england for instance) if I rip the PGP headers
>and footers off? Let's assume that the receivers public key is available.
I believe that it is always, in theory, possible through
cryptanalysis to tell encrypted data from random data, with
the usual exception of One Time Pad encryption, which can
not be decoded or identified even by an opponent with infinite
cleverness and resources.
>From a practical standpoint, this may by very hard to do.
I have studied ARCFOUR and it's implementation found at
http://www.ciphersaber.gurus.com and it looks like you need
examine gigabytes of encrypted messages to identity them as
the product of ARCFOUR encryption. I am curious about how
PGP is in this respect.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: PRNG Test Theory
Date: Sat, 26 Aug 2000 13:15:28 -0700
<[EMAIL PROTECTED]> wrote in message
news:8o95ea$6h3$[EMAIL PROTECTED]...
> In article
<6rUp5.6797$[EMAIL PROTECTED]>,
> "Paul Pires" <[EMAIL PROTECTED]> wrote:
> >
> > Tim Tyler <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > > [EMAIL PROTECTED] wrote:
> > >
> > > : Since any PRNG test can tell when a stream of bits
is empiracly
> random
> > > : [...]
> > >
> > > Hmm. Personally, I'd have phrased it as: "no PRNG
test alone is
> likely to
> > > tell you when a stream of bits is empirically random".
> > >
> > > If you use every test known to man - and they are all
passed - that
> might
> > > qualify the resulting stream as "empirically random".
> > >
> > > : that should suggest that any PRNG test can be turned
into a PRNG
> itself.
> > >
> > > As you mention you might expect - since PRNG tests
aren't designed
> for
> > > this job - unless you included a whole battery of such
tests, the
> results
> > > would pass that particular test used well, and fail
other ones
> miserably.
> > >
> > > I expect using a whole battery of tests would probably
result in an
> > > extremely slow and cumbersome PRNG.
> >
> > Yes but there is an interesting question here. Can
rejecting Non-
> random
> > (determined by any means) ever result in random? My Knee
jerk
> reaction is no
> > but I never thought of it that way before.
>
> Which is why I posed it.
>
> Let's build a prng with the runs test, poker test,
ones/zero test,
> DNA/OPSO test, birthday test, that given 'n' prior bits
will output the
> better of the two bits. Technically the output must pass
all the tests
> better then any other output.
Let's make it easy. Let's say that you posess a random
evaluation oracle. "REO" (just made it up). It perfectly
evaluates the provisional output for randomness. If it's
choice conforms to randomness, then there is a chance, at
each step that 1' test better, 0's test better, 1 & 0 are
both "good" and 1 & 0 are both putrid. The second or third
condition halts your process since a choice cannot be made.
So you use a coin flip to pick.
Question: Why didn't you just use the coin flip in the first
place?
My second problem is that any random source when viewed at a
certain granularity will occasionally pop out some results
that look ordered. This is natural. If you feed your gizmo
truely random input and you remove these pieces, aren't you
making the output less random?
And last, A certificational weakness. If you feed this gizmo
it's own output, along with the the choice not taken at each
step, it will never choose the choice not taken. Pretty
identifiable. You could put in a coin flip every once and
awhile to fix it.
Question: Why didn't you just use the coin flip in the first
place?
Just seems to me that it's like trying to make something
less determinant by adding determination. A feedback loop.
In nature, these are generally very cyclic and ordered.
Paul
"Just my opinion, I could be wrong" -<Dennis Miller>
>
> For simplicity I would limit this to a single bit output.
One question
> is how big of a memory is sufficient? 100 bits? 500 bits?
1,000,000
> bits? Obviously you can't buffer an infinite number of
previous bits,
> but some tests can be done cummulatively such that the
previous values
> are not needed only the results (runs test, one/zero test
for example).
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ZixMail?
Date: Sat, 26 Aug 2000 20:09:01 GMT
In article <yUUp5.192188$[EMAIL PROTECTED]>,
"Big Boy Barry" <[EMAIL PROTECTED]> wrote:
> Is Zixmail safe? Thanks...
Sure it is. And since you haven't said "safe against what" my answer
is technically valid.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: ZixMail?
Date: Sat, 26 Aug 2000 20:28:19 +0000
Big Boy Barry wrote:
>
> ZixIt encryption technology uses 1024-bit Public Keys.
>
> ZixMail message encryption uses Triple-DES with three independent keys.
>
> "Big Boy Barry" <[EMAIL PROTECTED]> wrote in message
> news:yUUp5.192188$[EMAIL PROTECTED]...
> > Is Zixmail safe? Thanks...
A review by "Steve" a little while ago in alt.security.pgp raises some
serious red flags. I'll summarize, but check DejaNews to see his review:
http://x68.deja.com/getdoc.xp?AN=660422857&CONTEXT=967321068.2125266960&hitnum=5
Some of Steve's points (I haven't verified them, but he gives a
pointer to ZixIt's docs):
- The public key algorithm is not specified.
- The source code is not available, so no auditing is possible.
- The EULA specifies no reverse engineering, so no checking is possible.
*** ZixMail "phones home" with every encryption, so that even if it's not
spying on you, it's enabling perfect traffic analysis capability.
- The 3DES implementation can't be checked with test vectors, so
there's no way of verifying that it's really in there with full
56*3-bit keys.
- It has no local encryption capability: you can't even mail yourself
an encrypted file from your HD without "phoning home" to Zixit.
Not to my taste, thanks -- vanilla low-feature PGP or other OpenPGP clone
works for me. Not that I have any secrets worth encrypting. ~8^)
--
Jim Gillogly
4 Halimath S.R. 2000, 20:20
12.19.7.8.18, 13 Edznab 1 Mol, Seventh Lord of Night
------------------------------
From: "Alexis Machado" <[EMAIL PROTECTED]>
Subject: Re: New algorithm for the cipher contest
Date: Sat, 26 Aug 2000 17:49:11 -0300
Hi Scott. Thanks for your interest.
I have a doubt in the following point of your analysis:
>
> The first test is as follows: encrypt pairs of plaintexts. Each pair has
an
> xor differential in bit 0, and has common random data in the other bits
(and
> the randomness assumption is importent). Following through the pair
through
> the cipher, we see that, after the first round, that pair now has an xor
> differential in bit 63 and random data in the other bits.
>
I understood here that the differential of bit 63 of the left multiplicand
(L) is transported from the first to the second round.
But the resulting bit 63 will depend not only on the right multiplicand
(K[0]) but also on the preceding bits (0..62) of L. So I don't think this
differencial will be carried to the 2nd round.
Particularly, since K[0] is odd, the bit 0 of L will be transported (the
differential too) to the 2nd round. But then this bit (xored with K[5]) will
be mirrored to the last bit and the effect described in the preceding
paragraph repeats in the 2nd round.
I'm missing something ?
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: 7 mil, how this usage of PGP has been calculated ?
Date: Sat, 26 Aug 2000 21:30:58 GMT
<[EMAIL PROTECTED]> divulged:
>PGP is used by 7 million people worldwide, according to Wallach ...
>how this usage of PGP has been calculated ?
perhaps you should be asking wallach.
my guess is due to download counters, or just plain "marketing statistics."
--
okay, have a sig then
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: Best way!
Date: Sat, 26 Aug 2000 21:37:29 GMT
<7zEp5.19300$[EMAIL PROTECTED]> divulged:
>What is the best way to send encrypted email. Encrypted email that
>cannot be cracked by any means.
not possible.
--
okay, have a sig then
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: R: Test on pseudorandom number generator.
Date: Sat, 26 Aug 2000 23:39:45 +0200
Sorry for HTML!
These are the results in plain text (html was more beautiful! :-) ):
test n. Mother CryptGenRandom URAND random
1 92 109
19 161
2 99 94
18 140
3 110 91
29 159
4 96 97
22 154
5 104 89
24 172
6 71 105
19 170
7 93 107
27 166
8 78 92
24 152
9 83 83
24 139
10 94 82
20 165
mean 92,00 94,90 22,60
157,80
standard dev. 11,81 9,54 3,66
11,55
std. dev./mean % 12,84 10,05 16,18
7,32
>So the expected number of matches is approximately 10^8*10^6*2^-40, which
is about 91.
OK. But if URAND pass all statistical test I think is better, for
cryptographics applications, to have few duplicated keys!
>The expected variance is roughly the square root of that (rule of thumb for
rare [Poisson] events): 9.5.
I don't know this rule, but if 9.5 is the expected variance, then URAND is
the better because the variance is the square of the standard deviation, so
3.66^2=13.3956 is the best!
Thank you for your answer.
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: R: Test on pseudorandom number generator.
Date: Sat, 26 Aug 2000 23:38:52 +0200
> Is it right that each call of the generators gives you a 5*8=40 bit
integer?
No. Each call of the generators gives 1 byte (unsigned char), so I need to
collect 5 bytes before continue with the test.
For example, URAND (see the description below the table in my first mail)
generate an unsigned 32 bit integer, so
I need to right shift 24 times this integer to get the most significant byte
(an unsigned char of 8 bits).
CryptGenRandom (Windows 95/98 CryptoAPI) generate 5 bytes each call.
>What are the moduli of the generators?
I don't understand your question. All generators are linear congruential
generators. With the best of these generators I will seed a Blum-Blum-Shub
pseudorandom number generator (cryptographically secure). In this generator
the modulo will be at least 1024 bits (for modulo I mean "n" of x=x*x % n).
My prog do the following:
1) generate and store 1,000,000 sequences of 5 bytes each, like this:
12 32 fa 43 ea (sequence #0)
09 32 19 00 bd (sequence #1)
.....
00 fa de 87 ab (sequence # 999,999)
2) sort the 5 bytes sequences;
00 fa de 87 ab (sequence # 999,999 now is #0)
09 32 19 00 bd (sequence #1 now is #1)
12 32 fa 43 ea (sequence #0 now is #2)
.....
(This is done only to speed up the next step)
3) generate 100,000,000 sequences of 5 bytes each and verify if this
sequence is present in the 1,000,000 sequences at step 2), so if at this
step is
generated a sequence 09 32 19 00 bd, the counter of duplicated sequences
will be increased by one (sequence 09 bd 32 19 00 is *not* a duplicated
sequence).
We can say that the 8 bits integers are concatenated to form 40 bits
integer (but this is not important in my prog).
Now my question is: why statistical tests did not detect this big
difference in these generators?
Tank you for your ansewer.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: New algorithm for the cipher contest
Date: Sat, 26 Aug 2000 14:27:50 -0700
Alexis Machado <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi Scott. Thanks for your interest.
>
> I have a doubt in the following point of your analysis:
> >
> > The first test is as follows: encrypt pairs of plaintexts. Each pair
has
> an
> > xor differential in bit 0, and has common random data in the other bits
> (and
> > the randomness assumption is importent). Following through the pair
> through
> > the cipher, we see that, after the first round, that pair now has an xor
> > differential in bit 63 and random data in the other bits.
> >
> I understood here that the differential of bit 63 of the left multiplicand
> (L) is transported from the first to the second round.
>
> But the resulting bit 63 will depend not only on the right multiplicand
> (K[0]) but also on the preceding bits (0..62) of L. So I don't think this
> differencial will be carried to the 2nd round.
Actually, I claim it does work, if you look at it immediately before/after
the multiply as an additive differential. Immediately before, we have an
xor differential in the 0th bit only. This implies that we can look at it
as an additive differential of 1 (that is, one is Y and the other is Y+1 for
some Y), and I choose to do so. Then, immediately after the multiply, it
will be an additive differential of K[2], that is, one is X and the other is
X+K[2] (mod 2^64), for some X (whose exact value does, as you claim, depend
on the preceding bits of L). Now, I claim that X is effectively random,
because I specified that the 63 input bits not involved in the differential
be random. Hence the probability that X and X+K[2] differ in the 63rd bit
(yes, now we're switching to a truncated xor differential) can be computed
from K[2] -- if K[2] is small, then X and X+K[2] will be "close", and likely
to have the same 63rd bit. This probability is approximately 0.5 iff K[2]
is approximately 2^62 or 2^62 + 2^63. There will be differentials in other
bits, but at this point, we don't care. In addition, the presence of a
partial differential in bit 63 after the second round always gives rise to
the precence of a partial differential in bit 0 after the third round.
Therefore, assuming that K[2] is not too close to 2^62 or 2^62+2^63, then a
1 bit plaintext differential in bit 0 will cause bit 0 after 3 rounds to
have a differential either significantly more often or significantly less
often than expected. Either case gives us a distinguisher.
And, if K[2] is approximately 2^62 or 2^62 + 2^63, then my other
distinguisher works...
>
> Particularly, since K[0] is odd, the bit 0 of L will be transported (the
> differential too) to the 2nd round. But then this bit (xored with K[5])
will
> be mirrored to the last bit and the effect described in the preceding
> paragraph repeats in the 2nd round.
>
> I'm missing something ?
>
>
>
>
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: R: Test on pseudorandom number generator.
Date: Sat, 26 Aug 2000 23:40:54 +0200
With my english I don't understand very well your answer.
Diehard is only a (complicated) test, but others test such as Maurer
(capable to detect very little defect in the numbers generators) don't
detect these bigs differences.
My 40 bits samples (if you want, you can see my reply to Mok-Kong Shen) is
because I wrote my prog about 1 year ago and my only matter was: if with my
cryptography program I generate a key of n bytes, what is the probability
that another user generate the same key?
Theoretically the answer of Douglas (for n=5, p=91/10^14) is right, but in
practice?
I choose n=5 only for practical reasons (n=6 generate only few collisions to
compare the several generators, n=4 is not very significative as key
length).
>Wouldn't XORing one of your data sets with the reference set make a result
set with a scarceity of consecutive 0 values?
If with "reference set" you mean the keys generated at the step 1, how can I
do this? The data set is 4*10^9 bits while the reference set is only 1/100
of this. Why do you want to try this XORing?
Thank you very much for interest.
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: 320-bit Block Cipher
Date: 26 Aug 2000 15:03:43 -0700
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).
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
------------------------------
** 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
******************************
