Cryptography-Digest Digest #471, Volume #12 Fri, 18 Aug 00 00:13:01 EDT
Contents:
Re: blowfish problem ("Douglas A. Gwyn")
Re: DES: Say it or spell it? (Newbie question) (DJohn37050)
Re: Funny Observation ([EMAIL PROTECTED])
Re: DES: Say it or spell it? (Newbie question) ("Adam Smith")
Re: What is up with Intel? (Benjamin Goldberg)
Re: DES: Say it or spell it? (Newbie question) (Nicol So)
Re: New quantum computer - any details? (Bill Unruh)
Re: New quantum computer - any details? (Bill Unruh)
Re: 215 Hz five-qubit quantum processor (Bill Unruh)
Re: 215 Hz five-qubit quantum processor (Bill Unruh)
Re: New Stream Cipher like SEAL ("Scott Fluhrer")
Re: www.curious.4ears ("rosi")
Re: Best AES candidates ?? ("Vic Drastik")
Re: New Stream Cipher like SEAL ("Scott Fluhrer")
Re: New Stream Cipher like SEAL ([EMAIL PROTECTED])
----------------------------------------------------------------------------
Crossposted-To: comp.lang.c
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: blowfish problem
Date: Thu, 17 Aug 2000 22:26:32 GMT
Michael Will wrote:
> Gergo Barany wrote:
> >No, a char is always one byte in C.
> No, sizeof(char) is always 1 in C.
> These are not two ways of saying the same thing.
Actually they are. The C standard uses "byte" and "char"
synonymously; which one is preferred depends on context.
But the long-established meaning of "byte" denotes merely
a contiguous collection of bits, at a specific location
within a generally wider "word", that can be accessed as
a unit. It does not connote "8 bits" (except when
referring to recent storage products, which are all
organized as arrays of 8-bit units). In Internetworking
standards, we generally use "octet" to mean precisely
8 bits, to avoid confusion on non-octet oriented systems.
A C "char" can be represented by any fixed number of bits
from 8 on up. Since the unit of object addressability is
coupled to "char", usually C implementors on an octet-
addressable architure will make "char" 8 bits so as not
to cause undue problems for systems programming. Other
platforms have at times used 9, 16, or other widths for
char.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 17 Aug 2000 23:32:41 GMT
Subject: Re: DES: Say it or spell it? (Newbie question)
NIST came up with the term and everyone at NIST calls it "dez"
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Funny Observation
Date: Thu, 17 Aug 2000 23:55:19 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> :> On Wed, 16 Aug 2000 20:02:06 GMT, [EMAIL PROTECTED] wrote, in
part:
>
> :> >Anyone ever notice that Dave Scott calls himself the 'Zip Guy' but
> :> >known of his software involves the deflate algorithm.
>
> I believe he has, in fact, used zip compression, for some things.
I would like you to meet "Tom" the ZipGuy.
> : I can't fathom why he believes huffman or arith alone is better then
> : deflate. I really would like to see him find typical files that
> : compress better with his methods then deflate.
>
> Files that compresses better with Huffman or arithmetic compression
alone
> exist. It's known that any compressor that doesn't add information
which
> isn't present in the original file is optimal for /some/ set of target
> files.
>
> I beleive for Huffman/arithmetic schemes, the criterion is something
> vaguely along the lines of a fixed frequency of symbols throughout
> individual target files. In addition, hHffman schemes prefer it if
> these frequencies are exact multiples of two of one another.
Deflate incorporates a huffman coder btw.
>
> : Also time and time again I repeat that smaller files means less
WASTED
> : SPACE. Which means the entropy per bit is higher (closer to one)
then
> : with the other methods. Doesn't that make sense?
>
> This is true. What is your point?
>
> While size is important, the size of the resulting files is not the
only
> criterion when choosing a compression algorithm for use with
encryption.
Think about it. If the compressed file is smaller it can't possible
inject nonrandom data, otherwise it wouldn't compress better. This is
very simple to prove. Consider a huffman codec the best it can get for
ASCII is 8 to 1, but a 12/4 LZSS codec can get 128 to 17 (bits) or
about 16 to 1. This is just LZSS, DEFLATE can get upwards of 1022 to
1...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Adam Smith" <[EMAIL PROTECTED]>
Subject: Re: DES: Say it or spell it? (Newbie question)
Date: Fri, 18 Aug 2000 00:26:47 GMT
Same here...
"S. T. L." <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I have always said "DES" as three letters, but "IDEA" as a single word.
>
> -*---*-------
> S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
> My upgraded Book Reviews Page: * http://sciencebook.cjb.net *
> Optimized pngcrush executable now on my Download page!
> Long live pngcrush! :->
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: What is up with Intel?
Date: Fri, 18 Aug 2000 02:18:04 GMT
lcs Mixmaster Remailer wrote:
>
> Roger Schlafly wrote:
> > lcs Mixmaster Remailer wrote:
> > > A careful reading of the document reveals that Intel's version of
> > > the bias remover uses three bits of state, rather than the two bit
> > > version attributed to von Neumann. It is a genuine improvement.
> >
> > How is it better? IMO, Intel should have omitted the bias
> > rejecter. It makes the chip unpredictable. It is easy to
> > do a much better job of removing bias in software. I'd rather
> > have the raw bits.
>
> Actually many people prefer that their random numbers be
> unpredictable. Chacun a son gout, I suppose...
What I think Roger means by "makes the chip unpredictable" is that by
using this method of removing bias, the time it takes to produce X many
random bits is unpredictable.
> As for how it is better, specifically it produces more efficient
> output, with a smaller percentage of rejected bits, preserving more of
> the entropy in the input.
This sounds like a good thing... with the von Neumann method of removing
bias, if we run it on an already unbiased stream of bits, over half the
bits will be discarded. How much does this decorrelator remove? I
think I've seen it said that 3 bits of state are used... How is this
done?
> With the bias remover, the chip produces very good quality random
> numbers that pass standard statistical tests, as described in
> http://www.cryptography.com/intelRNG.pdf. (We'll ignore the paranoids
> who claim that the results are faked...) These results will be good
> enough to be used directly in some applications.
>
> Without the bias remover the chip would pass almost no tests.
Some of us would like to use our own methods for removing bias, such as
a hash, a crc, or some custom designed method.
> A superficial reading would suggest that the RNG was crap since it
> fails everything. Sophisticated reviewers would know to look deeper,
> but it could still hurt the chip's acceptance if it got a reputatation
> for producing bits that fail elementary randomness tests. So to some
> extent this can be seen as a marketing requirement.
The solution for this is to provide two interfaces, one for the raw
bits, and another with the bias removed. Release notes would include a
note stating that the raw interface gives results in constant time, but
with a poorer quality of randomness, and the de-biased interface gives
much better random numbers, but at an unpredictable rate.
--
"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: Nicol So <[EMAIL PROTECTED]>
Subject: Re: DES: Say it or spell it? (Newbie question)
Date: Thu, 17 Aug 2000 22:24:01 -0400
Reply-To: see.signature
"Douglas A. Gwyn" wrote:
>
> DJohn37050 wrote:
> > DES is usually pronounced dezz.
>
> Since when? Everybody I know spells it out, just as we do
> with the other umpteen thousand acronyms we are plagued with.
I guess that depends on the people you work with. In my organization and
among the people I meet in industry forums, "DES" is generally
pronounced as "dez". I think we have tendency to force pronunciations on
acronyms (many of which are technically only abbreviations).
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: New quantum computer - any details?
Date: 18 Aug 2000 02:43:53 GMT
In <HLem5.48347$[EMAIL PROTECTED]> "Ed Suominen"
<[EMAIL PROTECTED]> writes:
>"Stanley Chow" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> There is (a little) more detail at
>> http://live.altavista.com/e?efi=980&ei=2087325&ern=y
>Quote from the article:
>"This phenomenon permits a quantum computer to have enormous power,
>Chuang said. For certain types of calculations, like complex algorithms for
>cryptography or searches -- a quantum computer using several hundred more
>atoms in tandem would be able to perform billions of calculations at the
>same
>time."
>Time for bigger keys or a switch to GF(p) ECC, methinks...
Hype from scientists is unfortunately not unknown. This is silly.
Quantum computers do not scale. Each extra bit requires as much (or
more) work than the one before. (estimates for atom type is 1 year per
bit). NMR quantum computers- which I thing is what Chuang used, will
definitely peter out by about 10 bits.
I think you can wait to switch.
>--
>Ed Suominen
>Registered Patent Agent
>Web Site: http://eepatents.com
>PGP Public Key: http://eepatents.com/key
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: New quantum computer - any details?
Date: 18 Aug 2000 02:45:55 GMT
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.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: comp.arch
Subject: Re: 215 Hz five-qubit quantum processor
Date: 18 Aug 2000 02:52:22 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
> Question -- is keeping an N+1 qubit computer coherent a *lot*
>harder than keeping an N qubit computer coherent? IE, does it
Yes. It essentially grows exponentially in some sense.(The error rate in
a set time due to decoherence increases exponentially with the number of
bits.) Prob of not decohereing for one bit= exp(-at), prob of not
decohering for n bits = exp(-nat). Of course once you are in the regime
where that exponential differs from a linear function of the arguement,
the game is all over anyway. On the other
hand, if you can get error correction going, then you can knock dowsn
the decoherence.
>get more difficult as an exponential, polymetric, linear, or some
>other function of qubits, roughly speaking? Or is everyone still
>scratching their heads and unable to say?
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: comp.arch
Subject: Re: 215 Hz five-qubit quantum processor
Date: 18 Aug 2000 02:53:56 GMT
In <8nctf9$5tf$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Paul Rubin) writes:
]The class of problems a quantum computer can probablistically solve in
]P-time is called QBP. It's believed to be larger than P but it still
]is no larger than NP. Factoring and other search-type problems sit
]inside QBP, but sorry, the classical halting problem is still undecidable.
No, search is still non-polynomial. Grovers speedup was to sqrt(N) which
is still very non-polynoimial in the length of N.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: New Stream Cipher like SEAL
Date: Thu, 17 Aug 2000 19:36:11 -0700
Mark Wooding <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Scott Fluhrer <[EMAIL PROTECTED]> wrote:
>
> > Well, one thing that is vaguely troubling is that each fundamental step
> > (varients of which you do 16 times between state outputs):
> >
> > > A = ROL(A ^ D, D>>27) + key[D&1023];
> >
> > is noninvertable, and so loses a little entropy.
>
> It looks invertible enough to me. In particular, computing
>
> A = ROR(A - key[D & 1023], D >> 27) ^ D
>
> looks like a most convincing inverse function to me.
You're right, of course. Somehow, I read this as:
A = ROL(A ^ D, D>>27) + key[A&1023];
Sorry.
--
poncho
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: www.curious.4ears
Date: Thu, 17 Aug 2000 23:33:44 -0400
John Wasser wrote in message
<[EMAIL PROTECTED]>...
>Did you use the contact information on his AT&T webpage:
>
> http://www.research.att.com/~amo/
>
Dear John,
Thank you very much.
Not a problem with e-address, I don't think. I mentioned that
I did get a reply to my first message. But then none of my
follow-ups sent to the same address triggered anything back.
You have the chance of seeing him? You could help by asking
him directly. Or you know who works in C224 and C226? Maybe I
can send them an e-mail message and ask for help? The answer
could be quite a simple one, but I want it. Don't get obsessed with
anything easily. Am.
If (BIG IF) He sees me to that day when I get an answer, I
PROMISE the world to breathe or pant past the eve to get it!
And my logic is just that simple, or simplistic.
Thanks again, John, for the information (and anybody who
helped in this respect).
--- (My Signature)
------------------------------
From: "Vic Drastik" <[EMAIL PROTECTED]>
Subject: Re: Best AES candidates ??
Date: Fri, 18 Aug 2000 13:14:56 +1000
>> But which should my last choices be ???
> Other block ciphers with interesting performance are:
> * Blowfish. (The predecessor to Twofish. It's also
> easy to implement and hard to get wrong.)
>
> * Square. (The predecessor to Rijndael.
> It's very fast, and has a wonderfully elegant design.
> There are security worries, though. :-( )
> -- [mdw]
This is the second time someone has mentioned possible security problems
with the Square cipher. Could you provide more detail , or give an online
reference ?
Vic
--
Email : [EMAIL PROTECTED]
Decode email address thus :
1=v,2=i,3=c,4=d,5=r,6=a,7=s,8=t,2=i,9=k
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: New Stream Cipher like SEAL
Date: Thu, 17 Aug 2000 20:01:00 -0700
<[EMAIL PROTECTED]> wrote in message news:8nh1r2$2lo$[EMAIL PROTECTED]...
> In article <8ngthl$kmi$[EMAIL PROTECTED]>,
> "Scott Fluhrer" <[EMAIL PROTECTED]> wrote:
> >
> > <[EMAIL PROTECTED]> wrote in message news:8nfapv$4r1
> $[EMAIL PROTECTED]
> > > The C source (really easy to read) is at
> > >
> > > http://www.geocities.com/tomstdenis/files/sc1.c
> > >
> > > Please comment if possible.
> > Well, one thing that is vaguely troubling is that each fundamental
> step
> > (varients of which you do 16 times between state outputs):
> >
> > > A = ROL(A ^ D, D>>27) + key[D&1023];
> >
> > is noninvertable, and so loses a little entropy. Not a whole lot,
> but if
> > you do this enough times, you start being liable to getting into a
> loop, or
> > start repeating the output that occurs for another seed. You should
> > definitely restrict how much output you can generate for a single
> seed.
>
> Actually you are wrong.
As I admitted to Mark, yes, I had a brain cramp there...
> > On a different topic, you may want to change the order of the
> operations in
> > the inner loop, as in:
> >
> > D = ROL(D ^ C, C>>27) + key[C&1023];
> > B = ROL(B ^ A, A>>27) + key[A&1023];
> > C = ROL(C ^ B, B>>27) + key[B&1023];
> > A = ROL(A ^ D, D>>27) + key[D&1023];
> >
> > This does make differentials propogate slower through the cipher in
> the
> > forward direction, however, I would claim that that isn't very
> important, as
> > the attacker can use differentials in both directions, and in the
> original
> > code, differentials propogated slowly in the reverse direction. In
> the
> > revised code, I claim that forward and reverse differentials are
> somewhat
> > better than the original reverse differentials, and as an added
> bonus, the
> > code would be much more parallizable.
>
> I want the strong avalanche though, that's what I hope will make it
> secure. Note that I will have to use more passes with the reverse
> direction and likely the code will be no faster because of that.
"Will have to use more passes with the reverse direction"? Obviously, we're
talking about two different things. I think I will try to enunciate what I
meant more clearly.
By reverse direction, I mean starting with a known state (or output
difference), applying the inverse of the next state function to it, and
seeing how it propogates to the previous state. Obviously, this is just
another way of viewing the cipher, and so there is no opportunity to "use
more passes".
And, one obvious differential starts off with the A,B,C,D difference being
(X,X,X,X), where X is a single bit difference that is neither the one of the
top 5 bits nor the bottom 10 bits.
The first line you get to in the inverse direction is:
D = ROL(D ^ C, C>>27) + key[C&1023];
This sets the differential in D to 0 with probability 1. Continuing this to
the top of the last round gives you the differential (Y,0,0,0) where Y is a
single bit difference that is neither the one of the top 5 or bottom 10 with
probability 17/32.
Continuing, the round before that gives you the difference (W,W,0,0) (again,
where W is a single bit differentials that avoid the top 5 and bottom 10)
with probability 17/(32*32)
And, the round before that gives you the difference (S,0,T,0) (with S and T
being single bit differentials that avoid the top 5 and bottom 10) with
probability (17/32)**2.
And, just before the first round gives you the differential (E,F,G,H) where
E is a two bit differential, and F,G,H are one bit differentials with
probability (17/32)**3 (if my math is right).
This gives a detectable differential with a reasonably high probability
(0.0003).
Now, this particular differential may not be a major concern -- in a stream
cipher, an attacker cannot just chose differentials, he has to dig through
the stream looking for likely candidates. However, I do claim that it is an
indication that the cipher is not as strong as you hoped.
--
poncho
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: New Stream Cipher like SEAL
Date: Fri, 18 Aug 2000 03:18:55 GMT
In article <8ni8hp$o7f$[EMAIL PROTECTED]>,
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote:
>
> Mark Wooding <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Scott Fluhrer <[EMAIL PROTECTED]> wrote:
> >
> > > Well, one thing that is vaguely troubling is that each
fundamental step
> > > (varients of which you do 16 times between state outputs):
> > >
> > > > A = ROL(A ^ D, D>>27) + key[D&1023];
> > >
> > > is noninvertable, and so loses a little entropy.
> >
> > It looks invertible enough to me. In particular, computing
> >
> > A = ROR(A - key[D & 1023], D >> 27) ^ D
> >
> > looks like a most convincing inverse function to me.
> You're right, of course. Somehow, I read this as:
>
> A = ROL(A ^ D, D>>27) + key[A&1023];
>
> Sorry.
>
No problem. At least you posted :)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
