Cryptography-Digest Digest #950, Volume #12 Wed, 18 Oct 00 12:13:00 EDT
Contents:
Re: FTL Computation (ca314159)
Re: Counting one bits is used how? (Runu Knips)
Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom (CiPHER)
Re: "The code book" where (CiPHER)
Re: Comments wanted on NIST Rng Tests ([EMAIL PROTECTED])
Re: Works the md5 hash also for large datafiles (4GB) ? (Tom St Denis)
Kappa of different languages ("Martin Apel")
"Software TEMPEST" explained (John Savard)
Re: "Software TEMPEST" explained (John Savard)
Re: Counting one bits is used how? ("bubba")
Re: Smartcard, Mathematical Proof? (David A Molnar)
Re: How about the ERIKO-CHAN cipher? (JPeschel)
Re: Works the md5 hash also for large datafiles (4GB) ? (John Myre)
Re: Works the md5 hash also for large datafiles (4GB) ? (Runu Knips)
Re: Works the md5 hash also for large datafiles (4GB) ? ("Sam Simpson")
Re: Works the md5 hash also for large datafiles (4GB) ? (Runu Knips)
Re: algo to generate permutations (Andreas Gunnarsson)
Re: Is it trivial for NSA to crack these ciphers? (Bob Silverman)
Re: Is it trivial for NSA to crack these ciphers? (Bob Silverman)
Re: Is it trivial for NSA to crack these ciphers? (Bob Silverman)
Re: Is it trivial for NSA to crack these ciphers? (Bob Silverman)
Re: Counting one bits is used how? ("Trevor L. Jackson, III")
Re: Works the md5 hash also for large datafiles (4GB) ? (John Myre)
----------------------------------------------------------------------------
From: ca314159 <[EMAIL PROTECTED]>
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: FTL Computation
Date: Wed, 18 Oct 2000 10:59:44 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> ca314159 wrote:
> >
> > You haven't defined information yet.
> >
>
> See the post you're responding to. It's a stream of
> bits being sent from one point to another point. Not
> a spatially separated set of receiver points.
Depends on the network protocol used. Not all protocols
use direct connections. Some split the data apart and
send them along various paths like virtual beam splitters.
Sentences, words, characters,...
What's smaller than a character ?
A character seems to be a quantum of information in this case:
It's probability under optimal compression varies
according to it's spatial and temporal context.
What's the context of this thread ?
It is dynamic and changing with every new character added to it.
Until the thread has ended, there is no fixed measure of
the information content of a character. One could say
that when the thread is dead, it has collapsed and may be
measured. One could also say that measuring it causes a
collapse. That measure though is only good for the context of
what it acts on.
I've never heard the words "data collision" used in
quantum computation. Perhaps it uses another name
for it ? Do you think data collision occurs in quantum
computation ?
> > Consider how QM uses virtual wavefunctions and
> > how I/O causes their unusual properties to collapse.
> >
> > Wavefunctions are a 'cheat' just like FTL computation.
> > They do interesting things as long as you don't
> > look at or measure or communicate between them (decohere).
> >
>
> Then how do you do the computation? Does QM violate
> FTL communication? Not that I've heard.
Quantum mechanics is what the 'mechanics' use,
quantum physics is what theoretists study.
Classical computers fit nicely in a deterministic box
Quantum computers don't.
'because, sometimes you feel like a nut;
sometimes you don't'
- the Mounds-Almond Joy song
Source code for quantum computer simulators:
http://www.dcs.ex.ac.uk/~jwallace/simtable.htm
If the simulator is mechanical, what's the problem
with the real thing ? That's the difference between
QM and QP.
If you yell at someone while they're working,
they can't concentrate. Quantum computers are the
same. But everyone demands closure, so you'd expect
the person concentrating to stop somewhere and
give you an answer.
> > In the olympics, does the high-jumper jump the height
> > if his or her center of mass never goes over the bar ?
> > A virtual cheat has its uses.
> >
>
> A silly analogy doesn't help here.
They become more useful if you have alot of them.
Like collecting pennies.
>
> > In an earlier thread I gave you a link to a specific use
> > for the lighthouse effect. Do you remember ?
> >
>
> No I don't remember it, because I didn't read it, because
> you don't know what you're talking about.
Then you must be a bad teacher ?
I had a few teachers that used the darth vader approach.
They were like shrinks who thought that since
electroshock therepy cured one 'student',
it should also cure the common cold as well.
>
> John Anderson
>
--
--
http://www.bestweb.net/~ca314159/
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 18 Oct 2000 13:10:57 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Counting one bits is used how?
Rob Warnock wrote:
> Exercise for the reader:
I hate this arrogance of the mathematicans.
------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom
Date: Wed, 18 Oct 2000 11:06:56 GMT
In article <[EMAIL PROTECTED]>,
"Sam Simpson" <[EMAIL PROTECTED]> wrote:
> Or maybe the "thief" is showing good faith by returning the unit and
> will now be paid the 25,000 UKP for safe return of the remaining
> items (e.g. the rotors!).
Well, on the news they said it was something of the sort, but I doubt
any amount of 'good faith' is involved. Apparently they established a
business-like deal.
I guess they receive an amount for the main machine and the rest when
the rotors arrive. (The theives were probably 'bricking it' for the week
that the machine was sitting at the BBC.)
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Subject: Re: "The code book" where
Date: Wed, 18 Oct 2000 11:13:20 GMT
In article <[EMAIL PROTECTED]>,
"ajd" <[EMAIL PROTECTED]> wrote:
>
> I don't think Simon Singh would like it if you start downloading his
> books for free.
But he does love basically reprinting The Code Book under a new name
just to accompany his TV series! Yay!
Granted he warns people, some place within his website, that if they
have The Code Book they _might_ not find the new one useful. Yay!
Errr... yes.
I find his range of v-neck jumpers on his TV series quite amusing, I
must say. Not that I'm a fashion guru or anything...
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Comments wanted on NIST Rng Tests
Date: Wed, 18 Oct 2000 11:57:24 GMT
Thank you for your input. I am sure a lot of you experts must have some
comments too on the subject. I would very much appreciate your input on
that subject.
Thank you.
Brice.
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> [EMAIL PROTECTED] wrote:
> >
>
> > Have you got any views, comments on this test suite given by NIST?
How
> > does it compare to DIEHARD? Is it likely to become a standard in
testing
> > Rngs for cryptographic applications?
>
> I have not used the suite but it seems to be based on lots
> of careful work with knowledge of existing packages like
> Diehard and hence can be expected to be superior to these.
> To the last question, my estimate is yes (if not a standard
> then so much employed that it will be defacto one).
>
> M. K. Shen
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Works the md5 hash also for large datafiles (4GB) ?
Date: Wed, 18 Oct 2000 12:05:15 GMT
In article <[EMAIL PROTECTED]>,
"Sam Simpson" <[EMAIL PROTECTED]> wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
> news:8sht3j$pui$[EMAIL PROTECTED]...
>
> <SNIP>
>
> > Oops... sorry. At any rate who will use a 512-bit hash anyways?
> >
> > Tom
>
> The same people that require AES with a 256-bit key - don't forget
> that a 256-bit hash is "vulnerable" to some attacks in 2^128
> operations (due to the birthday paradox). So, for a balanced system,
> I guess it can make sense to use a 512-bit hash with a 256-bit block
> cipher?
Perhaps....
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Martin Apel" <[EMAIL PROTECTED]>
Subject: Kappa of different languages
Date: Wed, 18 Oct 2000 14:19:41 +0200
Hi!
I'm searching for the Kappa of different languages like
english, french, german, turkish etc.
Can anyone point me to a ressource about this?
Thanks
Martin Apel
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: "Software TEMPEST" explained
Date: Wed, 18 Oct 2000 11:30:37 GMT
While I don't take it too seriously, I have to admit that it might
well protect your data from some hackers, who are only using
inexpensive electronic equipment from their basements:
on my page at
http://home.ecn.ab.ca/~jsavard/crypto/mi0606.htm
I now explain how the notion of using funny-colored text on your RGB
monitor to resist eavesdropping might work.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: "Software TEMPEST" explained
Date: Wed, 18 Oct 2000 12:13:52 GMT
On Wed, 18 Oct 2000 11:30:37 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>While I don't take it too seriously, I have to admit that it might
>well protect your data from some hackers, who are only using
>inexpensive electronic equipment from their basements:
I've revised the page since this posting to point out that I'm
discussing a very simplistic scheme, that falls far short of the
sophistication of the measures discussed in the paper by Markus Kuhn
and Ross Anderson.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "bubba" <[EMAIL PROTECTED]>
Subject: Re: Counting one bits is used how?
Date: Wed, 18 Oct 2000 07:55:09 -0500
I have seen the two variations you describe call Galois LFSR and
Fibonacci LFSR. But I don't think properly chosen polynomials
can cause them to produce the same output. A fundamental difference
is that for both types, some state transitions amount to a single shift.
But on the non shift only updates, the Galois LFSR differs by a single
and multiple bit updates. The Fibonacci LFSR differs by a single shift
with a zero or non-zero bit shifted in. Here is an example:
http://sduplichan.home.att.net/primitive/gf16.txt
"Rob Warnock" <[EMAIL PROTECTED]> wrote in message
news:8sjtn7$aqcmk$[EMAIL PROTECTED]...
> David Wagner <[EMAIL PROTECTED]> wrote:
> +---------------
> | Rob Warnock wrote:
> | >Well, yes, dot-products are used sometimes in GF math, but LFSRs are
more
> | >likely to use N-way parity, that is, "popcount(x)&1", in the feedback
terms.
> |
> | Are you sure? I'd say that LFSRs are more likely to use
popcount(r&t)&1,
> | where r is the state of the shift register and t [is] the feedback taps.
> +---------------
>
> Hmmm... I think we're saying the same thing, actually. My "x" *is*
> your "r&t" with the constant zeros compressed out, because I don't
> [usually] consider the feedback taps to be a "variable" [once I've
> chosen a polynomial], so the bits of my "x" are only those terms
> that *are* fed back.
>
> By the way, go look at some texts that actually show you the wiring
> diagrams. There are basically two flavors: one that computes a single
> parity of selected taps and feeds that in as the input (which is what
> both of the above methods implement); and one which more directly maps
> the notion of computing the "residue modulo the generator polynomial",
> which takes the *output* of the register and feeds it back into multiple
> places, each of them being an XOR between one of the intermediate stages
> and the next. These compute the same sequence iff you use reciprocal
> polynomials for the two. [That is, P(x)(mod G(x)) for one way of wiring,
> and 1/P(x)(mod G(x)) for the other ... I think.]
>
> While the first [input = parity(feedbacks)] is certainly simpler in
> hardware, the second is, as I said, closer to the "modulo a generator
> polynomial" notion *and* is easier to implement in software, oddly
> enough.
>
>
> -Rob
>
> p.s. Exercise for the reader: Given a primitive polynomial over GF(2),
> how do you implement in software a CRC-style checksum using that
polynomial
> such that you can feed multiple input bits into the checksum in a single
> "round" (so to speak). Hint#1: If the polynomial is of degree "m+1", and
> you want to input "k" data bits at a time, you're allowed to precompute
> an "m"-bit wide table with "2^n" entries in it. Hint#2: If "integers"
> in your software are at least "m" bits wide, a single "round" needs only
> two shifts, two XORs, and one lookup in the table to correctly "shift in"
> all "k" data bits.
>
> Bonus question: Can you change one of the shifts into an AND?
> If so, how, and what has to change? And when might you want to do that?
> Or if not, why not?
>
> -----
> Rob Warnock, 31-2-510 [EMAIL PROTECTED]
> Network Engineering http://reality.sgi.com/rpw3/
> Silicon Graphics, Inc. Phone: 650-933-1673
> 1600 Amphitheatre Pkwy. PP-ASEL-IA
> Mountain View, CA 94043
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Smartcard, Mathematical Proof?
Date: 18 Oct 2000 12:37:15 GMT
Sundial Services <[EMAIL PROTECTED]> wrote:
> render the device inoperable without it. Certainly a small chipcard is
> easier to lock-up than the entire device would be. But it also
> represents a vulnerability of its own if the intruder is creative --
> "crunch, oops."
> I don't know if a mathematical proof could possibly consider "crunch,
> oops." ;-)
yeah, we can do that. just define it formally. We say that a "cunch,
oops" occurs when...X. Now prove theorems which read like
"If 'crunch, oops', then user is unable to access service."
After a while we'll end up saying "crunch, oops" so many times it
will become totally robbed of meaning.
-david
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Date: 18 Oct 2000 13:18:44 GMT
Subject: Re: How about the ERIKO-CHAN cipher?
[EMAIL PROTECTED] (wtshaw) writes:
>In article <8siki7$g2d$[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
>
>> The ERIKO-CHAN cipher is a private-key cipher.
>>
>....
>> Of course, with each message the key must be
>> different.
>
>This is also a basic weakness of DES/AES
How so?
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Works the md5 hash also for large datafiles (4GB) ?
Date: Wed, 18 Oct 2000 07:47:59 -0600
Paul Schlyter wrote:
<snip>
> WHAT? Most MD5 implementations I've seen so far allow input of any
> length....
<snip>
You're not pulling my leg here, are you? They allow, say, an
input of 5 bits, exactly?
JM
------------------------------
Date: Wed, 18 Oct 2000 16:04:42 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Works the md5 hash also for large datafiles (4GB) ?
Sam Simpson wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
> news:8sht3j$pui$[EMAIL PROTECTED]...
> > [...] who will use a 512-bit hash anyways?
> The same people that require AES with a 256-bit key - don't forget
> that a 256-bit hash is "vulnerable" to some attacks in 2^128
> operations (due to the birthday paradox). So, for a balanced system,
> I guess it can make sense to use a 512-bit hash with a 256-bit block
> cipher?
Yes, I think so, too. 512 bit hashes are just like 256 bit block
ciphers. Enough for eternity to our best knowledge.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Works the md5 hash also for large datafiles (4GB) ?
Date: Wed, 18 Oct 2000 15:10:06 +0100
Yes, MD5, SHA-1 etc allow input of any arbitrary length in bits.
Typically inputs are padded to the desired length anyway....
--
Sam Simpson
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
John Myre <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Paul Schlyter wrote:
> <snip>
> > WHAT? Most MD5 implementations I've seen so far allow input of
any
> > length....
> <snip>
>
> You're not pulling my leg here, are you? They allow, say, an
> input of 5 bits, exactly?
>
> JM
------------------------------
Date: Wed, 18 Oct 2000 16:12:34 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Works the md5 hash also for large datafiles (4GB) ?
Paul Schlyter wrote:
> In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
> > (Not that I'd trust an implementation to get it right without
> > checking; and few implementations allow input other than sequences
> > of 8-bit bytes.)
>
> WHAT? Most MD5 implementations I've seen so far allow input of any
> length....
Hmm my own implementation of hashfunctions all allow to specify only
bytes, not bits. It just made no sense to me - you cannot write a
file with a bitlength, only with a bytelength. The interfaces of
the computer simply doesn't permit it (for example, if reading with
stdio in C).
I also don't remember that I've seen an implementation which is
actually able to handle bits instead of bytes. And it would result in
quite a number of problems - for example, you have to start count
bits with the MSB for SHA-1 and RIPE MD160, but with the LSB for
Tiger/192.
------------------------------
From: Andreas Gunnarsson <[EMAIL PROTECTED]>
Subject: Re: algo to generate permutations
Date: Wed, 18 Oct 2000 16:57:12 +0200
On Wed, 18 Oct 2000 [EMAIL PROTECTED] wrote:
> I just took a stab at generating only distinct arrangements,
> http://burtleburtle.net/bob/c/anagram.c
> It places all occurences of one letter, then all occurences of the
> next, and so forth. It's bigger and slower than pure permutations,
> although it only does work proportional to the number of distinct
> arrangements. It's still not lexicographic order.
It feels like this is a little off topic, but...
I exctracted the algorithm for generating distinct arrangements from the
number solving program I made. It is a quite simple non-recursive
algorithm that generates only distinct arrangements and the output is
sorted in alphabetic order.
It is available at ftp://ftp.zzlevo.net/pub/src/perm.c if anyone is
interested.
Andreas
--
Andreas Gunnarsson <[EMAIL PROTECTED]>
Carlstedt Research & Technology
Phone: +46 31 7014268
Mobile: +46 70 4262889
Fax: +46 31 101987
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Wed, 18 Oct 2000 14:58:00 GMT
In article <[EMAIL PROTECTED]>,
Anonymous <[EMAIL PROTECTED]> wrote:
> I'm not really interested in opinions of the relative
strengths/weakness of various ciphers.
>
> I'm more interested to know what people think about NSA's ability to
break messages encrypted with these ciphers.
Why???
Allow me to expand upon this.
(1) What people outside the NSA think is irrelevant. They can not
possibly have information about the NSA's true capabilities. Given
this, any "opinion" is worthless, because it is totally unfounded.
(2) I fail to understand people's paranoia about the NSA. Yes,
they employ a large number of competent mathematicians. But what
grounds does anyone have for believing that they are more competent than
mathematicians employed elsewhere. How many responding to this thread
know even one mathematician who works for the NSA? (I know several)
If you don't, how can you have an opinion one way or the other as
to the NSA's ability to break existing ciphers?
Answer: you can't. any answer you give is pure speculation and
has no foundation in fact.
(3) I fail to understand those people who have the vague notion that
somehow the NSA has super-human computation capabilities. They have
their own fabrication facilities and can design their own hardware,
but their budget is not infinite. Even though its exact value is
not revealed to the public, one can draw inferences about its upper
bound. From this, one can get approximations as to the upper bound
of their computational capabilities.
(4) We *know* how much arithmetic is required to break a 128-bit
cipher. We know how much storage is needed to conduct a linear or
differential attack. Why then do we keep getting speculation that the
NSA can somehow magically break ciphers that the outside world can not?
I am curious about the psychology of people who ask these kinds of
questions -- questions for which it is clear that noone can answer
in a meaningful way. What is the point?
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Wed, 18 Oct 2000 15:02:39 GMT
In article <[EMAIL PROTECTED]>,
lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
<snip>
>
> Aren't you forgetting the obvious fact that these "alphabet soup
agencies" don't use any of these ciphers to conceal data that is
important to them?
And exactly where did you get your information about this
"obvious fact"???
The real fact is that you have no clue about what ciphers they do or do
not use and are merely spouting paranoia.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Wed, 18 Oct 2000 15:02:52 GMT
In article <[EMAIL PROTECTED]>,
lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
<snip>
>
> Aren't you forgetting the obvious fact that these "alphabet soup
agencies" don't use any of these ciphers to conceal data that is
important to them?
And exactly where did you get your information about this
"obvious fact"???
The real fact is that you have no clue about what ciphers they do or do
not use and are merely spouting paranoia.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Wed, 18 Oct 2000 15:09:46 GMT
In article <[EMAIL PROTECTED]>,
lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
> >> Aren't you forgetting the obvious fact that these "alphabet soup
agencies" don't use any
> >> of these ciphers to conceal data that is important to them?
>
> >Different problems get different solutions. It's really that simple.
>
> So classified data gets a classified cipher? Or classified data gets
a better cipher? What's "better". That all I'm asking.
Classified data (e.g. tactical battlefied information) must be
transmitted/received using militarily hardened hardware. What ciphers
are actually imbedded in them can only be speculated upon by
outsiders. You have no basis for guessing one way or the other what
might be used, and this makes any comments you make worthless.
Anyone who *knows* the answer to your question is certainly not in
a position to reveal it.
>
> Is it a political statement to say that if these ciphers aren't good
enough for NSA, they're not good enough for me?
You don't know and have no way of knowing if they are good enough.
Nor do you have any understanding of the *operational* requirements
for a military cyptosystem.
> The NSA knew how to strengthen DES against differential cryptanalysis
many years before the civilian world knew what it was.
Where did you get this fact? People at IBM who designed the cipher
certainly knew about such attacks.
> I'm simply asking people to speculate
Such "speculation" is totally without merit or information content.
It is *pointless*
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 18 Oct 2000 11:21:05 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Counting one bits is used how?
bubba wrote:
> I have seen the two variations you describe call Galois LFSR and
> Fibonacci LFSR. But I don't think properly chosen polynomials
> can cause them to produce the same output.
There is some fuzz on the term "output" in this context. One can interpret the
"output" to be the most recently generated bit or "output" can mean the contents
of the register. Since the sequence of register states will not match, using
them as outputs leads to dissimilar output sequences. But if only the most
recently generated bit is considered, the register states are not relevant, and
similarity is possible.
> A fundamental difference
> is that for both types, some state transitions amount to a single shift.
> But on the non shift only updates, the Galois LFSR differs by a single
> and multiple bit updates. The Fibonacci LFSR differs by a single shift
> with a zero or non-zero bit shifted in. Here is an example:
>
> http://sduplichan.home.att.net/primitive/gf16.txt
>
> "Rob Warnock" <[EMAIL PROTECTED]> wrote in message
> news:8sjtn7$aqcmk$[EMAIL PROTECTED]...
> > David Wagner <[EMAIL PROTECTED]> wrote:
> > +---------------
> > | Rob Warnock wrote:
> > | >Well, yes, dot-products are used sometimes in GF math, but LFSRs are
> more
> > | >likely to use N-way parity, that is, "popcount(x)&1", in the feedback
> terms.
> > |
> > | Are you sure? I'd say that LFSRs are more likely to use
> popcount(r&t)&1,
> > | where r is the state of the shift register and t [is] the feedback taps.
> > +---------------
> >
> > Hmmm... I think we're saying the same thing, actually. My "x" *is*
> > your "r&t" with the constant zeros compressed out, because I don't
> > [usually] consider the feedback taps to be a "variable" [once I've
> > chosen a polynomial], so the bits of my "x" are only those terms
> > that *are* fed back.
> >
> > By the way, go look at some texts that actually show you the wiring
> > diagrams. There are basically two flavors: one that computes a single
> > parity of selected taps and feeds that in as the input (which is what
> > both of the above methods implement); and one which more directly maps
> > the notion of computing the "residue modulo the generator polynomial",
> > which takes the *output* of the register and feeds it back into multiple
> > places, each of them being an XOR between one of the intermediate stages
> > and the next. These compute the same sequence iff you use reciprocal
> > polynomials for the two. [That is, P(x)(mod G(x)) for one way of wiring,
> > and 1/P(x)(mod G(x)) for the other ... I think.]
> >
> > While the first [input = parity(feedbacks)] is certainly simpler in
> > hardware, the second is, as I said, closer to the "modulo a generator
> > polynomial" notion *and* is easier to implement in software, oddly
> > enough.
> >
> >
> > -Rob
> >
> > p.s. Exercise for the reader: Given a primitive polynomial over GF(2),
> > how do you implement in software a CRC-style checksum using that
> polynomial
> > such that you can feed multiple input bits into the checksum in a single
> > "round" (so to speak). Hint#1: If the polynomial is of degree "m+1", and
> > you want to input "k" data bits at a time, you're allowed to precompute
> > an "m"-bit wide table with "2^n" entries in it. Hint#2: If "integers"
> > in your software are at least "m" bits wide, a single "round" needs only
> > two shifts, two XORs, and one lookup in the table to correctly "shift in"
> > all "k" data bits.
> >
> > Bonus question: Can you change one of the shifts into an AND?
> > If so, how, and what has to change? And when might you want to do that?
> > Or if not, why not?
> >
> > -----
> > Rob Warnock, 31-2-510 [EMAIL PROTECTED]
> > Network Engineering http://reality.sgi.com/rpw3/
> > Silicon Graphics, Inc. Phone: 650-933-1673
> > 1600 Amphitheatre Pkwy. PP-ASEL-IA
> > Mountain View, CA 94043
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Works the md5 hash also for large datafiles (4GB) ?
Date: Wed, 18 Oct 2000 09:21:51 -0600
Sam Simpson wrote:
>
> Yes, MD5, SHA-1 etc allow input of any arbitrary length in bits.
<snip>
I know that. What I mean is, do *commonly available implementations*
actually allow that. Most that I have seen only have calls that are
given byte arrays as input. Which means, in other words, that only
inputs that are multiples of 8 bits are allowed. (Snippy comment
about other-sized bytes left out.)
JM
------------------------------
** 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
******************************
