Cryptography-Digest Digest #690, Volume #10 Mon, 6 Dec 99 10:13:01 EST
Contents:
Re: Random Noise Encryption Buffs (Look Here) ("r.e.s.")
Re: Random Noise Encryption Buffs (Look Here) ("r.e.s.")
Re: NEMA missing a plugboard? (Frode Weierud)
Re: MMPC - A multi-message encryption algorithm (zapzing)
Re: AES cyphers leak information like sieves (Volker Hetzer)
Re: High Speed (1GBit/s) 3DES Processor (Volker Hetzer)
about the interpolation attack on block ciphers ("GyungHwa Jun")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES (Volker Hetzer)
Re: Noise Encryption ("Tim Wood")
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Enigma, Scott19, Lord Caligo, & Factoring (JPeschel)
Re: Wanted: One-way hash sourcecode or algorithm (Keith A Monahan)
Re: Noise Encryption (Mattias Wecksten)
Re: NSA should do a cryptoanalysis of AES (SCOTT19U.ZIP_GUY)
Cryptix and blind signature (Szalai Zsolt)
----------------------------------------------------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Sun, 5 Dec 1999 23:22:11 -0800
"David Wagner" <[EMAIL PROTECTED]> wrote ...
: r.e.s. <[EMAIL PROTECTED]> wrote:
: > Let x1,x2,... be mutually independent binary random variables
: > with pr(xi=1)=pr(xi=0)=1/2, and let y1,y2,... be binary random
: > variables independent of the xi, but mutually correlated *among
: > themselves*, with nonzero covariance cov(y(i),y(i+1)).
: >
: > Now zi = (xi XOR yi) = xi + yi - xi*yi,
^^^^^^^
Oy! I mis-remembered this -- it should of course be
zi = (xi XOR yi) = xi + yi - 2*xi*yi
: > so we can easily calculate
: > the covariance between z(i) and z(i+1), which I find to be
: > cov(z(i),z(i+1)) = cov(y(i),y(i+1))/4 (nonzero).
: >
: > So if {yi} is a pairwise correlated sequence, then the same will
: > be true of {xi XOR yi}, even though {xi} was an iid sequence.
:
: I think you'd better double-check your math.
Right. The above calculation does indeed return cov(y(i),y(i+1))=0
when done using zi = (xi XOR yi) = xi + yi - 2*xi*yi.
: Suppose x1,x2 are independent coin flips.
: Suppose y1 is a single coin flip (independent of the x's), and y2=y1.
: This is the most extreme case of correlation possible for the y's.
:
: Let zj=xj XOR yj.
: Then it is readily confirmed that z1 is independent of z2.
: For instance, Pr[z1=0,z2=0] = Pr[x1=y1,x2=y2] = Pr[x1=x2=y1] = 1/4.
: And Pr[z1=0,z2=1] = Pr[x1=y1,x2=y2 XOR 1] = Pr[x1=x2 XOR 1=y1] = 1/4.
: And so on.
:
: Maybe you made a mistake in your calculations?
Yup -- my apologies to Guy Macon for wrongly impuning his MOM ;-) ;-)
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Sun, 5 Dec 1999 23:56:12 -0800
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote ...
: r.e.s. wrote:
: > "Guy Macon" <[EMAIL PROTECTED]> wrote ...
: > [...]
: > : An Exclusive OR (XOR) of a RBS with any sequence not derived
: > : from the same RBS is still a RBS. XORing any sequence will
: > : not and can not reduce the randomness.
: >
: > Alas, this is not true if the elements of the sequence are
: > required to be mutually independent, or at least uncorrelated.
Alas, the mistake is mine indeed -- sorry Guy.
: > Let x1,x2,... be mutually independent binary random variables
: > with pr(xi=1)=pr(xi=0)=1/2, and let y1,y2,... be binary random
: > variables independent of the xi, but mutually correlated *among
: > themselves*, with nonzero covariance cov(y(i),y(i+1)).
: >
: > Now zi = (xi XOR yi) = xi + yi - xi*yi,
^^^^^^^
[...]
: > It was a neat idea, but I believe the flaw is fatal.
: No. Your mathematical model is flawed.
Mea culpa...
I mis-remembered the above formula, which should have been
zi = (xi XOR yi) = xi + yi - 2*xi*yi. That caused the covariance
calculation to give nonzero, when indeed it gives zero when done
correctly.
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Frode Weierud)
Subject: Re: NEMA missing a plugboard?
Date: 6 Dec 1999 08:06:28 GMT
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] (UBCHI2) writes:
>Why did the designers of the NEMA rotor machine leave out the plugboard found
>on the enigma. Wouldn't the plugboard dramatically increase the difficulty of
>cryptanalysis of a rotor machine message?
It is perhaps better to ask why they did not reinvent the plugboard.
As far as I know the designers of the NEMA were unaware of the Enigma
plugboard. They based their design on the commercial Enigma machine,
model K, which did not have a plugboard.
The knowledge of the design of the Wehrmacht Enigma would probably have
been known to them before the NEMA was put into service in 1947 but at
that stage it was probably too late to change the design.
I asked one of the designers why they had not included a plugboard and
the reason he gave was that they considered the irregular stepping of
the rotors to be adequate. Also they decided to bury the fast stepping
rotors in the middle of the rotor bank such as to make rotor stripping
attacks a lot more difficult. Seen in this light their decision to do
without a plugboard is understandable. However, a plugboard would have
further strengthened the machine.
Frode
--
Frode Weierud Phone : +41 22 7674794
CERN, SL, CH-1211 Geneva 23, Fax : +41 22 7679185
Switzerland E-mail : [EMAIL PROTECTED]
WWW : home.cern.ch/~frode
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: MMPC - A multi-message encryption algorithm
Date: Mon, 06 Dec 1999 08:31:25 GMT
I read the article and it was very interesting.
But doesn't MMPC provide a large subliminal
channel, through which malicious software,
for example, could communicate information
about the key? Do you have any suggestions
for eliminating the subliminal channel?
Thanx, ZZ
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: Mon, 06 Dec 1999 09:04:43 +0000
Tim Tyler wrote:
>
> Volker Hetzer <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
> :> Volker Hetzer <[EMAIL PROTECTED]> wrote:
>
> [block size doubling ==> work required for a break doubling?]
>
> :> : If [...] the usual attacks (like differential) will require the
> :> : same number of blocks
> :>
> :> Some attacks will require a /much/ larger numbers of blocks, however.
> :
> : Such as?
>
> Say you're compiling a dictionary of blocks, which matches blocks to
> corresponding plaintexts. Say you have a target of getting 1/8 of the
> blocks. This lets you take vague guesses at the contents of the message,
> pretty much regardless of the block size.
Why should I do this? If I'm able to compile a dictionary with the right
key
I can decrypt the messages anyway.
Did you mix it up with the kind of attack where you compile one block
with every possible key?
In that case the amount of data grows exponentially with the keysize and
linear
with the block size.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me
spread!
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Crossposted-To: comp.dcom.vpn,comp.security.firewalls
Subject: Re: High Speed (1GBit/s) 3DES Processor
Date: Mon, 06 Dec 1999 09:07:00 +0000
Paul Koning wrote:
> If so, additional parallellism doesn't gain you anything
> for single stream throughput because you can't parallelize CBC
> encryption...
Or rather this requires interleaving which, in turn requires the
cooperation
of the sending party.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me
spread!
------------------------------
From: "GyungHwa Jun" <[EMAIL PROTECTED]>
Subject: about the interpolation attack on block ciphers
Date: Mon, 06 Dec 1999 09:18:00 GMT
While I'm reading the paper "The Interpolation Attack on Block ciphers" by
T. Jakobsen and L. Knudsen, there exists a equation that I'm not able to
understand.
In Section 2, equation(1) is deduced by the result[proposition 2] in Xuejia
Lai's paper, "Higher Order Derivatives and Differential Cryptanalysis". Why
is it trivial that the equation(1) is vallid?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Mon, 06 Dec 1999 09:44:03 GMT
"SCOTT19U.ZIP_GUY" wrote:
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> >Except for the obvious case where a highly predictable "header"
> >gives one (in effect) known plaintext, that claim seems counter-
> >intuitive. Compression removes a *lot* of redundancy. Could
> >you give a specific example of this information "leakage"?
> You mean again.
Sure. I must have missed it the first time. Is this a quibble
over whether a compression scheme that could have been 75%
effective is only 73% effective, or is it something else?
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Mon, 06 Dec 1999 10:01:17 +0000
Rick Braddam wrote:
>
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> > The chaining modes are not *meant* to evenly disperse PT
> > information throughout a message; to do so would require the
> > entire message to be available at one time, which is often not
> > the case for real encrypted communication channels.
>
> I've read this several times, on different threads. Each time I wonder *how* often
>it is not the case that the entire message is
> available at one time.
Whenever encryption is not performed at the uppermost application layer.
> I know that there are streaming audio & video for computer users, tv, telephone, and
>maybe even telegraph (for all I know), and that
> the best type of encryption for me might not be the best type for those uses.
You forget link-level encryption.
And remote logins.
> I don't mean to belittle applications where the complete message is not available
>before transmission
> starts. I'm just pointing out that they may not be applicable to the majority of
>users of the Internet.
> So I'm asking: what type of data are the largest number of users concerned with?
- http requests. they might be encrypted on one block, but is it worth
the bother?
- html pages. If a server has to keep the whole page in memory twice I
think that would create problems
because for servers under heavy load this leads to higher memory
usage. As to "next year", yes, memory
might be cheaper then, but the number of internet users will have
increased too.
- Sound and video. This is NOT only commercial. There are many
non-commercial videos and sounds out there.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me
spread!
------------------------------
From: "Tim Wood" <[EMAIL PROTECTED]>
Subject: Re: Noise Encryption
Date: Mon, 6 Dec 1999 10:21:52 -0000
Mattias Wecksten wrote in message <[EMAIL PROTECTED]>...
>> Erm, no, I think the Key-randomness is critical, if you can guess the key
>> you can recover the message.
>
> Yes, of course - if you can guess the key you can decrypt the message.
This
>is
> true for all keys - also true random keys.
however if your key is truely random (assuming that is possible) there is no
mechanism for guessing the key. This means that the OTP in this case is
provably secure, there is no possible mathamatical attack against the key or
the message. The cyphertext decrypts to all plaintexts (of the same length)
with _exactly_ equal probability. There is no method for crypt-analysis.
>
>> Also you must never reuse the same key...
>
> Of course, it would not be interesting to discuss otherwise.
>
>> OTP is as secure as your key generation actually. OTP=Secure if
KEYgen=Random.
>
> I disagree. I will try to explain why.
>
>Assumption:
>
> * Algorithm is known.
This should include the method of key generation. This is where the
potential weakness of a non random source comes in.
> * Encrypted text is known.
> * Key is not known.
> * Plaintext is not known.
>
>Statements:
>
> If the key is true random, the algorithm is "add" without carry, and
the
>plaintext is
> same character repeated (not random) the encrypted text will still be
true
>random.
> If the key is same character repeated (not random), the algorithm is
"add"
>without carry, and the
> plaintext is true random the encrypted text will still be true random.
But if neither is random, then it may be possible to attack the cipher with
a small amount of other knowledge, like for instance the PRNG. It may be
possible to give some plaintext _different_ probabilitys of being the
correct decipherment (attacks on PRNG have occured) in fact it may be
possible to reduce the key to such a level where a brute force attack then
language frequency analysis may be possible.
>
>Result:
>
> Since these two cases will result in the same distribution you cannot
tell
>them apart (actually
> they can generate the same encrypted text). This results in that you
cannot
>say how random
> the key is or how random the message is. All cases in between can and
do
>exist.
That is not true they are both special cases. They are the _only_ two cases
when the cipher is provably secure.
In fact the second case is a non-case, it is effectivley the first case.
(the algorhythm used does exactly the same to the plaintext as it does to
the key.)
>
> If you use a limited amount of data you can get a distribution that is
>impossible to tell apart from
> a "true" random set.
True but then the cipher is not perfect, you have to limit the data amount,
using a true random key the size of data is immaterial. The cipher is always
secure.
>
>Assumption:
>
> * The range for the sets are [i E N; 0<i<10]
> * One data subset is from a true random set.
> * One data subset is from a generated set.
>
>Example:
>
> 1. a = { 4, 4, 4, 4 }
> 2. b = { 9, 3, 7, 2 }
>
>Result:
>
> You cannot tell the subsets apart (a is from a real random
distribution).
I may well be able to if you gave me several KB of data. This is not
inconcivable. Pseudo-Random Number Generators (PRNG) are difficult to
produce so that they are not predicatable. Also they all (as far as I know)
have periods after which they repeat.If this period is long in many cases it
does not matter, in the case of the OTP it does.
>
> The important thing is to use a key that could not be guessed - yes,
but
>this do not
> by itself mean that the key has to be "true" random.
I agree, many stream ciphers work this way. They are not provably perfectly
secure, in fact some have been attacked as I described above. Applied
Cryptograph has some examples....
Summation Generator, Rueppel's Seld-Decimated generator.... Designing stream
ciphers is difficulty but there are some which are thought secure. They are
not OTPs for the reasons I have disscused (non uniform probability amongst
possible plaintexts). They in effect have a key (the generator seed).
>The real problem with
>OTP is to transport the key by a secure media.
This is not always a problem. For instance it is easy for two ships in the
same dock to transfer key material bettween the but not two ships that have
sailed to opposite sides of the world!
If they had exchanged key material they would be able to exchange perfectly
secure material.
>
>> I would however be interested in your scheme for a secure system using
>> JavaScript and compiler? Could you post a little more elaborately or was
>> that just some strange comment not meant to be taken literally?
>
> I would love to if there is an audience for it.
I consider my self an audience, or put it on a web page (if you don't have
one mail me and i'll host it on mine - if it's any good).
>
>> whats "MvH M WxX" ?
>
> MvH = Med v�nliga H�lsningar (Sincerely in .se language)
> WxX = W-[ex]-ten [Wecksten]
Ahh, I see.
>
> That is all *hoping for a nice discussion*,
>
> MvH M WxX
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: 06 Dec 1999 05:30:39 EST
In article <82fo1k$7p0$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (r.e.s.) wrote:
>: Maybe you made a mistake in your calculations?
>Yup -- my apologies to Guy Macon for wrongly impuning his MOM ;-) ;-)
I was actually a bit disapointed reading your apology. My goal is to
gain a practical undersatanding of this subject, and there is nothing
like concocting a hairbrained scheme that looks perfect and having it
shot down in flames by an old salt when it comes to understanding
something.
I sure did do a great setup for that "impuning his MOM" joke! LOL!
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Enigma, Scott19, Lord Caligo, & Factoring
Date: 06 Dec 1999 12:51:25 GMT
To my web site I've added a new page, "Historical
Ciphers." Currently, the page contains only
a few links to good Enigma sites, but it's also
home to various Enigma and Bombe simulators.
I hope to add Gillogly's paper, "Ciphetext-only
Cryptanalysis of Enigma" soon.
I have also added a new clue to Scott's gloat contest,
a new tool by Lord Caligo that displays hidden
ICQ information and a factoring tool. The clue
is in the "Contests" section, the ICQ tool and
the factoring program are on the "Key Recovery
Resources" page.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: Wanted: One-way hash sourcecode or algorithm
Date: 6 Dec 1999 13:25:26 GMT
For MD5, go to
http://theory.lcs.mit.edu/~rivest/rfc1321.txt
SHA-1 is another good choice but for whatever
reason I can't find a decent link to source or
the specification. I have a headache and it's
Monday morning, so you'll have to do some digging
yourself. FIPS 180-1 is the document that describes
it, I'm pretty sure.
Keith
Mattias Wecksten ([EMAIL PROTECTED]) wrote:
: I am searching for a one way hash source or algorithm.
: Any information appreciated.
: M WxX
------------------------------
From: Mattias Wecksten <[EMAIL PROTECTED]>
Subject: Re: Noise Encryption
Date: Mon, 06 Dec 1999 15:13:27 +0100
Tim Wood wrote:
> Mattias Wecksten wrote in message <[EMAIL PROTECTED]>...
> >
> >Assumption:
> >
> > * Algorithm is known.
>
> This should include the method of key generation. This is where the
> potential weakness of a non random source comes in.
>
I think this is the center of all disagreements. What if you use a non
algorithmic random generator. There is still not true randomness, but still
there is no way of "guessing" the data.
Sincerely
M WxX
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Mon, 06 Dec 1999 15:21:42 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>"SCOTT19U.ZIP_GUY" wrote:
>> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>> >Except for the obvious case where a highly predictable "header"
>> >gives one (in effect) known plaintext, that claim seems counter-
>> >intuitive. Compression removes a *lot* of redundancy. Could
>> >you give a specific example of this information "leakage"?
>> You mean again.
>
>Sure. I must have missed it the first time. Is this a quibble
>over whether a compression scheme that could have been 75%
>effective is only 73% effective, or is it something else?
No this is based on the fact that if one looks at a binary file.
One can quickly determine if it is one that could have resulted
from the compression in use. Most compression schemes
are such that Decompress(Compress(X))=X for all X
But so far only the ones I've written (in open lititature) have
the addtional property that Compress(Decompress(X))=X
for any X. This is something the average user can check on his
own. Takes files are random and try to decompress them and
then compress them back. The problem is far more than just
the headers. It is so bad that for many encrypted messages
you may be guaranteeing the fact that the only Key that can
lead to a valid solution is the one the user used. Which means
the attacker may have enough info to break your message on a
cipher only type of attack.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: Szalai Zsolt <[EMAIL PROTECTED]>
Subject: Cryptix and blind signature
Date: Mon, 06 Dec 1999 15:20:44 +0100
Hi!
I plan to use the Cryptix library (3.1.1) but I need some
blind signature stuff as well. Is there any free library
what implements the blind signature (and it can work with
Cryptix or it contains the major algorithms (RSA, DES))?
Thx
Zsolt
------------------------------
** 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
******************************
