Cryptography-Digest Digest #951, Volume #12 Wed, 18 Oct 00 13:13:00 EDT
Contents:
Re: Is it trivial for NSA to crack these ciphers? (Bob Silverman)
Re: CHAP security hole question (Vernon Schryver)
Re: Is it trivial for NSA to crack these ciphers? (John Myre)
Re: FTL Computation ("Paul Lutus")
Re: Works the md5 hash also for large datafiles (4GB) ? (Tom St Denis)
Problem with the CS-Cipher (Tom St Denis)
Re: Counting one bits is used how? ("bubba")
Efficient software LFSRs ("Trevor L. Jackson, III")
Rijndael in Perl (Tony L. Svanstrom)
Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom (Andre)
Re: CHAP security hole question ("Trevor L. Jackson, III")
Re: Efficient software LFSRs ("Trevor L. Jackson, III")
Re: How about the ERIKO-CHAN cipher? (James Felling)
----------------------------------------------------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Wed, 18 Oct 2000 15:17:18 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> On Sat, 14 Oct 2000 13:42:06 -0500, "Stephen M. Gardner"
> <[EMAIL PROTECTED]> wrote, in part:
>
> >could accomplish more
> >than a larger group of scientists working in the open
>
> Ah, but the number of mathematicians working in the open on
> cryptography is far smaller than the number working in the NSA.
This so-called fact is often quoted, but is far from the truth.
I suggest you look over the proceedings from Crypto, Euro-Crypt
and Asia-Crypt as well as some of the other conferences dealing with
crypto. COUNT the number of different authors. Also check cross-
references. The number will surprise you. The NSA/CCR does not
have anywhere close to this number of mathematicians.
--
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: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: CHAP security hole question
Date: 18 Oct 2000 09:24:18 -0600
In article <8sjbtt$2df$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> ...
>My question is on CHAP, the Challenge Handshake Authentication Protocol.
> I have found papers on the Net that publishes crpto weakness in MS
>implementation of CHAP that is based on hashed password. And there
>seems to be a freely available software based on data dictionary attack
>to explore the security hole in MS implementation. So my question is:
>Is this weakness general to CHAP itself, to just to MS implementation of
>CHAP? And is there other similar authentication or security protocol
>that provides better protection against attack than CHAP does?
> ...
MS does not have an implementation of CHAP, but a protocol that is
distinct from CHAP defined in RFC 1994. A good comparison between
MS-CHAP and the RFC 1994 standard can be found starting on page 113 of
"PPP Design, Implementation, and Debugging," second edition, by James
Carlson. Even people who are very familiar with PPP can find useful
information in Carlson's book on the PPP protocols not documented or
not fully documented in any RFC.
Carlson lists three main holes in MS-CHAP. The first is not really
a hole in MS-CHAP but the observation that it is posible to obtain
lists of passwords from Microsoft systems. Anything based on shared
secrets is no stronger than the secrecy of those secrets.
The second is that Microsoft uses a single secret to authenticate both
a source of PPP packets and access to a user account. The ability to
send PPP packets to a system is generally no worse than what can be done
to the same system through its other network connections by any random
bad guy without any secret knowledge, while access to an account is the
whole thing. Other brands of systems can distinguish the two. If a bad
guy gets a CHAP secret, all that need be compromised is IP packet access,
but an MS-CHAP secret is often useful for more serious dirty work.
The third hole is in the amazing mechanism for changing passwords
over the wire, effectively in cleartext. What more needs be said
about something like that?
I'd add a fourth hole. For years Microsoft stridently insisted that
MS-ChAP was more secure than CHAP, and incidentally had interoperability
problems with systems compliant with the open PAP and CHAP standards.
In other words, as always, beware of monopolists bearing proprietary gifts.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Wed, 18 Oct 2000 09:48:27 -0600
Bob Silverman wrote:
<snip>
> 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?
<snip>
Good question. But I doubt you'll get any satisfactory
answers. People don't seem to be able to function with
not knowing something, and often accept opinion as fact
rather than accept ignorance.
This is true in practically every area of life. Why else
would people care about political race polls? They shouldn't
mean *anything*, since we actually *choose* the winner through
voting, but people just love to "know". (This is aside from
the fact that polls tend to be self-fulfilling, because of the
bandwagon phenomenon.)
And it isn't just those who need to make plans based on some
outcome; people who will take no action one way or another
will happily debate endlessly about anything that hasn't
happened yet. Listen to a sports talk show sometime, when
the hosts are taking predictions as to the score of the local
team's next game. It isn't that people have anything on
which to base their opinions, or even that they necessarily
*have* very strong opinions. They just seem to take comfort
in having something concrete to expect - even if their
expectation is essentially baseless.
JM
------------------------------
From: "Paul Lutus" <[EMAIL PROTECTED]>
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: FTL Computation
Date: Wed, 18 Oct 2000 16:00:05 GMT
ca314159 <[EMAIL PROTECTED]> wrote in message
news:8sjvqv$hb1$[EMAIL PROTECTED]...
> > 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.
No, it does not. No matter the communications conventions, there is still a
transmitter and receiver. If you argue there really is no transmitter and
receiver, you pull the rug out from beneath your own argument.
[ snip unbelievable trash ]
> > 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 ?
You think a student who knows nothing can be blamed on the teacher. This
explains why you don't know anything. If the student doesn't know anything,
the problem is the student.
--
Paul Lutus
www.arachnoid.com
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Works the md5 hash also for large datafiles (4GB) ?
Date: Wed, 18 Oct 2000 16:20:04 GMT
In article <[EMAIL PROTECTED]>,
Runu Knips <[EMAIL PROTECTED]> wrote:
> 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.
>
Ah but I have two problems with the new SHA
1. It's gross, ugly, unbalanced and sloppy
2. Who will spend 2^128 effort to forge a message?
I personally think they should have gone for some multipermutation
structure (i.e FFT) which is suitable for low end processors.
Unbalanced structures are stupid, plus they use "nonlinear" function of
only 3 out of the 7 available chaining variables. Personally if you ar
egoing to unbalanced the structure, go all the way since a 7x1 can be
much more nonlinear then a 3x1.
Of course a 5 Layer FFT (using 16-bit mixing functions, assuming the
input is divided into 32 8-bit words) would have much higher diffusion
(assuming a multipermutation was used) and be somewhat compact in terms
of a 8-bit MCU usage.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Problem with the CS-Cipher
Date: Wed, 18 Oct 2000 16:26:27 GMT
I implemented the M-Function as described in CS-Cipher and I found that
with a prob. of 65026/65536 that any two inputs (that differ by a fixed
amount) will not be a multipermutation.
Essentially I took a 16-bit input 'x' and a difference 'y' and got 'z =
M(x) xor M(x xor y)' and counted the number of times either the low or
high byte of 'z' is zero.
Well actually I used a slightly different 'sbox' but I think the idea
holds true.
Am I mistaken or is their structure not a multipermutation?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "bubba" <[EMAIL PROTECTED]>
Subject: Re: Counting one bits is used how?
Date: Wed, 18 Oct 2000 11:44:29 -0500
You are right, I forgot that sometimes only a single bit is considered the
output.
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> 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
>
>
>
>
------------------------------
Date: Wed, 18 Oct 2000 12:45:07 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Efficient software LFSRs
This is a brief summary of a technique for implementing efficient LFSRs
in software. The mechanism involves generating successor states a word
at a time rather than a bit at a time. In order to accomplish this
parallelism inter-tap dependencies must be eliminated.
Inter-tap dependencies are visible in a state transition table as
forward references. The most effective presentation of the issue
involves a change in perspective from a single-bit update (mini-cycle)
to a full register update (maxi-cycle). A maxi cycle of an N-bit
register consists of N mini-cycles. The value of this perspective
derives from the fact that the state of a register cell after a
maxi-cycle is simply the original cell value XORed with each of the
respective tap cell values.
For a trinomial each cell's expression will be original[selfcellno ] XOR
original[ (selfcellno + tapcellno ) % N ]. A tabular example is easiest
to understand. Given a five bit register with the feedback tap at bit
zero (x^5 + x + 1) we see the following list of expressions:
<fixed width font>
Bit Expr
4' 4x0
3' 3x4'
2' 2x3'
1' 1x2'
0' 0x1'
</fixed width font>
Since the self term is a constant it can be ignored, leaving only the
differential term. This simplification makes it easier to see the
dependencies as the tap position changes:
<fixed width font>
Tap
Bit 0 1 2 3
4' 0 1 2 3
3' 4' 0 1 2
2' 3' 4' 0 1
1' 2' 3' 4' 0
0' 1' 2' 3' 4'
</fixed width font>
Any tap arrangement that has dependencies (forward references) in only
the lower (tail) half of the register can be updated with only a shift
and XOR applied to each of the two sections of the register. In the
table above tap columns 2 and 3 qualify. Thus these tap configurations
can generate five bits of output with only two shift/XOR actions. This
contrasts with the classical generators which require five shift/XOR
operations. [Note that the classical shifts are all single-bit, while
the shifts in the parallel technique are multi-bit.]
Within a 32-bit machine word there are four 31/x tap arrangements that
can produce 31 bits of output with two shifts and two XORs. The output
bitstream will be identical to that of a classical implementation or its
Galois transform.
This technique generalizes to more taps and to registers wider than a
machine word. For example, using classical methods the 521/32 tap
arrangement would require 521 shift/XOR operations plus 9*521 indexing
operations to generate 521 bits. Yet the fortuitous tap arrangement
allows 521 bits of state to be generated on a 32-bit machine with a
single shift, 9 XORs, and 9 indexing operations, which is much more
efficient. This extreme reduction is due to the fact that a 32-bit
shift is equivalent to a one-word offset.
In concrete terms this can be implemented with a 521-bit big-endian
register aligned so that the LSB falls on bit 0 of a byte. A bit of
administrative overhead updates the MSW with a shifted LSW. Then the
rest of the register is updated with reg[i] ^= reg[i+1]; or the
equivalent using a word pointer.
This parallelism technique compares well against additive generators in
that they require approximately the same amount of work (both can be
implemented as batch or incremental updates), but the additive generator
requires <wordlength> times as much space. I.e., 521 words versus 521
bits.
Additive generators using the same polynomial do have longer periods,
but they are not even close to 2^bits_of_state, while both techniques
are comfortably (ridiculously) large for practical purposes.
------------------------------
Crossposted-To: comp.lang.perl.misc
Subject: Rijndael in Perl
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Wed, 18 Oct 2000 16:47:41 GMT
Anyone that knows if Rijndael exists in Perl yet and/or if someone's
working on it?
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
on the verge of frenzy - i think my mask of sanity is about to slip
---���---���-----------------------------------------------���---���---
\O/ \O/ �99-00 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
From: Andre <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom
Date: Wed, 18 Oct 2000 16:41:14 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> On Wed, 18 Oct 2000 01:25:23 +0100, Mathew Hendry
> <[EMAIL PROTECTED]> wrote, in part:
>
> >Three of the four rotors are missing. (Why steal only those?)
Its an enigma (sic) why they'd remove the rotors .
Here's my theory why they were removed .
I suspect that it has to do with the secret Tesla files relating to
zero point energy and wireless power .
As this information was sensitive, after the end of WW2 it was
encrypted with one of these machines. (best technology available at the
time) . I suspect that the thieves knew this, as they had gotten hold
of one of the documents concerned.
Therefore, they needed the original machine that the document(s) were
encrypted on to read the documents.
This also explains why the rotors were removed.
(to allow the code wheels to be copied onto computer in order to read
any other documents they might obtain) ...
Any comments ? (apart from "are you taking your medication" ? :-) )
BTW I would *really* appreciate it if anyone could shed any light on
this particular theory ...
>
> Maybe the thief just had trouble cleaning his prints off of them?
>
> Or - since an early British newspaper article claimed that there were
> suspicions one disgruntled member of a dissident faction among the
> staff at Bletchley had engineered the theft to discredit the current
> management - perhaps the rotors will be delivered, one each, to other
> media outlets for maximum publicity.
>
> There's even the chance that removing the rotors reduced the Enigma's
> weight enough to make returning it in secret somehow easier - either
> by making it easier to carry, or because the thief was afraid postal
> authorities had been given its weight to watch for it with.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
>
--
Andre de Guerin
Email <[EMAIL PROTECTED]>
Who is "General Failure" and why is he reading my disk drive ?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 18 Oct 2000 12:53:34 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: CHAP security hole question
Vernon Schryver wrote:
> In article <8sjbtt$2df$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>
> > ...
> >My question is on CHAP, the Challenge Handshake Authentication Protocol.
> > I have found papers on the Net that publishes crpto weakness in MS
> >implementation of CHAP that is based on hashed password. And there
> >seems to be a freely available software based on data dictionary attack
> >to explore the security hole in MS implementation. So my question is:
> >Is this weakness general to CHAP itself, to just to MS implementation of
> >CHAP? And is there other similar authentication or security protocol
> >that provides better protection against attack than CHAP does?
> > ...
>
> MS does not have an implementation of CHAP, but a protocol that is
> distinct from CHAP defined in RFC 1994. A good comparison between
> MS-CHAP and the RFC 1994 standard can be found starting on page 113 of
> "PPP Design, Implementation, and Debugging," second edition, by James
> Carlson. Even people who are very familiar with PPP can find useful
> information in Carlson's book on the PPP protocols not documented or
> not fully documented in any RFC.
>
> Carlson lists three main holes in MS-CHAP. The first is not really
> a hole in MS-CHAP but the observation that it is posible to obtain
> lists of passwords from Microsoft systems. Anything based on shared
> secrets is no stronger than the secrecy of those secrets.
>
> The second is that Microsoft uses a single secret to authenticate both
> a source of PPP packets and access to a user account. The ability to
> send PPP packets to a system is generally no worse than what can be done
> to the same system through its other network connections by any random
> bad guy without any secret knowledge, while access to an account is the
> whole thing. Other brands of systems can distinguish the two. If a bad
> guy gets a CHAP secret, all that need be compromised is IP packet access,
> but an MS-CHAP secret is often useful for more serious dirty work.
>
> The third hole is in the amazing mechanism for changing passwords
> over the wire, effectively in cleartext. What more needs be said
> about something like that?
>
> I'd add a fourth hole. For years Microsoft stridently insisted that
> MS-ChAP was more secure than CHAP, and incidentally had interoperability
I believe the technical term for the superiority of MS-CHAP is "gooder" --
"plus good" for those of a classical bent. (Follow the money! ;-)
>
> problems with systems compliant with the open PAP and CHAP standards.
> In other words, as always, beware of monopolists bearing proprietary gifts.
>
> Vernon Schryver [EMAIL PROTECTED]
------------------------------
Date: Wed, 18 Oct 2000 12:59:20 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Efficient software LFSRs
"Trevor L. Jackson, III" wrote:
> This is a brief summary of a technique for implementing efficient LFSRs
> in software. The mechanism involves generating successor states a word
> at a time rather than a bit at a time. In order to accomplish this
> parallelism inter-tap dependencies must be eliminated.
>
> Inter-tap dependencies are visible in a state transition table as
> forward references. The most effective presentation of the issue
> involves a change in perspective from a single-bit update (mini-cycle)
> to a full register update (maxi-cycle). A maxi cycle of an N-bit
> register consists of N mini-cycles. The value of this perspective
> derives from the fact that the state of a register cell after a
> maxi-cycle is simply the original cell value XORed with each of the
> respective tap cell values.
>
> For a trinomial each cell's expression will be original[selfcellno ] XOR
> original[ (selfcellno + tapcellno ) % N ]. A tabular example is easiest
> to understand. Given a five bit register with the feedback tap at bit
> zero (x^5 + x + 1) we see the following list of expressions:
>
> <fixed width font>
> Bit Expr
> 4' 4x0
> 3' 3x4'
> 2' 2x3'
> 1' 1x2'
> 0' 0x1'
> </fixed width font>
>
> Since the self term is a constant it can be ignored, leaving only the
> differential term. This simplification makes it easier to see the
> dependencies as the tap position changes:
>
> <fixed width font>
> Tap
> Bit 0 1 2 3
> 4' 0 1 2 3
> 3' 4' 0 1 2
> 2' 3' 4' 0 1
> 1' 2' 3' 4' 0
> 0' 1' 2' 3' 4'
> </fixed width font>
>
> Any tap arrangement that has dependencies (forward references) in only
> the lower (tail) half of the register can be updated with only a shift
> and XOR applied to each of the two sections of the register. In the
> table above tap columns 2 and 3 qualify. Thus these tap configurations
> can generate five bits of output with only two shift/XOR actions. This
> contrasts with the classical generators which require five shift/XOR
> operations. [Note that the classical shifts are all single-bit, while
> the shifts in the parallel technique are multi-bit.]
>
> Within a 32-bit machine word there are four 31/x tap arrangements that
> can produce 31 bits of output with two shifts and two XORs. The output
> bitstream will be identical to that of a classical implementation or its
> Galois transform.
>
> This technique generalizes to more taps and to registers wider than a
> machine word. For example, using classical methods the 521/32 tap
> arrangement would require 521 shift/XOR operations plus 9*521 indexing
> operations to generate 521 bits. Yet the fortuitous tap arrangement
> allows 521 bits of state to be generated on a 32-bit machine with a
> single shift, 9 XORs, and 9 indexing operations, which is much more
> efficient. This extreme reduction is due to the fact that a 32-bit
> shift is equivalent to a one-word offset.
>
> In concrete terms this can be implemented with a 521-bit big-endian
> register aligned so that the LSB falls on bit 0 of a byte. A bit of
> administrative overhead updates the MSW with a shifted LSW. Then the
> rest of the register is updated with reg[i] ^= reg[i+1]; or the
Curse.
Proofreading failure. The update statement should be reg[i+1] ^= reg[i].
Curse.
>
> equivalent using a word pointer.
>
> This parallelism technique compares well against additive generators in
> that they require approximately the same amount of work (both can be
> implemented as batch or incremental updates), but the additive generator
> requires <wordlength> times as much space. I.e., 521 words versus 521
> bits.
>
> Additive generators using the same polynomial do have longer periods,
> but they are not even close to 2^bits_of_state, while both techniques
> are comfortably (ridiculously) large for practical purposes.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: How about the ERIKO-CHAN cipher?
Date: Wed, 18 Oct 2000 12:04:46 -0500
Yes. I think that they could.
First off the 0-5/0-5 digit split here is our old friend ADFGVX but
instead of a transposition step there is a stream addition step. The major
security then lies in your chosen stream. Assuming that the method is
known, but the key( the 20+digit number) is not there are a couple of
workable attacks. 1) squrts are not very good random streams. There are
often correlations in their digits. e or pi or trancendental numbers are
more likely to have good properties. 2) given these correlations and since
the digit stream is not transposed at all, and therefore is seperable one
can make some correlative attacks vs. the sqrt stream. I think it would be
challenging to beat, but I also think that there would be some quantity of
practical attacs vs. it. If you applied some form of simple transposition
to it at any point post conversion this would become stronger. ( such as
aligning the output of the masked stream in columns beneath the 20 digit
number, and using that as a transposition key) in that case it becomes
ADFGVX masked with a Stream. This will have some benefits. In addition
simply for compactness of output that the code's output be recombined via
the table to the numbers and letters.
[EMAIL PROTECTED] wrote:
> The ERIKO-CHAN cipher is a private-key cipher.
>
> You use the following table to encode a message:
>
> 0 1 2 3 4 5
> -+-----------
> 0|A B C D E F
> 1|G H I J K L
> 2|M N O P Q R
> 3|S T U V W X
> 4|Y Z 0 1 2 3
> 5|4 5 6 7 8 9
>
> Then you take your key, a 20-digit (or longer) integer, take its square
> root, and starting at the decimal point, you take every digit less than
> 6 until you have as many digits as are in your message. Then you
> modulo-6-add this to the digits of your message.
>
> Could the NSA crack this? Of course, with each message the key must be
> different.
>
> A variation which does not have the "different key each time" weakness
> is to start your message with a 20-digit number which is to be added to
> the key before the square root is taken. But I don't have good feelings
> about it. Unless you send the key *in* code, followed by the message.
>
> 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
******************************
