Cryptography-Digest Digest #628, Volume #13 Sun, 4 Feb 01 15:13:00 EST
Contents:
Re: Tree algorithm (Paul Crowley)
Re: ideas of D.Chaum about digital cash and whether tax offices are delighted ?
(George Weinberg)
Re: What do you do with broken crypto hardware? ("Tor Rustad")
Re: Pseudo Random Number Generator (Crypto Neophyte)
Re: MIKE - alternative to SPEKE and PAK ("Michael Scott")
Re: Encrypting Predictable Files (Dido Sevilla)
Re: On combining permutations and substitutions in encryption (David Wagner)
Re: On combining permutations and substitutions in encryption (David Wagner)
Re: PGP Crack (Dido Sevilla)
Re: PGP Crack ([EMAIL PROTECTED])
Re: On combining permutations and substitutions in encryption (Terry Ritter)
----------------------------------------------------------------------------
Subject: Re: Tree algorithm
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Sun, 04 Feb 2001 17:04:01 GMT
If you're interested in cryptographic algorithms based on trees, look
at the stream cipher LEVIATHAN.
http://www.cluefactory.org.uk/paul/crypto/leviathan.html
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: [EMAIL PROTECTED] (George Weinberg)
Crossposted-To: talk.politics.crypto,alt.cypherpunks
Subject: Re: ideas of D.Chaum about digital cash and whether tax offices are
delighted ?
Date: Sun, 04 Feb 2001 17:19:57 GMT
On Sun, 04 Feb 2001 00:18:03 +0100, "Thomas J. Boschloo"
<[EMAIL PROTECTED]> wrote:
>Reply-To: boschloo<at>multiweb<dot>nl
>
>Phew, I am glad you think about it that way. I am always scared to get
>my ass fried over things like this. We sort of have a pedophile hunt
>going on in Holland right now. Recently someone got killed and he is now
>a folk hero called 'the pedokiller'.
>
You mean the killer is the hero, right? People say it's
only in Texas that "He needed killing" is still considered a defense
for murder, but actually it's a defense anywhere you have trial by
jury.
>And this type of pornography is just one of the issues (although a very
>popular one at the moment). There is also stuff like snuff movies (ever
>seen Lost Highway or Videodrones by respectively David Lynch and David
>Cronenburg?)
It's important to recoginize that these are fiction.
>I also had an somewhat related (anti-echelon) thought about firearms
>(since you Americans seem so obsessed with that).
>From my observations, it's primarily anti-funners that are "obsessed"
with firearms.
>hat if there would be
>a technology that allowed every bullet to be traced by some homing
>signal. Just like GSM phones are now. Would we use it to stop
>drive-by-shootings and terrorist actions in shopping malls?
Never work in the real world. A bullet with a GPS installed in would
probably cost about a grand, as opposed to more like a nickle for
a normal lead one, which would work better. No chance of getting
anyone to use something like this, ever.
>I sure am confusing myself :-) Thanks for all the responces so far. I
>think this is an important discussion, even if I don't get all the
>topics right first time.
>
>What is your standing on Assassination Politics by Jim Bell? In it
>bad/corrupt politicians get killed by pseudonymiously 'predicting' the
>time of death of that politician. Sure it can also be used against
>'good' politicians (like JFK??).
>
I don't see how it could. JFK only became a 'good' politician
after he was shot.
George
>TIA,
>Thomas J. Boschloo
>Den Helder, Holland
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
>
>iQB5AwUBOnyDmAEP2l8iXKAJAQHStQMeKbjRDbArkTnBsivmyH7fRpZpDTR6mktn
>ELaOHBXtvT64iFOdz5e/eqnmQp0oNqdOq0ZtaBZauwWgYGnwdguGlSy87Ztoxvwi
>diwdMTIlfrUciL+vyWo6NaeaE/RWDd3P9kTjIw==
>=W5Bb
>-----END PGP SIGNATURE-----
>--
>-----BEGIN PGP MESSAGE-----
>Comment: This dirty signed executable will twart Netsafe 4.2
>Comment: Try Netsafe at <http://www.ozemail.com.au/~netsafe>
>
>owEBzQAy/4kAeQMFADpc/IoBD9pfIlygCQEBvXYDHjqpd4mblDvTxQsubVPZAhEL
>21LgMaNgT5rE9+Te4zLxaC4XpcnC7uMXSMPDWOPGHCijf9J2jo9HdrYsjQWPWUXH
>JgwazJ88Df13S3QG8R3+i+uxtGxCG6OPr94nLSbdfcrO/6isT2IMdC11bnNhZmUu
>Y29tAAAAAOsjLoA+/wAAdAHPgPwwdRBQLv4G/wC0TM0hLv4O/wBYLv8uXAC4ITXN
>IYkeXACMBl4AtCW6AgHNIbIlzSc=
>=3E5B
>-----END PGP MESSAGE-----
>
------------------------------
From: "Tor Rustad" <[EMAIL PROTECTED]>
Subject: Re: What do you do with broken crypto hardware?
Date: Sun, 4 Feb 2001 18:25:29 +0100
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
> I'm wondering if anyone else here is using crypto hardware modules for
> key management. What do you do if one malfunctions?
Normally we have regular service intervals, where the manufacturer send a
technician, who is able to fix most problems. No sensitive keying material
will be easy accessable at that point, since beforehand the HW has been
zerozied either manually, or by simply moving the box'es outside the TCB
(trusted computing base). Even so, the technician will _not_ be left alone
during his work, but is superviced by internal security experts.
I only recall one case where we have sent a box the manufacturer, before
doing so, the box was zeroized and even the firmware removed. In that case,
the application keys was stored outside the box as cryptograms on a hard
disk, so the manufacturer would not gain much from analyzing the box. It was
anyway a "low-value" service.
> I haven't had any trouble with the modules I'm using, but would like
> to know some typical policies people use, in case something happens.
The policy depent on the value of the keys. If you are talking about
"finacial" master keys at national level, well then these things should not
be taken lightly. Se the post by Peter Gutmann in this thread, and read DOD
5220.22-M and aswell a paper by Peter on these matters. Deleting information
is not as simple as people might think, sanitizing is the only choice in
some cases.
--
Tor <torust AT online DOT no>
------------------------------
From: Crypto Neophyte <[EMAIL PROTECTED]>
Subject: Re: Pseudo Random Number Generator
Crossposted-To: talk.politics.crypto
Date: Sun, 04 Feb 2001 17:28:13 GMT
On Sat, 3 Feb 2001 23:46:17 -0600, Matthew Montchalin wrote
(in message
<[EMAIL PROTECTED]>):
Snip
> Well, compressing a DVD which is already compressed, should inflate it in
> some obvious (?) sort of way. And after that, you can encrypt it, I guess.
> As I have said in the past, and which others seem to have said, the weak
> point in all these encryption systems is the human element. There's just
> not much a 'high' security echelon can do in trying to straighten out an
> unreliable or incompetent lackey; all the codes in the world here won't help.
After reading this thread I see more of a potential for using this scheme to
transfer passwords. I am a person who just does not trust public key systems
and the problem with traditional crypto is how do you transfer the key. And
face it, with a 1024 bit key you have write it down somewhere. Sure you can
encrypt it but then you need another key.
Lets say that Bob and Alice agree before hand that they will use DVD's to
obtain the key for messages. The DVD will be the number one DVD on the top
selling DVD chart. The day of the week the message is sent (Monday = 1) is
the scene that is used and the hour is how many seconds into the scene that
defines the start of the key.
Bob and Carol can decide on a different way to choose a DVD segment.
In order to make it a little more secure it could be agreed to change the
information from the bit stream in an algorhythm that can be easily
remembered and coded into the key determination software.
HKRIS
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: MIKE - alternative to SPEKE and PAK
Date: Sun, 04 Feb 2001 18:04:54 GMT
"Thomas Wu" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Michael Scott" <[EMAIL PROTECTED]> writes:
>
> > "Michael Scott" <[EMAIL PROTECTED]> wrote in message
> > news:iWLe6.100186$[EMAIL PROTECTED]...
> > >
> > > "Thomas Wu" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > > "Michael Scott" <[EMAIL PROTECTED]> writes:
> > > >
> > > > > "Thomas Wu" <[EMAIL PROTECTED]> wrote in message
> > > > > news:[EMAIL PROTECTED]...
> Huh? If a fake client Chris comes along, can't she do step 3, get Steve's
> response in step 4, and just keep guessing x until the test in step 5
> (H(B/u^x) == w) passes? That would let her do an offline dictionary
> attack after one failed exchange. Did I miss something?
>
Quite right. That was dumb of me. Which leaves me with either.....
3. Carol: A=3^a mod p, w=4^c mod p, a and c random. Sends {A,w} to Steve
4. Steve: B=3^b.v^r mod p. u=4^r mod p, b and r random. F=H(w^r). Sends
{B,u,F} to Carol
5. Carol: Check F=?=H(u^c). If not abort, else S=(B/u^x)^a. Steve calculates
S=A^b
The idea is the same, to force Steve to make u=4^something by engaging in a
base-4 Diffie-Hellman. Only if it he does will Carol continue.
..... or the somewhat faster alternative, as previously posted but tidied up
a little, which includes the result of the base-4 DH in the key.
3. Carol: A=3^a mod p, w=4^c mod p, a and c random. Sends {A,w} to Steve
4. Steve: B=3^b.v^r mod p. u=4^r mod p, b and r random. Send {B,u} to Carol.
5. Carol: S=B^a.u^(c-ax) mod p. Steve calulates S=A^b.w^r
Mike Scott
> Tom
> --
> Tom Wu * finger -l [EMAIL PROTECTED] for PGP
key *
> E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms
in
> Phone: (650) 723-1565 exchange for security deserve
neither."
> http://www-cs-students.stanford.edu/~tjw/
http://srp.stanford.edu/srp/
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: Encrypting Predictable Files
Date: Mon, 05 Feb 2001 02:27:01 +0800
DJohn37050 wrote:
>
> If really concerned, do double CBC. Then every bit is dependant on every other
> bit.
I suppose you mean do CBC once with the blocks in the proper order, and
then CBC again with the blocks in reverse order. Just doing CBC twice
is double encryption, which only gets you with your first block
encrypted twice with the same key, and I don't see how beneficial this
is to preventing known plaintext attacks. It doesn't make every bit
dependent (note the correct spelling) on every other. Doing CBC once
forwards and once backwards, or in fact encrypting the second time
starting with some other ciphertext block than the first and doing CBC
on all the blocks in some other consistent order will do that though.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: On combining permutations and substitutions in encryption
Date: 4 Feb 2001 18:34:54 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Douglas A. Gwyn wrote:
>David Wagner wrote:
>> If you build any cipher that (1) runs in polynomial time,
>
>What would that mean? Any specific system runs in O(1) time.
I over-simplified. To be more precise, you need to give me a family
of ciphers {C_k}, one for each value of k. Think of k as a security
parameter: The running time of C_k must be polynomial in k, whereas the
security condition is that breaking C_k should be super-polynomial in k.
If there exists a family of ciphers where these two conditions are met,
then P != NP.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: On combining permutations and substitutions in encryption
Date: 4 Feb 2001 18:36:53 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Douglas A. Gwyn wrote:
>Actually I don't pay much attention to asymptotic complexity
>theory since it is rarely if ever applicable to real crypto
>systems.
Fair enough.
Although, in defense of asymptotic complexity theory, its proofs can
almost always be turned into non-asymptotic results (concrete security)
without too much work. In this case, removing the asymptotics shows
that if you can build a fast 3SAT solver (for appropriate values of fast),
you can probably crack most ciphers of practical interest.
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: PGP Crack
Date: Mon, 05 Feb 2001 02:59:07 +0800
[EMAIL PROTECTED] wrote:
>
> I was curious, does anyone have a good layman's explanation of the
> recent PGP Crack that was discovered.
>
> I mean was it intentionally placed there by Network Associates? How does
> (or did) it work. I can't find too much information on it.
If you mean the ADK problem, my understanding of it was that it arose
from an attempt to add something approximating key escrow to PGP.
Additional Decryption Keys (ADK's) are extra keys tagged to someone's
public key which should be signed by the key's owner, and PGP interprets
these as additional recipients to which the sender can optionally send
the same message to encrypted with the ADK(s). Trouble was, PGP
versions 5.5 through 6.5.3 didn't properly check the signatures on these
ADK's, so anyone could add unauthorized ADK's to your public keys.
Since most people give as little thought to security as they can get
away with, the dialog box about the presence of ADK's may have been
calmly pressed 'OK' on, and the same message sent encrypted both to the
true recipient and the malicious attacker who put the phony ADK there in
the first place. A thorough description of the bug by Phil Zimmermann
is here
http://www.pgpi.org/files/prz-adk.txt
Phil denies that it was added because NSA convinced them to add a back
door to PGP. I'll leave it to the Lone Gunmen on sci.crypt to debate on
whether or not he should be believed.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PGP Crack
Date: Sun, 04 Feb 2001 19:46:11 GMT
Yes, ADK was the term. Thanks, and any further information would be
greatly appreciated.
-Jeff
In article <gX5f6.4209$[EMAIL PROTECTED]>,
"Michael Brown" <[EMAIL PROTECTED]> wrote:
> You mean the ADK problem?
>
> <[EMAIL PROTECTED]> wrote in message
news:95in0c$8ld$[EMAIL PROTECTED]...
> > I was curious, does anyone have a good layman's explanation of the
> > recent PGP Crack that was discovered.
> >
> > I mean was it intentionally placed there by Network Associates? How
does
> > (or did) it work. I can't find too much information on it.
> >
> > -Jeff
> >
> >
> > Sent via Deja.com
> > http://www.deja.com/
>
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: On combining permutations and substitutions in encryption
Date: Sun, 04 Feb 2001 20:05:14 GMT
On 4 Feb 2001 11:49:48 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>[EMAIL PROTECTED] (Terry Ritter) wrote in <[EMAIL PROTECTED]>:
>
>...
>
>>
>>Known-plaintext is one of the most damaging information conditions,
>>specifically because it can immediately expose a complete ciphering
>>transformation.
>>
>>For the emulated huge simple substitutions we call conventional block
>>ciphers, known-plaintext generally does expose one element from the
>>emulated table.
>>
>>For classic simple XOR stream ciphers, known-plaintext immediately
>>exposes the confusion or keying sequence, which then allows that
>>sequence to be attacked.
>>
>>But for Dynamic Transposition, known-plaintext does *not* immediately
>>expose any particular permutation, because many different permutations
>>can produce that same transformation. This is an advantage. How big
>>that advantage is, obviously depends.
>>
>>However, I would say that Dynamic Transposition is not "complex," but
>>is instead far clearer in concept than any Feistel cipher.
>>
>
> Terry "wrapped PCBC" also is designed to "not immediately expose"
>any particular permutation. But it also allows data to mix through
>the whole file not just in the forward direction.
Actually, it does.
We need to compare ciphers of similar type for the description to have
a similar meaning. I see SCOTT-type ciphers as "Variable-Size Block
Ciphers (VSBC's)," the operative words being: "Block Cipher."
We assume that the known-plaintext attack provides the plaintext file
and the ciphertext file. That defines one transformation in the
emulated huge Simple Substitution which is the block cipher, even for
SCOTT-type ciphers. I don't know that the information is particularly
helpful, but the transformation *is* exposed.
The issue becomes more interesting when we have a "small" block
cipher, but not because we hope to accumulate enough transformations
to decipher anything we see. Instead, if we have even a small number
of such transformations, very few keys could produce that set, which
minimizes or removes key uncertainty -- if only we could solve the
cipher transformations. Presumably, this is the unicity distance,
which, in "small" (which is to say, conventional) block ciphers,
should be fairly short.
The issue is just different with respect to Dynamic Transposition
ciphers. Because many different permutations can produce the exact
same transformation from plaintext to ciphertext, there is no one
permutation result which might lead back to a particular sequence by
which one could attack the RNG. And since Dynamic Transposition
creates a new permutation for each block, known-plaintext never
provides information to distinguish which particular permutation was
actually used for any block. This is different from completely
revealing a particular transformation, even if that which is revealed
is only one from among a multitude.
Now, it can reasonably be argued that knowing the different subsets of
permutations -- as revealed by known-plaintext -- do in fact deliver
some information about the RNG state. I argue that this is different
in practice from a block cipher, in which the fundamental concept of
enciphering -- an emulated huge simple substitution -- is directly
addressed by unicity distance. In practice, since we cannot search
the keyspace, we have to instead find some logical relationship from
key to result. In a normal block cipher, that is the ciphering
rounds, which are directly connected to the key. No additional levels
of protection are involved. In a Dynamic Transposition block cipher,
the relation is from the linear RNG, through sequence nonlinearity,
through shuffling itself (which discards information) and the
double-shuffle (which hides the RNG sequence), and only then to the
ultimate permutation which affects the data. That is the sense in
which I meant that the attack computation should be more complex with
Dynamic Transposition, even though I see the ciphering process itself
as being much clearer.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
