Cryptography-Digest Digest #33, Volume #12 Thu, 15 Jun 00 07:13:00 EDT
Contents:
Re: Cipher design a fading field? ("Douglas A. Gwyn")
Re: Another beginner question (Benjamin Goldberg)
Re: Double Encryption Illegal? (Miguel Cruz)
Re: Comments/analysis requested: stream cipher derived from hash (David Hopwood)
Re: On using compression as proper means of encryption (SCOTT19U.ZIP_GUY)
Re: Diffie's New directions in Cryptography ([EMAIL PROTECTED])
Re: Double Encryption Illegal? (jkauffman)
Re: Threshold Schemes. (Simon Johnson)
Re: Another beginner question (Simon Johnson)
Re: Another beginner question (Simon Johnson)
Re: Is Gretchen down? (Vernon Schryver)
Re: On using compression as proper means of encryption (Guy Macon)
Re: Cipher design a fading field? (Mok-Kong Shen)
Re: Cipher design a fading field? (Mok-Kong Shen)
Re: Comments/analysis requested: stream cipher derived from hash function (SHA-1)
(Tim Tyler)
Re: Cipher design a fading field? (Benjamin Goldberg)
Re: Comments/analysis requested: stream cipher derived from hash (David Blackman)
Re: Random sboxes... real info (Tim Tyler)
Re: Cipher design a fading field? (Tim Tyler)
Re: Can we say addicted? (Tim Tyler)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Thu, 15 Jun 2000 06:10:42 GMT
"Trevor L. Jackson, III" wrote:
> ... some of it was simply incorrect, such as epicycles, ...
Certainly, before science was discovered, there was ignorance.
One would hope that we can do better now that we have learned
to think better. My point against skepticism is, just because
we don't yet know *every*thing doesn't mean that we currently
don't know *any*thing.
(Epicycles were not "incorrect", but were an overly complex
development of a theory founded on a suboptimal premise that
seemed rooted in common sense. It took development of better
theories, particularly of universal gravitation, to supplant
the older theory with a simpler one that explained the
observed facts.)
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Another beginner question
Date: Thu, 15 Jun 2000 06:21:29 GMT
Cheri & Mike Jackmin wrote:
>
> Consider a simple cipher in which SHA-1 (or a similar message digest)
> was used to generate a series of key blocks from the preceding
> ciphertext. How would this cipher be vulnerable?
>
> For example, suppose I want to encrypt a message of arbitrary length.
> I take user's the password, run it through SHA-1 to produce a 128 bit
> key, and XOR this key against the first 128 bits of the message to
> produce my first block of ciphertext. I then take this block of
> ciphertext, run it through SHA-1 to generate my next 128 bits of key,
> and so on.
>
> Since I have never heard of this method being used, I have to assume
> it has some sort of weakness which renders it unsuitable.
>
> This approach is appealing because it would be so easy to implement
> and to test, but the primary reason for my question is just a nagging
> curiosity; I honestly can't even guess as to why this method wouldn't
> be secure, but I'm sure you folks could spot the flaw right away.
The problem with the method becomes obvious if you write it
symbolically.
CT[1] = PT[1] xor H( password )
CT[i] = PT[i] xor H( CT[i-1] )
Once I have a block of ciphertext (call it CT[N]), I can find PT[N+1]
by simply doing H(CT[N]) xor CT[N+1]. The only block that's secure
is the first one. An improved method would be something like the
following:
CT[1] = PT[1] xor H( password, IV )
CT[i] = PT[i] xor H( password, CT[n-1] )
Where IV is an initialization vector. There is a name for this kind
of block chaining, but I forget what it is [Output Feedback Mode, I
*think*, but I'm not sure]. Here's a slightly better method, which
doesn't require keeping the password anywhere in memory:
K = H( password, IV )
CT[1] = PT[1] xor H( K )
CT[i] = PT[i] xor H( K, CT[n-1] )
It's effectively the same, except that if someone manages to steal the
K value, only that one stream of data is compromised, not all streams
created with that password ( remember that K is different with each
stream, and because H is cryptographically secure, it cannot be used
to find the password [we hope] ).
Note that if you're using *just* using a password as the key, you had
better be using one with *lots* of entropy... I'd suggest using a
multi-word, arbitrary-length password, brobably generated with something
like diceware (I think that's what it's called).
------------------------------
Crossposted-To: comp.databases.oracle
Subject: Re: Double Encryption Illegal?
From: [EMAIL PROTECTED] (Miguel Cruz)
Date: Thu, 15 Jun 2000 06:38:53 GMT
Simon Johnson <[EMAIL PROTECTED]> wrote:
> They can't *prove* you used the algorithm on a piece of data
> twice without brute-forcing double the key-space of the
> encrypting algorithm.
They can look at your source code.
miguel
------------------------------
Date: Thu, 15 Jun 2000 06:05:36 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Comments/analysis requested: stream cipher derived from hash
=====BEGIN PGP SIGNED MESSAGE=====
David Hopwood wrote:
> > Iterative step (generate the next N bits of output):
> >
> > Output[i] = S1[i] xor S2[i]
> > S1[i+1] = hash(S1[i]: S2[i])
> > S2[i+1] = hash(S2[i]: S1[i])
>
> If S1[i] is ever equal to S2[i], the output after that point will lock to
> all-zeroes. The probability of that happening at each iteration is 2^-N,
> so the expected number of iterations before it happens is on the order
> of 2^(N/2).
Sorry, this is wrong - the expected number of iterations is on the order
of 2^N.
The rest of my article is OK despite this mistake, though (I still
think it's a good idea for the hash functions to have distinct inputs,
for instance.)
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOUhjxDkCAxeYt5gVAQFgxQgAu/sD5jxDhYEhN8/L5AuxxrxQlcQD8WHw
lBiLN8rJfyd0zwgOQw0dtX/FBMQQaiwclPbXABBk36lWzUANHP4u6wJPfS73S04g
7aS5FVKbimPvYPvVdjprk57ZvMw51NqwdZ7km+MPYuptKiP0NF7ZAL/hSBig1Hul
2gSfManKOligrpoVxb1qtwu5Mco8Iyas0duX7bEGjCA9oTWLtcMMM+Hn42rjA9St
aaxpxR/m9IxkrXxwoNBqltqaZBDaWyEEa8n4h+a+axkO0ZB/hvUp5TARr7fisHVW
Y7tvljEIVHzPoIk87efCNa481niO081l8YDdd09DrQcj0sfF6taT7g==
=5aJe
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: On using compression as proper means of encryption
Date: 15 Jun 2000 07:42:02 GMT
[EMAIL PROTECTED] (David Hopwood) wrote in
<[EMAIL PROTECTED]>:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Mok-Kong Shen wrote:
>[snip]
>> Use a PRNG (crypto strength unessential) with a key as
>> seed to generate a sequence of symbols (length of sequence
>> determined by PRNG) to initialize an adaptive Huffman
>> compression algorithm, taking care that all symbols of the
>> plaintext alphabet are input at least once. The output in
>> this initialization phase is discarded. Then start feeding
>> symbols of the plaintext into the algorithm. Use the result
>> as ciphertext. Decryption amounts to a corresponding
>> decompression after doing the same initialization.
>
>This is very weak. It amounts to no more than a simple
>substitution on variable-length symbols. Frequency analysis
>can be applied almost as easily to variable-length symbols as
>it can to fixed-length symbols.
>
I am not saying it is as strong as scott19u.zip but
it is very hard to try to do frequency analysis on variable
length symbols. Becasue with out a tree you do not know
where one symbol starts and one symbol ends. Obviously
you haven't given this much thought.
http://members.xoom.com/ecil/compress.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Diffie's New directions in Cryptography
Date: Thu, 15 Jun 2000 07:48:15 GMT
>
> It's reprinted in "Contemporary Cryptology" (IEEE Press, edited by
> Gus Simmons) and in many other places too. It's a classic paper, well
> worth reading.
>
I would prefer an online copy. Can you give me the url?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: jkauffman <[EMAIL PROTECTED]>
Subject: Re: Double Encryption Illegal?
Crossposted-To: comp.databases.oracle
Date: Thu, 15 Jun 2000 00:46:16 -0700
In article <1S_15.351$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Miguel Cruz) wrote:
> Simon Johnson
> <[EMAIL PROTECTED]> wrote:
> > They can't *prove* you used the algorithm on a piece
> of data
> > twice without brute-forcing double the key-space of
> the
> > encrypting algorithm.
> They can look at your source code.
> miguel
not really, you don't change the source you just run it
twice.
* Sent from AltaVista http://www.altavista.com Where you can also find related Web
Pages, Images, Audios, Videos, News, and Shopping. Smart is Beautiful
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Threshold Schemes.
Date: Thu, 15 Jun 2000 08:30:55 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (James Pate Williams, Jr.) wrote:
> On Wed, 14 Jun 2000 21:36:16 GMT, Simon Johnson
> <[EMAIL PROTECTED]> wrote:
>
> >Thanxs, But i'm after the math to do it, not the algothims..... I
aint
> >go time to *decipher* the code :p
> >--
> >Hi, i'm the signuture virus,
> >help me spread by copying me into Signiture File
> >
> >
> >Sent via Deja.com http://www.deja.com/
> >Before you buy.
>
> If you tried looking at the program that has a reference to Schneier's
> book in the opening comments you would see that a form of the
> algorithm requires the extended Euclidean algorithm for calculating
> the inverse of a number modulo another number. Also, you can
> use Gaussian elimination. Another program shows the method using
> Lagrange's interpolation formula. See the _Handbook of Applied
> Cryptography_ by Alfred J. Menzes et al. 12.71 Mechanism page 526.
>
> ==Pate Williams==
> [EMAIL PROTECTED]
> http://www.mindspring.com/~pate
>
>
Sorry, i'll look at your code with more details :)
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Another beginner question
Date: Thu, 15 Jun 2000 08:56:47 GMT
What you propose should be okay, but you can't use the same key twice
because the cipher isn't text an key dependent. Basically, if you have
two files encrypted with the same key, you can XOR the two and remove
the key-stream. Now you can simultaneously crack both messages by
character frequency analysis.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Another beginner question
Date: Thu, 15 Jun 2000 09:01:25 GMT
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, "Cheri & Mike
> Jackmin" <[EMAIL PROTECTED]> wrote:
> >
> >Consider a simple cipher in which SHA-1 (or a similar message
> digest)
> >was used to generate a series of key blocks from the preceding
> >ciphertext. How would this cipher be vulnerable?
> >
> >For example, suppose I want to encrypt a message of arbitrary
> length.
> >I take user's the password, run it through SHA-1 to produce a
> 128 bit
> >key, and XOR this key against the first 128 bits of the message
> to
> >produce my first block of ciphertext. I then take this block of
> >ciphertext, run it through SHA-1 to generate my next 128 bits
> of key,
> >and so on.
>
> Well if I have a block of ciphertext I can find the rest of the
> plaintexts... For example
>
> K = 128 bit key
>
> P1 = plaintext
> C1 = P1 xor H(K)
> K = C1
>
> repeat as required...
>
> I just need C1 now to find P2 from C2..
>
> Tom
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion
Network *
> The fastest and easiest way to search and participate in Usenet -
Free!
>
>
Hey, i thought the author of this post was suggesting the following,
where y_0 is the key:
p = plain-text
For the i'th block
y_i=H(y_i-1)
C=p ? y_i
I don't know, maybe i'm wrong :p
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Crossposted-To:
alt.security.pgp,comp.security.firewalls,alt.privacy.anon-server,alt.privacy
Subject: Re: Is Gretchen down?
Date: 14 Jun 2000 19:11:55 -0600
In article <e2Vv1sk1$GA.323@cpmsnbbsa07>,
Joseph Ashwood <[EMAIL PROTECTED]> wrote:
> ...
>They would be forced to have a vampire on each of the major backbones, or at
>least the ones with anything of interest. It would be a massive undertaking,
>cost a hundred million dollars or so (just a very rough guess), but it is
>possible. ...
The academics who have installed measuring devices on major backbones
haven't spent a noticeable fraction of $100M. If all you need to do is
capture all of a few packets matching some easy criteria such as IP
addresses, port numbers, an interesting pattern or checksum of all or part
of the rest of the packet from fiber running at a bunch of GBytes/sec,
then you need only a little, cheap fancy hardware and a cheap PC.
See for example http://www.cetp.ipsl.fr/~porteneu/inet98/6g/6g_3.htm
Yes, that hardware doesn't look at payloads, but consider the
possibilities. That it is smart enough to track all flows
active at a given instant
To put it another way, if you can build, sell, or buy a router that takes
the IP source and destination addresses, IP protocol number, TCP or UDP
port number, IP QOS bits, and perhaps a few other things, does some
computing including looking the values up in table with at least 100,000
and perhaps 1,000,000 entries, and then ship the packet to a destination
based on all of that, and run at Tbit/sec, then what's the big deal about
making one of those destinations be a recording device fast enough to
capture all of the SMTP traffic to and from a few 100 large hosts?
In case, you haven't be paying attention to the market, competitive
TBit/sec IP routers do all of that computing and table looking, and
1,000,000,000,000 bit/sec speeds (aggregate among its up to OC-192 links).
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: On using compression as proper means of encryption
Date: 15 Jun 2000 05:28:06 EDT
Mok-Kong Shen wrote:
>
>
>
>
>Anton Stiglic wrote:
>
>> My I suggest something to you?
>>
>> You seem to have allot of ideas, which might be interesting,
>> but the posts in which you express does ideas are very
>> lengthy. Personally, I haven't read one of them because I
>> don't want to spend that much time. It would be nice if
>> you could go straight to the fact and express your ideas.
>> If something is missing, someone will ask you.
>
>Many thanks for your suggestion. I'll take heed to avoid
>things that really could be cut. However, I am of the humble
>opinion that presentation of motivations or some historical
>backgrounds is just as essential for the majority of readers as
>explanation of the bare and dry 'kernel' of an article. Anyway,
>in journal publications it is commonplace to have an introduction
>section illustrating why one wants to deal with a certain topic and
>what has already been done on that, etc. etc.
Ever notice what comes before the presentation of motivations or
historical background in those journals? It's called an abstract.
I personally prefer your present, longer format. Putting the point
at the top would help Anton - see the style in your local newspaper.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Thu, 15 Jun 2000 11:48:58 +0200
John Savard wrote:
> Well, if the size of the RAM available to a program is limited, not
> just the size of the program itself, then a program with N bits of
> storage available to it can have only 2^N distinct states. Hence, if
> it doesn't halt after 2^N instructions, it is proven that it will
> never halt.
You probably mean that execution of each intruction must lead to a
single unique successor state. How about the case that this doesn't
hold, i.e. when the state transition depends on the history?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Thu, 15 Jun 2000 11:49:04 +0200
wtshaw wrote:
> Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
>
> > Could you give a pointer to your 3-way? Thanks.
>
> I can give a simple explanation here as to how it generally works:
>
> Consider in a base 26 set, A=0 and Z=25 for both Ct and Pt and key.
> Depending on the historic algorithms, the following are true, at least in
> common current usage, for the current letters:
>
> Beaufort: Pt + Ct = K mod 26
>
> Variant: Ct + K = Pt mod 26
>
> Vigenere: Pt + K = Ct mod 26
>
> In the implementation, sensing the current changable mode, K, P, or C,
> direct the logic to the proper derived equation to get Ct in encryption,
> or Pt in decryption. The mode key might be kpc which means the mode used
> for processing will cycle, and this is independent of the key letters in
> the keystring, which might be of a different number than those in the mode
> key.
Thanks. I see you are in fact using multiple encryption (not in series
with a stack but switching among algorithms) and the idea is related
to my recent thread 'On dynamic random selection of encryption
algorithms'.
M. K. Shen
------------------------------
Crossposted-To: sci.crypt.random-numbers
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Comments/analysis requested: stream cipher derived from hash function
(SHA-1)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 15 Jun 2000 10:13:41 GMT
In sci.crypt.random-numbers tomstd <[EMAIL PROTECTED]> wrote:
: An even better idea is to maintain a counter.
Counter-based schemes allow backtracking. Avoiding this seemed to be the
point of the design.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Breast is best.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Thu, 15 Jun 2000 10:45:54 GMT
Mok-Kong Shen wrote:
>
> John Savard wrote:
>
> > Well, if the size of the RAM available to a program is limited, not
> > just the size of the program itself, then a program with N bits of
> > storage available to it can have only 2^N distinct states. Hence, if
> > it doesn't halt after 2^N instructions, it is proven that it will
> > never halt.
>
> You probably mean that execution of each intruction must lead to a
> single unique successor state. How about the case that this doesn't
> hold, i.e. when the state transition depends on the history?
That would require allocating memory each time data is added to the
history, wouldn't it?
------------------------------
From: David Blackman <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Comments/analysis requested: stream cipher derived from hash
Date: Thu, 15 Jun 2000 20:46:28 +1000
Tim Tyler wrote:
>
> In sci.crypt.random-numbers tomstd <[EMAIL PROTECTED]> wrote:
>
> : An even better idea is to maintain a counter.
>
> Counter-based schemes allow backtracking. Avoiding this seemed to be the
> point of the design.
How do you backtrack with Tom's method? It looked about as hard as
breaking SHA-1 to me. (Provided the random seed is kept secret.)
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random sboxes... real info
Reply-To: [EMAIL PROTECTED]
Date: Thu, 15 Jun 2000 10:29:10 GMT
David A. Wagner <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
:> David Hopwood <[EMAIL PROTECTED]> wrote:
:> : In fact, a method for selecting a permutation uniformly at random
:> : from that space would be as secure as a keyed permutation (a.k.a.
:> : block cipher) of that size can possibly be.
:>
:> That last seems questionable. The space of all possible permutations
:> contains the identity transformation - which is not strong.
: Nonsense. That's on par with the following popular fallacy:
: Myth: "the all-zeros key is a weak key for the one-time pad
: (because it acts as the identity transformation), and
: so the one-time pad can be strengthened if you exclude
: the all-zeros key."
: Such reasoning is pure balderdash. The myth is, of course, false.
Oh dear. I seem to have caught David while he's having a dream ;-)
It is not on par at all! You're comparing my (sensible) idea to some
complete and utter nonsense!
An OTP is used once. A block cypher may potentially be used to encypher
*many* blocks. If the permuting transform used is the identity
transformation, the analyst is likely to notice this at once in (say) ECB
mode. The cyphertext *is* the original plaintext. *No* other permutation
would have this effect over a number of blocks of differnet plaintext.
Whereas if the all-zero key is used in an OTP the analyst has no way of
knowing that. There are *many* such keys that will produce plausible
messages - and the analyst has no way of knowing which is being used.
The identity transformation *is* weak. It has zero diffusion and zero
confusion. It's hopeless as a method of cryptography. That much should
be obvious.
The reason nobody cares about it happening in designs that try to
simulate random permutations is that the chance of hitting on it is
so small - *not* because it's *acutally* as strong as your average
random permutation.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ UART what UEAT.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 15 Jun 2000 10:41:09 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Indeed, there are numerous examples of small programs for which we
: do not know whether or not they will halt. One cannot count on
: determining this by executing the program.
Of course not.
However the original question was "if program size is bounded, does the
halting problem exist for that set of programs?"
There exists a finite program that correctly states whether each program
in such a space will terminate.
If there were a halting problem, no such program could possibly exist.
The halting problem relates to the *existence* of such a program -
without consideration of any difficulties in actually finding it.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Breast is best.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Can we say addicted?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 15 Jun 2000 10:51:46 GMT
tomstd <[EMAIL PROTECTED]> wrote:
: <[EMAIL PROTECTED]> wrote:
:>http://www.terracom.net/~ereserch/float/movie and
:>http://www.terracom.net/~ereserch/float/movie2
: Dude I got a four-oh-four.
The correct URLs are:
http://mendota.terracom.net/~eresrch/float/movie/
http://mendota.terracom.net/~eresrch/float/movie2/
I still can't help thinking Mike should try some bigger doses ;-)
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ VIPAR GAMMA GUPPY.
------------------------------
** 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
******************************
