Cryptography-Digest Digest #924, Volume #9 Thu, 22 Jul 99 09:13:05 EDT
Contents:
Re: randomness of powerball, was something about one time pads (John Myre)
Re: Compression for encryption (Mok-Kong Shen)
Re: another news article on Kryptos (Mok-Kong Shen)
Re: RSA public key (Thomas Pornin)
CSS/DVD Scrambler ([EMAIL PROTECTED])
Q: Interaction of cross-posted follow-ups? (Mok-Kong Shen)
Re: Q: Interaction of cross-posted follow-ups? (Thomas Pornin)
Re: Open questions about Dave Scotts Method ([EMAIL PROTECTED])
Kryptos Beginning of publicatio of solution ("collomb")
Re: Compression for encryption ([EMAIL PROTECTED])
Re: Compression for encryption ([EMAIL PROTECTED])
Re: hush mail (Raja BrewHaHa)
Re: Compression for encryption ([EMAIL PROTECTED])
Re: Traffic flow confidentiality ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: randomness of powerball, was something about one time pads
Date: Tue, 20 Jul 1999 15:56:07 -0600
Patrick Juola wrote:
> In article <[EMAIL PROTECTED]>,
> Alan Braggins <[EMAIL PROTECTED]> wrote:
<snip>
> >I'm still not sure about the case where he doesn't always open a door,
> >and sometimes opens a door when it will help you, but is more likely
> >to open a door if you have already chosen the prize.
>
> Surely that's a mixed case and depends on the exact percentages.
> Where *did* I put my game theory text? 8-)
>
> -kitten
OK, I'll bite: what is the optimal *host* strategy?
To make things simpler, assume that all we want to do minimize the
number of times the contestant chooses the "correct" door, rather
than minimizing the actual cost of the prizes given away (which
certainly seems like a harder problem). The host decides whether
or not to open a door based on which door the contestant chooses
(first), and his (the host's) knowledge of which is the winning
door. Of course, he can choose randomly - maybe he gets his
instructions from somebody behind the curtain who can roll dice
as necessary.
I think we might as well also restrict the host so that he
cannot open the winning door - thus removing it from choice.
All I learned about game theory was from an article or two in
Scientific American - and that was a long time ago.
John M.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Compression for encryption
Date: Thu, 22 Jul 1999 11:27:25 +0200
John Savard wrote:
>
> And it does make sense to optimize a compression method for
> cryptographic purposes: i.e. to ensure that it leaves behind very
> little redundancy, even if that takes computer time not justified by
> bandwith savings alone; to ensure that the redundancy left behind is
> in a form less likely to be useful to a cryptanalyst; to integrate
> compression capabilities into an encryption program so that headers
> indicating compression are not present - all these things are
> sensible, not irresponsible.
Further, since compression consumes processing time, it could have
some substantial impact on the total time required by the analyst
to decrypt (a security benefit resulting from 'inefficiency').
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: another news article on Kryptos
Date: Thu, 22 Jul 1999 11:12:09 +0200
Doug Gwyn (ISTD/CNS) wrote:
>
> Certainly, the more complex you make the encryption system,
> *usually* more work (and input data) is needed to crack it.
>
> But "switching algorithms" under control of a key is itself
> a fixed algorithm, just more complex than its components.
Besides switching algorithms and employing parametrized algorithms
mentioned previously, I use to think that there is substantial
potential of variability obtainable when one uses superencipherment.
For chaining n algorithms can be done in n factorail different
ways. Even for n as low as 3 the impact on the analyst could be
huge. (It is assumed, of course, that the chaining of the specific
algorithms concerned does not introduce weakness.)
BTW, in a recent thread one learned that in the realm of classical
methods double transpositions result in an effective key length which
is the LCM of the key lengths of the components. Could it be that the
yet unsolved part of Kryptos is superenciphered?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: RSA public key
Date: 22 Jul 1999 10:08:07 GMT
According to vincent <[EMAIL PROTECTED]>:
> If I always take the same very small exponent for the public key [...]
> do I limit the number of private key which will result from this
> computation ?
Obviously, yes, but that is not a problem, since you will still get a
valid private key for each pair of primes (p, q). For 1024-bit public
keys, this still means about 2^1006 possible keys, which is *huge*.
> Is it weak to do so, because obviously it would make the encryption
> faster (as well as the key generation) ?
If you encrypt three times a message with three different public modulus
but with the public exponent 3, an eavesdropper might guess the message
(not the public key) from the three encryption.
PGP (in RSA mode) uses 65537. 65537 is prime, relatively short and
uses only two '1' in its binary representation, therefore it yields
fast encryption. It is quite improbable that you send the same message
to 65537 different recipients, each time encrypted with the recipient
public key (and exponent 65537), and that in the same time you consider
this message as secret.
--Thomas Pornin
------------------------------
From: [EMAIL PROTECTED]
Subject: CSS/DVD Scrambler
Date: Thu, 22 Jul 1999 10:03:17 GMT
Is the CSS/DVD-style crypt algorithm available anywhere, or information
about it? I know to read keys of the disk but that alone is rather
useless.
Or is it another of those things that can't be exported etc etc?
Cheers for any reply,
Lund
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Q: Interaction of cross-posted follow-ups?
Date: Thu, 22 Jul 1999 12:35:38 +0200
An hour ago I posted three follow-ups, two to a single group
(sci.crypt), a third in answer to an article cross-posted to two
groups (sci.crypt and sci.crypt.research). Those for a single group
appeared almost instantly, while that to two groups hasn't yet
appeared after an hour.
Long time ago I had the same experience. It seems that the phenomenon
pertains only to the case where one of the cross-posted groups is
moderated and nothing happens until the message is processed by
the moderated group. On the other hand, cross-posting to an arbitrarily
large number of groups is without delays, if these are all unmoderated.
Could someone knowledgeable in the news processing system explain
this phenomenon? Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: Q: Interaction of cross-posted follow-ups?
Date: 22 Jul 1999 11:41:26 GMT
According to Mok-Kong Shen <[EMAIL PROTECTED]>:
> It seems that the phenomenon pertains only to the case where one of
> the cross-posted groups is moderated and nothing happens until the
> message is processed by the moderated group.
That is exactly what happens. A crossposted message is a unique entity,
and if one of the groups is moderated, the message will not appear until
the moderator approved it. Please note that if you crosspost to two
different moderated groups, only the first moderator will process it;
once approved, it will appear instantly in all groups, including the
other moderated one.
--Thomas Pornin
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Open questions about Dave Scotts Method
Date: Thu, 22 Jul 1999 12:03:55 GMT
In article <7n667d$na6$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Joe I don't belitlle him for being a little boy. I just got tired
of reading
> his posts. We went in circles. Very time I tried to answer his
questions
> or make a point he goes to left field. He evne said he was tired of
responding
> to my posts and said he would quit. I guess he has not quit. If he
want to
> write me with short questions I might anwser him. But as young as he
is
> he should look at the code himself if he really wants to learn but I
think
> he is all talk and no action.
Arrrrrg!!! What are you talking about?
I have posted my questions to you about five times (the first msg in
this thread). And you have never answered them. That is because to
answer my questions you would have had to analyze your algorithm. I am
not trying to be mean but if you haven't analyzed your algorithm at all
you are a snake oil peddler to me.
The reason our posts went in circles is because you kept brining
the 'NSA' and 'AES' into conversations like 'how would you break your
method'. You keep asserting your knowledge and that your code is as
good as it gets. But you haven't analyzed it thus you don't know.
Read Applied Crypto: 'It's easy to invent a system that I can't break.
It's hard to invent a system that nobody else can't break.' (something
to that effect). Basically if you don't publish any findings we won't
see it as something you really worked on.
Add this to my questions:
1. Is word size of 19 bits more secure then word size of 16 bits? If
so by how much against iterative attacks?
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "collomb" <[EMAIL PROTECTED]>
Subject: Kryptos Beginning of publicatio of solution
Date: 22 Jul 1999 11:50:42 GMT
To have a general view of this work, please go to my web site�:
http://calvaweb.calvacom.fr/collomb/
The decoding of KRYPTOS step by step
First step
The text of KRYPTOS comprises 4 sentences which end by a question mark ?.
Following these 4 sentences one finds the famous 97 characters.
The point of interogation do not mean that the sentences are
interrogative in themselves but they incite us to question us on the
characters
who make the seriess.
We note, for example, that the first series comprises 100 characters, but
no character O.
Let us remember the reflexion of a former Director of the CIA which,
speaking about KRYPTOS, said that he had the memory < Zero >.
Curiously the second series which counts 125 characters, does not have,
either, the character O !
These two series of characters, are in complicity, they have something in
common: the
character < O > misses.
First series
EMUFPHZLRFAXYUSDJKZLDKRNSHGNFIVJ
YQTQUXQBQVYUVLLTREVJYQTMKYRDMFD
VFPJUDEEHZWETZYVGWHKKQETGFQJNCE
GGWHKK
It thus comprises 100 characters. That leads us to build with these 100
characters, laid out in the order of KRYPTOS, a square of 10 characters by
10
characters :
E M U F P H Z L R F
A X Y U S D J K Z L
D K R N S H G N F I
V J Y Q T Q U X Q B
Q V Y U V L L T R E
V J Y Q T M K Y R D
M F D V F P J U D E
E H Z W E T Z Y V G
W H K K Q E T G F Q
J N C E G G W H K K
The filling of this square was carried out in a natural way, i.e. from
left to the right and from top to bottom.
Second series
Here
DQMCPFQZDQMMIAGPFXHQRLG
TIMVMZJANQLVKQEDAGDVFRPJUNGEUNA
QZGZLECGYUXUEENJTBJLBQCRTBJDFHRR
YIZETKZEMVDUFKSJHKFWHKUWQLSZFTI
HHDDDUVH
The second series has 125 characters which do not make it possible to
build a square. It is known that it is in complicity with the first
series. Both do not have a character < O > .
It is noted that 125 characters + 100 characters make 225 characters with
which
one can build a square of 15 characters X 15 characters = 225.
Now, we will lay out these 125 new characters in order to join them with
the preceding square of 10 X 10, to obtain a new square of 15 X 15.
We take them in order, for building the new square below. We
placed the new 125 characters sticked to the square 10 X 10, to show the
intellectual advance. The provision of these 125 characters was carried
out in a natural way, i.e. from left to the right and from top to
bottom.
E M U F P H Z L R F .... DQ MCP
A X Y U S D J K Z L ....FQ Z DQ
D K R N S H G N F I ....M M IAG
V J Y Q T Q U X Q B .....P F X H Q
Q V Y U V L L T R E .....RL G T I
V J Y Q T M K Y R D ....MV MZ J
M F D V F P J U D E ....AN Q LV
E H Z W E T Z Y V G ...KQ E DA
W H K K Q E T G F Q ..G D VFR
J N C E G G W H K K .....P J U NG
E U N A Q Z G Z L E CGYUX
U E E N J T B J L B Q C R TB
J D F H R R Y I Z E T K Z EM
V D U F K S J H K F WHKUW
Q L S Z F T I H H D D D UVH
We built a new square of 15 characters X 15 characters.
The system htlm does not enable to put each character in a box but the
reader can easily restore the situation.
Here, the square of 10 X 10 become 15 X 15 :
E M U F P H Z L R FDQ MCP
A X Y U S D J K Z LFQ Z DQ
D K R N S H G N F I M M I AG
V J Y Q T Q U X Q B P F X H Q
Q V Y U V L L T R E RL G T I
V J Y Q T M K Y R D MV MZ J
M F D V F P J U D E AN Q LV
E H Z W E T Z Y V GKQ E DA
W H K K Q E T G F QG DVFR
J NC E G G W H K KPJ U NG
E U N A Q Z G Z L E CGY UX
U E E N J T B J L B Q C R T B
J D F H R R Y I Z E T K Z E M
V D U F K S J H K F WHKUW
Q L S Z F T I H H D D D UV H
TO FOLLOW .....
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Compression for encryption
Date: Thu, 22 Jul 1999 11:51:06 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> Compression methods certainly don't hide information of themselves.
> But randomizing the equivalents in compression, like bisecting
> messages to conceal stereotyped beginnings, is a precautionary measure
> that is not harmful.
>
> And it does make sense to optimize a compression method for
> cryptographic purposes: i.e. to ensure that it leaves behind very
> little redundancy, even if that takes computer time not justified by
> bandwith savings alone; to ensure that the redundancy left behind is
> in a form less likely to be useful to a cryptanalyst; to integrate
> compression capabilities into an encryption program so that headers
> indicating compression are not present - all these things are
> sensible, not irresponsible.
you seem to forget that not all messages are sent in post-mortem form.
I could be sending live data where the compression is adaptive (i.e no
hidden information like the tree or dictionary). This also means
bisecting is not possible.
I don't see the justification to create cryptographic compression
routines. It would then rely on compressible plaintext, but what about
MP3 audio for example... Basically some data won't compress well and
you might actually hinder the lines of communication.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Compression for encryption
Date: Thu, 22 Jul 1999 11:52:48 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Further, since compression consumes processing time, it could have
> some substantial impact on the total time required by the analyst
> to decrypt (a security benefit resulting from 'inefficiency').
>
Not really if your stream is live I know that you must be using an
adaptive method and that the first few bytes are literals. Simple
check.
I think people are omitting the fact that not all messages are post-
mortem. Live video and audio is usefull as well and needs attention.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Raja BrewHaHa <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,alt.privacy,alt.security.keydist
Subject: Re: hush mail
Date: Thu, 22 Jul 1999 05:42:47 -0600
=====BEGIN PGP SIGNED MESSAGE=====
On Tue, 20 Jul 1999, Bryan Fordham might hav written:
> I've been looking at HushMail (www.hushmail.com) and have found it
> pretty interesting. I was wondering if anyone thinks it would be
> possible to run a remailer off one of those accounts. I don't think
> so, as the client is in java... but... well, I don't know a whole heck
> of a lot about it.
Reasons not to HushMail:
1. Poor choice regarding private key storage.
2. Piss-poor public key infrastructure.
4. Poor docs.
3. Possible weakness in key generation.
5. Filespace: 1meg limit.
Java (or HushMail's choice to _require_ diskless roaming
capability under JavaSCRIPT) seems to hav reduced cracking to cracking
the pass-phrase with HushMail, as Java proper has no local filesystem in
order to make it safer to download software automatically. It requires a
tighter pass-phrase than PGP. That *might* be acceptable, and this
isn't:
HushMail's FAQ sucks, especially what they omit regarding
signatures and what they say regarding back doors: _No way_ can I see to
trust their public key infrastructure (hashes only!?). Also, they
limited their crypto to Java users (at best), so running a remailer
under it will take PGP and some coding anyway, unless they provide a
pop server.
Then there's 3a. in HushMail's technical description: "The p and
g numbers are strong pre-generated constants given in the applet." That
sounds weak to me, and I'm not familiar enough with Elgamal to say if
it's critical. It just sounds a lot like the description of "common
public modulus", which the PGP attacks FAQ mentions is penetrable.
The FAQ also says that p and q should be chucked if not encrypted as in
PGP. I remember a related remark in the openpgp doc about Elgamal that
said you can find stronger probable primes by subtracting one, then
testing if that divided by two is also probably prime.
Presently, HushMail is wasted computing cycles and ignorant
if not fraudulent hype. Expect to see M$ acquire them soon.
_______
MS: Acronym for a human-crippling disease.
M$: Acronym for a corporation that developed navy-crippling software.
=====BEGIN PGP SIGNATURE=====
Version: <a href="http://www.pgpi.com/">PGPfreeware 5.0i</a>
Charset: noconv
iQEVAwUBN5bWYZRV1wdrBWurAQFwgwf9HRvVDArg4kQbItwL2Eu3GsDeMIiyIIU8
nXXghNw7WGJAqZ1oISXEHhPtai1aCe9C+arIpQvYmNeRlds6T/7oF/8l4L/iqpa1
b5FSYCeRT18k88J6pZ/LNUdVb0etzqOoaJFP+hXNc/lqYtWriyf5SNLjduZAlcx3
w0M7oIVy24DzKyPB5+Ti1iCGQfraSHN9JvlZMrqXtzc4yrq/QUpvDtuxx0XGeHdY
znxe4GErscWUKXD2YmGqay03deU6S+/YSiBqg4KhjPJcylFEnDRl80/iG18Kb7VI
/lorsIB6iubYapGjddyEusqO/DhTCo3L5P9vPwhW2n+Z8hPYsPVGiA==
=0zdN
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Compression for encryption
Date: Thu, 22 Jul 1999 11:58:43 GMT
In article <7n65l1$na6$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> No as a matter of fact most compression routines do not make a
> random file smaller. If any thing they in general make a random file
> longer. There are many reasons for the longer length headers is just
> one of them.
Literal byte encodings as well (LZW methods) although this can be
avoided.
> However if one has data that is of very high entropy not only will
> compression be a waste of time as a first step before encryption
> but high entropy data can safely be encrypted with something as poor
> as any of the AES candidates. Since a person intercepting the
> data would not have a clue what the data was even if the correct
> key along with several others was used to try to break the system.
> However if one is wanting to often send a low entropy message such
> as this post it is best to use a compression routine designed to
> make such files smaller so that the overall entropy of sent message
> is reasied. The problem with most compression routines is that
> even if the file is smaller there are tell tale signs that files are
> compressed. So that if the enemy guess a key he may be able
> to reject the file as a file that is not a valid compressed file. So
it
> is best to use a compression method that does not leave tracks.
> My version of adaptive huffman compression does just that.
> A compression/decompression may be used with encryption
> and will add nothing for the attacker to get a handle on if
> for all ffiles A compressed to B then B decompressed to A
> and for all files C decompressed to D then D decompresses to C
> Of course you would also hope to use a compress/decompression
> method that on the average shortens the length of the files that
> you are tending to use.
If the plaintext is truly random you don't need to encrypt it. Since
the receiver will not make much of it anyways. I don't see any
adaptive method that 'hides' its tracks in the sense that you will not
learn about the compression structure. In huffman cases for example
the data leafs will move closer to the root as they are used more
often. This will be visible because the tree starts in a known
position...
Plus what about files that don't compress much?
A = C(B)
(C = compress)
if H(B) is low so will H(A).
BTW why are AES methods weak? Have you found a break? I would love
to read it...
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Traffic flow confidentiality
Date: Thu, 22 Jul 1999 12:00:52 GMT
In article <7n55qh$7m9$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> However, SSL does not even provide clickstream privacy very reliably.
>
> You can argue over whether SSL was intended to provide clickstream
> privacy or not, but I would argue that many users (rightly or wrongly)
> expect SSL to provide clickstream privacy, so there is either an
> education problem or a technical problem.
I think that SSL was not intented to provide clickstream privacy. It is
just a data encryption network protocol. So I believe this is an
education problem.
>
> In this respect, the lack of padding is relevant to the discussion.
> (I don't know whether padding would actually provide clickstream
privacy,
> but I too am surprised that the standard doesn't even allow for the
> possibility.)
>
> Do you agree?
I agree. The standard of TLS 1.0 should be able to add a random padding
using stream ciphers.
But I think too that the padding length for block ciphers in TLS 1.0
should be longer to provide clickstream privacy. If you think that even
an URL could be much longer than 255 bytes... (not even talk the 64
bytes tops for SSL 3.0)
But now arises another question: If TLS 1.0 is able to add a longer
padding than 255 bytes (lets say, for example, 4096 bytes), is this
worthwhile the overhead of this extra padding for providing clickstream
privacy?
Gabriel
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
