Cryptography-Digest Digest #830, Volume #10 Mon, 3 Jan 00 13:13:01 EST
Contents:
Re: meet-in-the-middle attack for triple DES ("Trevor Jackson, III")
Re: stupid question ("Trevor Jackson, III")
Re: Wagner et Al. (Guy Macon)
Re: crypto and it's usage (Roger Carbol)
Re: meet-in-the-middle attack for triple DES (Bernie Cosell)
Re: news about KRYPTOS ("John E. Gwyn")
Re: On documentation of algorithms ("John E. Gwyn")
Re: how good is RC4? ([EMAIL PROTECTED])
Re: Wagner et Al. (Guy Macon)
Re: Cryptography in Tom Clancy (Eric Lee Green)
Re: crypto and it's usage (Eric Lee Green)
Re: Wagner et Al. (wtshaw)
Re: stupid question ("John E. Gwyn")
Re: news about KRYPTOS ("Ferdinando Stehle")
Re: Bits 1 to 3 (Re: question about primes) ("John E. Gwyn")
----------------------------------------------------------------------------
Date: Mon, 03 Jan 2000 12:16:29 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: meet-in-the-middle attack for triple DES
Rick Braddam wrote:
> Bill Unruh <[EMAIL PROTECTED]> wrote in message
> news:84ol8a$kik$[EMAIL PROTECTED]...
> > In <[EMAIL PROTECTED]> Mok-Kong Shen
> <[EMAIL PROTECTED]> writes:
> >
> > ]If one could manage to have each block encrypted by a different key,
> > ]then such attacks would in my humble opinion be pointless for any
> > ]common block encryption algorithm that offers sufficient difficulty
> > ]to determine the key from only one single pair of corresponding plain
> > ]and cipher texts. On the the further assumption that the key stream
> > ]is not (or barely) subjected to inference, this would seem to leave
> > ]the adversary no other means in practice but to brute force the
> > ]'key' that generates the said key stream. (Note that the key stream
> >
> > Sure, but it will be slow. If your key stream is sufficintly strong,
> > then just xor will probably be fine. many block encryptions take a
> long
> > time to set up the key schedule, and you have to go through this for
> > each and every block.
>
> Suppose you use Wei Dai's Crypto++ library, and instantiate 2 or more
> instances of Blowfish or TwoFish, each with a different key. Then pass
> the first block to the first instance, the second block to the second
> instance, the third block to the first instance, alternating
> blocks/instances to the end of the message. That way key setup is only
> done once at the beginning, and there is no relationship between the odd
> and even blocks. It would be more difficult to do in C code, but still
> possible.
>
> Would that make analysis more difficult?
>
> Would it make a difference if each instance "shared" the IV vs. each
> having its own?
>
> If more secure, what would be the equivilent single-instance key length
> (assume each uses 128 bit key)?
>
> Just curious,
>
> Rick
It would be unreasonable to expect the Opponent is not aware of your
multiplexing mechanism. Given he knows which blocks go together he mounts
one attack on one thread of the multiplexer.
------------------------------
Date: Mon, 03 Jan 2000 12:20:51 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: stupid question
No Spam wrote:
> Trevor Jackson, III wrote:
> >
> > No Spam wrote:
> >
> > > Joseph Ashwood wrote:
> > > >
> > > > > I have a stupid question. But what is the difference between a key of a
> > > > > stream cipher and a key of an one-time-pad ???
> > > > The basic difference is where in the process they are used.
> > > > The basic algorithm is:
> > > >
> > > > data--|
> > > > |
> > > > RNG------Cipher-----output
> > > >
> > > > The difference is where the key is used. In the case of a one time pad the
> > > > key replaces the RNG (the RNG having been run prior, and being a true Random
> > > > Number Generator). In a stream cipher the key is used as a seed to a
> > > > _pseudo_ Random Number Generator (called a pseudo RNG because it does not
> > > > generate truly random numbers). That is the current typical usage, a while
> > > > back there was actually some discussion about what constitues a stream
> > > > cipher and what constitutes a block cipher, and I can extend it to include
> > > > OTP easily. My personal opinion is that a stream cipher function has as it's
> > > > inputs data, key, and the previous data (although the effect of the previous
> > > > data is often limited to the length), a block cipher inputs only data and
> > > > key, an OTP is simply a block cipher where the key is exactly as long as the
> > > > data (we have actually discussed some other issues here but that's the
> > > > basics).
> > > > Joseph
> > > Joseph,
> > >
> > > I too have a stupid question I hope you will answer for me.
> > >
> > > It seems that most of the postings in this news group view the use of
> > > PRNG in encryption as very poor.
> > >
> > > If create a key pass phrase: "ABCDEGGH" and use the first three, two
> > > byte pairs (AB, CD, and EF) as 16 bit seeds for a PRNG.
> > >
> > > Taking the ouput streams fron the PRNG for each of the three seeds, and
> > > XORing the output into a 10K buffer. So the PRNG's output was XORed
> > > into the 10k buffer three times.. each with a different seed (AB, CD,
> > > EF).
> > >
> > > Then I take the last key pair GH, seed the PRNG and use the PRNG to pick
> > > the bytes from the 10K buffer to use as a streaming encryption XOR .
> > >
> > > Is there any attack that can be used to break the code other than a
> > > brute force key phrase attack?
> > >
> > > If a large amount of the plain text was know.. say 100K of a 100,100
> > > byte message, is there an attack the will decrypt the last 100 bytes?
> >
> > Yes. The mechanism will depende on the kind of PRNG you use, but in general
> > you've got a bigger weakness. You are reusing your 10Kb buffer. Ten times on
> > average. Given 100K plaintext & cipher text the entire 10Kb buffer could be
> > exposed, even it it were generated by a true RNG, (thus 80K bits of seed instead
> > of 42 bits).
> >
> > If the whole 10K buffer is not exposed by simple comparison of the plain and
> > cipher texts the few missing bytes will be easily found by testing keys against
> > the vast quantity of buffer contents that are known.
> >
> > If only the pass phrase is secret (the attacker knows how the PRNGs work), you
> > should be able to break the whole system with around 56 bits of plain/ciphertext.
> > It would not be simple, but it would work in time O(N log N) or perhaps O(N^2) on
> > the key length rather than O(2^N) on the key length (brute force).
> >
> > The central concept of this kind of attack is that each bit of plain/cipher text
> > constrains the possible initial seeds. Given enough information the keys are
> > fully determined.
> Trevor,
>
> will changing the buffer size to say 8192 bytes, being an even divisor
> of the seed size correct the problem?
No, the problem is not with the buffer management. The problem is that your extreme
expansion of a few bytes of key into a large mask does not make it any harder to find
the keys. In principle every bit of the buffer that you learn cuts down on the space
of possible keys because ~half of the keys would not generate that bit, but the
complement.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Wagner et Al.
Date: 03 Jan 2000 12:15:58 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Steve K) wrote:
>>A good crypto program can only be attacked
>>from the highest level of access. Yours can be attacked from
>>a few of the lower levels.
>
>Please name a crypto program that meets your specification, i.e. is
>"good" in that it can not be attacked by a trojan. I want to see
>how it does that.
You first. Show me where I ever claimed that such a program exists.
I only defend positions that I have actually said are true <grin>.
What I did claim is that a crypto program that uses standard (easy to
monitor or intercept) windows calls, saves keys and plaintext on
the disk then erases them later, or allows it's memory to be swapped
to the swap file can be attacked by a trojan that cannot touch a
crypto program that doesn't do such things. Clearly the highest
level can do almost anything (there are things in NT that nobody
ever gets the rights to do), and the lowest level can't do anything
at all. In the middle are users and programs that can read standard
windows messaging calls, but cannot read or write the RAM used by
another program.
>It seems to me that this is a case where any program that avoids
>all known attacks simply breeds a new attack, meanwhile giveing
>the user a false sense of security.
I don't like your logic. You seem to imply that because avoiding
all known attacks breeds a new attack, you shouldn't try to avoid
all known attacks. By this logic, you might as well send your
plaintext with skywriting, because using crypto gives the user a
false sense of security. In like manner, just because you cannot
defeat all trojans is no reason to avoid attempts to defeat some
of them. The rational thing to do is to figure cost/benefit, not
to set up a war between perfect and good.
------------------------------
Subject: Re: crypto and it's usage
From: Roger Carbol <[EMAIL PROTECTED]>
Date: Mon, 03 Jan 2000 17:19:56 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> I was just wondering how many people here actually use crypto.
Back when I was in the military, I used it on a fairly
regular basis; I imagine there are a large number of other
military personnel who use crypto on a regular basis as part
of their occupation.
I also do some online banking, and I've been known to rot13
the occasional message.
.. Roger Carbol .. [EMAIL PROTECTED]
------------------------------
From: Bernie Cosell <[EMAIL PROTECTED]>
Subject: Re: meet-in-the-middle attack for triple DES
Date: Mon, 03 Jan 2000 12:22:50 -0500
Scott Fluhrer <[EMAIL PROTECTED]> wrote:
} Simple. Rewrite the equations like so:
}
} DK3(C) = DK2(EK1(P))
}
} Compute the decryption of the known C with all possible K3's, and put them
} into a (2**56 size) list.
}
} Then, go through all possible K2,K1 pairs, and compute DK2(EK1(P)). Search
} to see if that value appears in the list. If it does, use that K1,K2,K3
} triplet to decrypt some more ciphertext. If that works, you just found it.
}
} Time taken = O(2**56) -- to compute the DK3(C) list
} + O(2**127) -- expected time to go through the K1,K2 until we
} find the right one.
Has this *ever* been done? I know there are papers about it [and papers
about how to speed it up and the like], but overall, it seems like it'd be
a pretty impressive feat just to *STORE* all 2^56 blocks, much less do the
2^127 other operations and then the comparisons/lookups against the 2^56.
I'm not even sure what you'd *STORE* 2^56 blocks of data on...:o) I'm
inclined to think that this is mostly theoretical, rather than a practical
plan for "cracking" a TDES encrypted message...
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
[EMAIL PROTECTED] Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
From: "John E. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: news about KRYPTOS
Date: Mon, 03 Jan 2000 11:31:30 -0600
collomb wrote:
> KRYPTOS must be necessarily conceived so that a non-specialist could
> solve this enigma by simple means < paper and pencil > and not by
> means of powerful computers.
That is by no means "necessary", but in fact the vast majority of the
KRYPTOS ciphertext was solved by an analyst using pencil-and-paper
methods, as well as by an analyst using a computer. Their solutions
were identical, *and* confirmed by the sculptor and cryptologist that
the sculptor had consulted.
Your attempts to extract religious messages from KRYPTOS are
delusional.
------------------------------
From: "John E. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: On documentation of algorithms
Date: Mon, 03 Jan 2000 11:38:00 -0600
wtshaw wrote:
> As Einstein said,"If you can't explain it to a child, you
> don't understand enough yourself."
That's not quite what he said, but anyway it is an oversimplification.
Not even the most intelligent 10-year-old child is going to understand
anything that abstracts far beyond his experience or that is
inherently complex. Try explaining ultrafilters, C*-algebras, K
theory, elliptic curves, etc. to a child sometime.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: how good is RC4?
Date: Mon, 03 Jan 2000 17:26:46 GMT
Tom St Denis wrote:
[...]
> it's really simple, no need to read software... it's just
Yes RC4 is simple, but it's very easy to make a
little mistake and get it wrong. Tom should
know after the number of wrong RC4s he's posted.
> init_key()
> {
> x = y = 0;
> for i = 0 to 255
> s[i] = i;
>
> for i = 0 to 255
> y = (y + key[i] + s[i]) mod 256
> tmp = s[y]; s[y] = s[i]; s[i] = tmp;
>
> <dump some>
> }
>
> get_rc4_byte()
> {
> x = (x + 1) mod 256;
> y = (s[x] + y) mod 256;
> tmp = s[x]; s[x] = s[y]; s[y] = tmp;
>
> return s[(s[x] + s[y]) mod 256];
> }
>
> < this is of couse pseudo-C code... >
Replace "key[i]" with "key[i mod key_length]" and
place "y=0" as the last line in init_key(). Then
I _think_ it's correct - but I recommend working
from widely-used specifications or tested code.
> It's not a TM, and call it RC4.
As other pointed out, RC4 is a trademark.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Wagner et Al.
Date: 03 Jan 2000 12:42:29 EST
In article <84qj6h$dq9$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tom St Denis) wrote:
>I seriously doubt that. With java/activex turned completely off I
>doubt there are many venues of attack left open.
Your confidence would be misplaced. There are many such attacks. You can
find them on microsoft's security page, with documentationm of the patches
and upgrades needed to avoid them. Let me pick one at random..
MK Overrun: This bug can cause Internet Explorer 4.0 to crash when
a malicious Web site contains a certain kind of URL (that begins
with "mk://") with more characters than the browser supports. The
extra characters could form a malicious executable that could then
run on your computer.
Obviously the attacks are mostly to older versions, but the new
versions get new attacks that are not publicised by M$ until a
patch has been written.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Cryptography in Tom Clancy
Date: Mon, 03 Jan 2000 10:42:54 -0700
Arturo wrote:
> On Wed, 29 Dec 1999 21:51:13 -0500, "Trevor Jackson, III"
> <[EMAIL PROTECTED]> wrote:
> >Eric Lee Green wrote:
> >
>
> >A few days ago the Air Force announced that it expects B-52s to be in service
> >through 2045.
>
> As the B52�s comes as far back as the 60s, it�s like having
> WWI planes in service today. Saddam�s grandchildren could knock it
> out with stones.
Well, aircraft design has pretty much reached physical limits. Today's
airliners, for example, are almost identical to the jet airliners of the late
60's and early 70's (which had a lot in common with the B52 insofar as design
went), with the difference that they've been re-engined to be more fuel
efficient and quieter, and the electronics have been upgraded. Last time I
looked, they were proposing to re-engine the B52's, and the electronics were
upgraded during the 1980's if I remember correctly and they're proposing to
upgrade the electronics yet again early in this (21st) century. So to say that
they're going to have B-52s in service through 2045 is kind of incorrect --
they will have B-52 *AIRFRAMES* in service through 2045, but the actual guts
of the plane will have pretty much been stripped out and replaced from
scratch.
Not to mention that the B-52's role today is to keep AWAY from combat zones --
they're cruise missile platforms, not bombing platforms (the bombing platform
role has been handed over to the B-2 stealth bomber and its guided "smart
bombs"). If you're looking for a big airframe to lurk offshore and drop cruise
missiles, it doesn't matter that the thing is slow, clumsy, and extremely
vulnerable to any modern-day anti-aircraft measures (or even to 1960's
anti-aircraft measures, for that matter). You just want the cheapest, biggest
thing you can get out there. Other than re-fitting 747's to carry cruise
missiles, B-52's are pretty much the best solution out there for that task.
Anyhow, we're far from crypto. My point of mentioning B-52's was that the
Armed Forces tend to keep technology around for a LONG time, meaning that Tom
Clancy having a cipher used 10 years ago be broken by the NSA doesn't mean
that it was a 10-year-old cipher -- the cipher machine used to encode messages
10 years ago may have been as much as 20 years old at that time, meaning
they'd be 30 years old today and woefully inadequate.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: crypto and it's usage
Date: Mon, 03 Jan 2000 10:45:48 -0700
Tom St Denis wrote:
> I was just wondering how many people here actually use crypto. I mean
> almost anyone here can pull apart ideas and have fun, but does anyone
> use what's left?
>
> I personally use it just for fun, and sometimes to keep things
> private. Nothing life threatening... Anyone else?
Banks are VERY interested in having their financial data encrypted so that
attackers cannot get to it.
I shouldn't have mentioned even that much, sigh.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Wagner et Al.
Date: Mon, 03 Jan 2000 12:24:55 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Steve K) wrote:
>
> Please name a crypto program that meets your specification, i.e. is
> "good" in that it can not be attacked by a trojan. I want to see how
> it does that. It seems to me that this is a case where any program
> that avoids all known attacks simply breeds a new attack, meanwhile
> giveing the user a false sense of security.
>
You rang?
The requirements are: Use an email program that does not automatically run
attachments; use a system that does not sponsor attacks; do not have other
programs in the computer that can offer assistance to known attacks
against software; and, use a crypto program that is otherwise computer
security compliant.
--
Considering that the best guess is that Jesus was born in 4 BC,
for the purists, fate worshipers, and absolute prognosticators,
you all missed your boat fome time ago, as hype mongers rejoice.
------------------------------
From: "John E. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: stupid question
Date: Mon, 03 Jan 2000 11:54:26 -0600
Guy Macon wrote:
> [EMAIL PROTECTED] (actually Douglas A. Gwyn) wrote:
> >A stream cipher produces an output symbol for each input symbol,
> >without having to buffer up input symbols into a block before
> >encrypting them. (The other design is called, appropriately, a
> >"block cipher".)
> I am not sure how to interpet "symbol". If I take a plaintext
> and an equally sized randomtext (if such exists) and exlusive
> or them to create my ciphertext, I can treat the two input streams
> as a series of bits. If I replace the XOR with various other
> combining methods, I need to treat the two input streams as a series
> of bytes. If I use Unicode. bytes are too small. I can imagine
> working on a series of 1K graphics files that each display a single
> letter. Would a "block" cipher with 1K blocks become a stream cipher
> in the case of the graphics files? This is a silly example, but my
> question is real - I don't think that I can define the difference
> between a stream and block cipher with rigor.
I already gave you a fairly rigorous definition.
Traditionally, a symbol was a letter of the alphabet, but these
days is most often a single bit, sometimes an octet. ("Byte"
denotes a collection of adjacent bits treated as a unit, not
necessarily 8 bits, although in many contexts the latter is now
an established convention.) The important thing is that a
"symbol" encodes an atomic unit of the data being communicated,
such that any smaller amount of data cannot be identified until
more data arrives.
In a block cipher, the block is collected together merely because
the encryption method requires it, not because each block means
something definite as a unit.
Some convolutional codes (m/n with m not equal to 1) combine a
small number of input bits into a single output symbol; these are
stream-oriented in their design but have a touch of block-like
flavor due to the meaning-oblivious chunking of the data bits.
This illustrates the fact that the stream-vs.-block categorization
is incomplete, but that doesn't mean that we can't tell the
difference between clear examples of stream vs. block ciphers.
- Douglas
------------------------------
From: "Ferdinando Stehle" <[EMAIL PROTECTED]>
Subject: Re: news about KRYPTOS
Date: Mon, 03 Jan 2000 18:03:21 GMT
John E. Gwyn wrote
>Ferdinando Stehle wrote:
>> - why wasting the entire right side of the sculpture devoted to the
>> Vigenere table used only in one third of KRYPTOS ?
>>
>
>It's not a waste, it's a pleasing pattern with "KRYPTOS" clearly
>evident. The additional columns balance the width against the
>message side.
hmm... maybe you're right
but what i meant was that J.Sanborn could have put a meaning in
the right side, usefult to decrypt the Part 4...
in fact, the right side shows, as J.Gillogly said, a Quagmire II table.
...may be that has to be used to solve Part 4.
I'm not completely convinced about the decorative pattern of "KRYPTOS"...
why the Quagmire III table KRYPTOSABC... is surrounded by
ABCDEFGH... (the normal alphabet) on top, on bottom and on the right ?
...and why the KRYPTOSABCD... string is longer than 26 chars
(indeed it is 30 chars long) ??
.ABCDEFGH...
AKRYPTOSA...
BRYPTOSAB...
CYPTOSABC...
....
i think that the ABCDEF.. frame should have a reason to be there.
...but maybe i'm wrong.
regards
Ferdinando
------------------------------
From: "John E. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Bits 1 to 3 (Re: question about primes)
Date: Mon, 03 Jan 2000 12:05:13 -0600
"Tony T. Warnock" wrote:
> According to Dirichlet's theorem, the density of primes in arithmetic
> progression is the same for all progressions with the same step size.
> Thus the density of primes ending in 1,3,7,9 (base ten) is the same.
I am unable to decipher that. "The same" as what? Surely, not as
each other: 0,2,4,6,8 vs. 1,3,5,7,9 is a counterexample. 1,3,7,9
final digits aren't an arithmetic progression. ???
------------------------------
** 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
******************************
