Cryptography-Digest Digest #486, Volume #12 Sat, 19 Aug 00 13:13:01 EDT
Contents:
Crypto 2000: share ride SF bay area to Santa Barbara? (Paul Rubin)
Re: Looking for a DES or RSA chip with write-only key. (Benjamin Goldberg)
Re: Java Random Numbers (Tim Tyler)
Re: 1-time pad is not secure... (Guy Macon)
Re: 1-time pad is not secure... (Tim Tyler)
Re: Breaking Simple XOR Encryption (Peter)
Re: 1-time pad is not secure... (Tim Tyler)
Re: Breaking Simple XOR Encryption (Tim Tyler)
Re: Just a thought... (Tim Tyler)
Re: Intermittent stream cipher? (John Savard)
Re: Intermittent stream cipher? (John Savard)
Re: Intermittent stream cipher? (Dave Hazelwood)
Re: New quantum computer - any details? (Sander Vesik)
Re: an attack for stream ciphers ("Scott Fluhrer")
Re: Intermittent stream cipher? (Mok-Kong Shen)
Re: Intermittent stream cipher? (wtshaw)
Re: Intermittent stream cipher? (wtshaw)
Re: DES: Say it or spell it? (Newbie question) (Sander Vesik)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Crypto 2000: share ride SF bay area to Santa Barbara?
Date: 19 Aug 2000 07:37:39 GMT
Anyone want to drive down? I had something set up, but it fell through.
Paul
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Looking for a DES or RSA chip with write-only key.
Date: Sat, 19 Aug 2000 08:31:08 GMT
Paul Rubin wrote:
>
> In article <[EMAIL PROTECTED]>,
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> >[WARNING: place coffee cup firmly on the table to avoid making mess]
> >
> >Mark Currie wrote:
> >>
> >> I would not recomend *burning-in* of keys. The Pijnenburg chips -
> >> PCC101 (DES) & PCC201 (Exponentiator) have write-only key registers
> >> that (I think) can be retained with a battery after power-down.
> >[snip]
> >
> >Surely you don't *really* mean "write-only", do you?
>
> Yes, write-only. That's normal. You can write keys into the
> registers but not read them back. The chip also supports encryption
> operations using the keys you have written, but does not give you
> direct access to the key registers after the keys are loaded.
Obviously the sarcasm passed over your head. Lookup write-only memory
in the New Hacker's Dictionary, which is available at MANY places. The
first one I found using http://www.google.com/ to search was at
http://www.tuxedo.org/~esr/jargon/ and the particular definition is
http://www.tuxedo.org/~esr/jargon/html/entry/write-only-memory.html
--
"There's a mathematical reason not to trust Christians... The Buddhists
believe that human lives repeat. The atheists believe that human lives
terminate. That means that the Christians must believe that humans are
irrational."
- Matt Katinas
"Not necessarily... they could think that humans are imaginary."
- Rob Pease, in response to the above
"Of course Christians think humans are irrational: They believe humans
are transcendental, and all transcendentals are irrational. I suppose
that all we can be certain of is that humans are complex."
- Me, in response the the above
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Java Random Numbers
Reply-To: [EMAIL PROTECTED]
Date: Sat, 19 Aug 2000 09:28:18 GMT
Scott Fluhrer <[EMAIL PROTECTED]> wrote:
[Java RNG]
: It looks like it has a few bugs. In particular, I believe that char's
: in Java are always 8 bits, and so anytime you try to store something in
: the "upper 8 bits", it gets lost.
In this you are mistaken - "char"s in Java are unicode characters - 16-bit.
The normal 8-bit datatype in Java is called a "byte".
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: 1-time pad is not secure...
Date: 19 Aug 2000 10:10:06 GMT
Douglas A. Gwyn wrote:
>
>Tim Tyler wrote:
>
>> However, this all seems rather a long way from OTPs. Without a good
>> method getting macroscopic measured events from quantum phenomena, in
>> the face of opposition from ones' opponents, discussion of quantum
>> theory seems rather irrelevant.
>
>I don't know why you continue to maintain that there is no
>"good method of getting macroscopic measured events from
>quantum phenomena". Even a simple scintillation chamber
>demonstrates the contrary.
I analysed one method and calculated an upper bound to the
possible amount of bias. Tim Tyler accepted my analysis
(with the exeption of the case wher a sophisticated attacker
can replace all of my hardware and also could hypnotize me).
Now he is back to making the same claim that I refuted. Sigh.
Memetic Infection. No doubt about it.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Reply-To: [EMAIL PROTECTED]
Date: Sat, 19 Aug 2000 09:48:34 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Guy Macon wrote:
:> Tim Tyler wrote:
:> >To *ignore* these (as, for example Bruce Scheiner does in AC when he
:> >writes "Beleive it or not there's a perfect encryption scheme." - p.15,
:> >2nd ed.) is not sensible.
:>
:> Whenever I find that my reasoning in an area where I am not an expert
:> leads me to the conclusion that standard textbooks on the subject are
:> wrong, I take the possibility that it is my reasoning that is wrong
:> much more seriously than yoy seem to. You should think about that.
: Good advice. Even the most respected authors do make occasional
: mistakes, but not nearly as readily as the typical reader.
: A perfect *scheme* can exist without ever being perfectly
: *realized*.
In a sphere where perfection is not even known to be possible, "perfect"
is probably misleading word.
Schneier goes on to say:
``[..] the caveat, and this is a big one, is that the key letters have to
be generated randomly. Any attacks against this scheme will be against
the method used to generate the key letters. Using a pseudo-random
number generator doesn't count; they have nonrandom properties. If you
use a real random source - this is much harder than it might first
appear, see Section 17.14 - it's secure".
There are plenty of other things that tarnish the OTP as a
"perfect encryption scheme" - it suffers from severe key distribution
problems, and a total lack of plaintext diffusion.
I guess Schneier just wanted a snappy headline.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Peter <[EMAIL PROTECTED]>
Subject: Re: Breaking Simple XOR Encryption
Date: Sat, 19 Aug 2000 10:21:22 GMT
Thanks for the informative replies.
Douglas, you said ,"For learning cryptanalysis in general, there are
better texts than Schneier's.". Could you please recommend some such
texts.
Joe, you said "You can find the length, or period, of the key by the
Kasiski method or by the Index of Coincidence that Schneier talks
about." Can you provide me with some references re "Index of
Coincidence" and the "Kasiski Method".
Thanks
Peter
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Reply-To: [EMAIL PROTECTED]
Date: Sat, 19 Aug 2000 10:06:47 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> You don't have any basis for the claim that there are no initial
:> conditions. What you have is ignorance of any relevant initial
:> conditions. This is not necessarily the same thing.
: You're actually talking about hidden variables, not initial
: conditions (which has a different, formal meaning).
I was discussing the previous poster's claim - which explicitly
referred to initial conditions.
: [..] the current state of physical knowledge about irreducible
: randomness is that it is *different in kind* from the simple
: lack of knowledge of details underlying classical sources of
: apparent randomness. [...]
I would agree with this.
: A fundamental unknowability is not the same as an accidental lack of
: knowledge about something that is in principle knowable.
I agree with this as well - although it is not known to be relevant to
the case in question.
: The difference in character leads to different mathematical properties.
: That difference has been empirically confirmed, so we *know* that the
: underlying randomness is irreducible. [...]
No we don't. Empirical confirmation has only gone so far. Equally well,
19th century observation would have "confirmed" that Brownian motion
was random. Any attempt to state that observations suggested that no
lower-level deterministic processes were responsible for Browniam
motion would - in that instance - have been mistaken.
: That is not an assumption, it is a conclusion.
*Your* conclusion, and one which does not appear to follow from the known
information.
At the risk of repeating myself, you /can't/ conclude that a source is
genuinely random by an experimental process. You can only conclude that
something is /not/ random - in the case where you are able to make useful
predictions about its behaviour.
If after /much/ effort, you fail to find any non-randomness, that might be
suggestive - but it's hardly conclusive.
:> However, this all seems rather a long way from OTPs. Without a good
:> method getting macroscopic measured events from quantum phenomena, in
:> the face of opposition from ones' opponents, discussion of quantum
:> theory seems rather irrelevant.
: I don't know why you continue to maintain that there is no
: "good method of getting macroscopic measured events from
: quantum phenomena". Even a simple scintillation chamber
: demonstrates the contrary.
It does not. Such a device has not been demonstrated to be immune
from interference from environmentaol factors - especially not when
the "environmental factors" include the active opponents I mentioned.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Breaking Simple XOR Encryption
Reply-To: [EMAIL PROTECTED]
Date: Sat, 19 Aug 2000 10:15:34 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Peter wrote:
:> I would appreciate an explanation of the attack that is
:> used against simple XOR "encryption" schemes.
: The first thing to understand is that XOR is *not* an
: encryption scheme, nor a class of such schemes; it is
: just a primitive Boolean-logic operation that has many
: uses, including as a *component* in some encryption
: schemes (but not in others). Knowing that XOR was used
: in a scheme does not tell one nearly enough to make use
: of that information.
: Different cryptanalytic attacks are applied against
: different encryption schemes. I don't have a copy of
: Schneier's book at hand at the moment and thus I don't
: know which *specific* method he was talking about.
1.2.3 of Schneier (1994) turns into 1.4 in Schneier (1996).
``The simple-XOR algorithm is really an embarassment; it's nothing more
than a Vigenere polyalphabetic cipher [...] The plaintext is being XORed
with a keyword to generate the ciphertext.''.
He goes on to discuss frequency analysis to determine the length of
the password, by a coincidence counting method, and XORing the cyphertext
with itself shifted sideways by this size - to eliminate the key bits,
and leave a relatively simple function of the original plaintext.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Just a thought...
Reply-To: [EMAIL PROTECTED]
Date: Sat, 19 Aug 2000 10:19:09 GMT
Simister, Shawn [SKY:0000:EXCH] <[EMAIL PROTECTED]> wrote:
: I've been wondering whether it would be viable to create an encryption
: algorithm whose strength would be based upon the fact that it could
: only be broken by a brute force attack [...]
How do you arrive at this "fact", when applied to the algorithm in question?
That the best attack is brute force is more often a hypothesis than a fact.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Intermittent stream cipher?
Date: Sat, 19 Aug 2000 13:23:40 GMT
On Fri, 18 Aug 2000 15:37:18 -0400, "mconroy" <[EMAIL PROTECTED]>
wrote, in part:
>I would like to know where I might find a cipher algorithm that allows me to
>stream plaintext input on an intermittent basis. The application is logging
>messages to a file which must be encrypted.
Actually, any type of block cipher mode will do that, if you save the
complete state between encryptions. But cipher programs like mcrypt
wouldn't be set up to do this.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Intermittent stream cipher?
Date: Sat, 19 Aug 2000 13:22:27 GMT
On Fri, 18 Aug 2000 15:37:18 -0400, "mconroy" <[EMAIL PROTECTED]>
wrote, in part:
>This happens regardless of the mode I choose.
>(which may, in fact, be a problem with mcrypt).
Does it let you choose ECB mode? If so, it's a problem with mcrypt.
What is needed is that each record is encrypted with its own key (for
security), and the individual records are visible, for each one to be
independently encrypted or decrypted. That may leak important
information.
And what about the index to the file? That would have to be encrypted
and decrypted as a whole each time if it is encrypted.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Dave Hazelwood <[EMAIL PROTECTED]>
Subject: Re: Intermittent stream cipher?
Date: Sat, 19 Aug 2000 23:24:47 +0800
On Fri, 18 Aug 2000 18:16:30 -0700, "Scott Fluhrer"
<[EMAIL PROTECTED]> wrote:
>
>Darren New <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> > I would like to know where I might find a cipher algorithm that allows
>me to
>> > stream plaintext input on an intermittent basis. The application is
>logging
>> > messages to a file which must be encrypted. The file has to remain
>> > encrypted at all times.
>>
>> Why not just use something like RC4. To add a line, run the generator thru
>> as many bytes as you already have in the file, and then pick up the stream
>> from there? If your log file is 3000 bytes long now, run RC4 for 3000
>bytes
>> (or 3000+256, or whatever) and then start using the output to xor with the
>> new message?
>
>That has the problem that, if the log file gets large, you end up running
>RC4 a lot to get to the right state. If your log file is one megabyte, you
>generate one megabyte of RC4 output to append a single line. What would
>make more sense is to take a block cipher and run it in counter mode. That
>is, divide the file up into N byte chunks (where N is the block size: 8 for
>blowfish and 16 for twofish), and for each chunk, take the offset of that,
>encrypt it, and xor the resulting ciphertext into your data to form the
>value to store. To store an additional line, all you need to do is generate
>the ciphertext that corresponds to the blocks the new line takes up.
So what is the overhead of a megabyte of RC4 output ? A split
fraction of a second ? Or less ?
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: Sander Vesik <[EMAIL PROTECTED]>
Subject: Re: New quantum computer - any details?
Date: 19 Aug 2000 14:28:46 GMT
Bill Unruh <[EMAIL PROTECTED]> wrote:
> In <[EMAIL PROTECTED]> Sander Vesik <[EMAIL PROTECTED]>
>writes:
>>How long is 'realistical length' and what constitutes a practical
>>quantum computer? A qc that can crack say 512 bit RSA in say 4 weeks
>>is practical, but not overly threatening for 16/32 kbit keys that are
>>still realistically long.
> If, it could solve a 512 bit key in 4 weeks, it would take a few months
> for a 1024 bit key, etc.
> HOwever no quantum computer is anywhere near even 10 bits yet.
Working and running a "useful algorithm" - 5 qubits. Largest existing -
7 qubits. So we are near 10 qubit and imho will have a working 10 qubit
one at the latest in a year or so.
--
Sander
FLW: "I can banish that demon"
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: an attack for stream ciphers
Date: Sat, 19 Aug 2000 09:04:03 -0700
<[EMAIL PROTECTED]> wrote in message
news:8n7uhh$7tc$[EMAIL PROTECTED]...
> Here is another technique for attacking stream ciphers (such as RC4,
> Solitaire, et cetera): Given a partial solution, fill in the rest
> of the solution a few different random ways and look for biases in the
> results generated by that set of solutions.
>
> For example, suppose RC4 just produced a 27. You know it was produced
> by m[m[i]+m[a]]. There are 256 possible values of i, 256 of a, 256 of
> m[i], 256 of m[a] that could cause that. But if you make those
> guesses, you can calculate m[i]+m[a], and of course m[m[i]+m[a]] = 27.
> So one result and four guesses gives you five values of the internal
> state, and that's a partial solution.
Actually, the attacker can keep track of i, so he doesn't have to guess
it...
>
> If you take one such partial solution, complete it twenty random ways,
> and examine the results those produce, you may find the 8th result
> from now is going to be 27 98% of the time. If the actual 8th result
> from now isn't 27, then this partial solution probably isn't the
> correct one.
I haven't thought it through for other stream ciphers, but for RC4, it
doesn't appear to work very well. The problem appears to be that the i
pointer scans through the array, and the j pointer is updated by every
element that the i pointer points to. This implies that where j happens to
be will be a complex function of (among other things) all the elements that
i has pointed to between the time you saw the first 27 and the 8th result
from now. And, I claim that if you don't assume all of those elements, j
will be anywhere with approximately equal probability, and so there won't be
any strong biases in the "8th result from now". And, if you do assume all
of intermediate permutation elements, you start getting into a backtracking
attack, which is the best known key-recovery attack without enormous amounts
of data, but is also known to be quite impractical.
>
> If you choose such partial solutions at random and complete them
> randomly, a billion times, you will see biases due simply to the fact
> that you are using RC4 and it just generated a 27. This could also be
> done by finding a billion RC4 sequences that contain 27 and comparing
> them without mucking about with partial solutions. However, you can
> do the same thing just as efficiently with the partial solutions
> dictated by a train of 10 results. Accidentally finding a billion
> sequences with those same 10 results is infeasible. The biases this
> gives you (assuming biases exist) should be able to tell you whether
> or not a very short sequence was generated with RC4. Equivalently, it
> would allow you to make good guesses at some unseen values.
>
> (Apologies for not exploiting this myself. I'm busy with toddlers.)
>
> - Bob Jenkins
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Intermittent stream cipher?
Date: Sat, 19 Aug 2000 18:41:54 +0200
mconroy wrote:
>
> I would like to know where I might find a cipher algorithm that allows me to
> stream plaintext input on an intermittent basis. The application is logging
> messages to a file which must be encrypted. The file has to remain
> encrypted at all times. However, opening the file, decrypting, adding ONE
> line, and reencrypting just doesn't make sense. I know there are a few
[snip]
Do I understand correctly that you have a file which is
to be constantly attached (opened) in interactive mode
and time and again a minute arbitrary part of it will be
updated? I suppose in that case you would naturally need
the facility of a 'direct access' or 'index sequential'
file such that each record has a unique (commonly numerical)
index. The record to be updated can then be accessed (or
created dynamically) individually and updated with the new
version of your encrypted data. I don't know whether C
supports this. But it is at least supported in Fortran,
Cobol and PL/I. (Common LISP also supports that, if my
memory doesn't betray me.)
M. K. Shen
==========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Intermittent stream cipher?
Date: Sat, 19 Aug 2000 10:11:41 -0600
In article <[EMAIL PROTECTED]>, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote:
>
> Use the stream cipher of your choice, and discard from it however many
> bytes are already in the file. Then use it to encrypt the line you're
> adding. To make this easier, you can use a block cipher in counter
> mode, which makes skipping x*blocksize bytes as simple as starting the
> counter at x instead of 0.
>
The total added keyspace can be no more than the allowed range of the
counter. This added amount is not apt to be significant.
--
If you have a conscience, vote for a candidate that has one too.
For president, I see only one that has consistently practiced what
he has preached, and always been on the side of basic good, RN.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Intermittent stream cipher?
Date: Sat, 19 Aug 2000 10:21:46 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> On Fri, 18 Aug 2000 15:37:18 -0400, "mconroy" <[EMAIL PROTECTED]>
> wrote, in part:
>
> >I would like to know where I might find a cipher algorithm that allows me to
> >stream plaintext input on an intermittent basis. The application is logging
> >messages to a file which must be encrypted.
>
> Actually, any type of block cipher mode will do that, if you save the
> complete state between encryptions....
>From the problem that replaced data might not be the same length as its
repacement, any of the customary block cipher modes, that are really means
to stream equal sized blocks, simply cannot handle such a real world
problem. To render a superficial fix, your data base must yield to the
disease of patchitis, an infirmity of poor system design.
--
Problem: Politics as Usual Rx: RN
------------------------------
From: Sander Vesik <[EMAIL PROTECTED]>
Subject: Re: DES: Say it or spell it? (Newbie question)
Date: 19 Aug 2000 16:55:28 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> "S. T. L." wrote:
>> I have always said "DES" as three letters, but "IDEA" as a single word.
> Yes, since IDEA was evidently selected to be a pronounceable
> acronym, that is appropriate.
DES is, imho, very pronouncable acronym. For all i know they could have
selected the words to form a prononcable acronym 8-)
Unlike AES, for example.
> For example, we just gave a demo for a program called "CTA"
> which is pronounced "see tee aay", not "stah", but the big
> project "MUVES" I worked on years ago was called "moves",
> not spelled out (except when helping somebody write it down).
--
Sander
FLW: "I can banish that demon"
------------------------------
** 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
******************************
