Cryptography-Digest Digest #520, Volume #12 Thu, 24 Aug 00 01:13:00 EDT
Contents:
Provably secure stream cipher ([EMAIL PROTECTED])
Re: The DeCSS ruling (Barry Adams)
How to add 96 bits of key to DES ([EMAIL PROTECTED])
Re: How to add 96 bits of key to DES ([EMAIL PROTECTED])
A few big primes? (Michael Brown)
Re: SHA-1 program (cool!) (Benjamin Goldberg)
Re: Comment from Hardware Experts Please (Mack)
Re: blowfish problem ("Spud")
Re: A few big primes? ([EMAIL PROTECTED])
Re: Crypto Coprocessor on Javacard (Mack)
Re: Re-using CD-R discs (Mack)
Re: Testvectors for DES and 3xDES (Hideo Shimizu)
Re: blowfish problem ("Spud")
Re: Provably secure stream cipher ("Alexis Machado")
Re: New algorithm for the cipher contest (Mack)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Provably secure stream cipher
Date: Thu, 24 Aug 2000 03:13:36 GMT
Here is an idea for a somewhat slow provably secure (as long as the
underlying prng is statistically random, but need not wholely random).
Based (yet again) on the simple pair-wise decorrelated function
f(x) = ax + b
in GF(2^n) (n = 8, 32, 64 ...)
The idea is that the prng will make the (a, b) values for each 'x' that
is being encrypted. Since this is pairwise decorrelated and the values
(a, b) are made anew with each output this is provably secure if the
stream (a, b) is not guessable (in this case without any known stream).
The only big flaw is that if the attacker sends a stream of zeroes into
the cipher 'b' will be recovered. Any ideas? I could change it to be
f(x) = a(x + b) + c which would make the attack impossible to exploit,
but this requires three clockings per output...
And I was thinking of primarly doing this in GF(2^8) where the
multiplicative inverses could be stored in a LUT.
I think the prng could be a simple lagged fibonacci generator say
(83,258) or something... The key schedule could be a 16 -> 258 type
function using a 16 stage LFSR as the expansion function
Any comments please?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Barry Adams <[EMAIL PROTECTED]>
Subject: Re: The DeCSS ruling
Date: 23 Aug 2000 22:33:13 -0500
On Wed, 23 Aug 2000 12:38:50 -0400, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
>Jim Steuert wrote:
>> What about just plain curiosity? Can that be a legal reason for
>> reverse engineering?
[ About the legality of reverse engineering programs]
>Should it be? Suppose you're curious what's in somebody's
>house -- should that be a legal excuse for entering without
>permission?
Thats a totally unapt analogy, if they a sell a device or software
to be installed in my house or my computer, then i should have every
right to know exactly what its doing, for my own security.
>Unfortunately this legal case seems to have involved both
>a possible intent to cause malicious mischief or abet
>criminal activity (theft), and the more intellectual issue
>of right to attack cryptosystems. One way to look at the
>latter is that the DVD vendors chose to use a difficult
>puzzle (CSS) as their primary means of protecting their
>rights to control use of their property. It's much like
>depending on a lock to keep people out of one's house --
>it keeps unskilled honest people out, but provides little
>protection against skilled people and career criminals.
Once again a totally unapt analogy. CSS does not
even protect against coping. So we not even talking
about software/media copyright "theft". What CSS does
it prevent a DVD I have bought from running on any player
that is not made by a manufacturer with an licease. I see
absolute no legal president as to way the should have such
a right over media i have legally optained.
Funny enough DeCSS isn't actually the threat the movie industries
power grab, what is the fact that many players which bypass the
regional lock have been made available for sale (include the
playstation 2)
>We use other means such as social and legal sanctions to
>address the latter.
Quid custodes ipso custodian
------------------------------
From: [EMAIL PROTECTED]
Subject: How to add 96 bits of key to DES
Date: Thu, 24 Aug 2000 03:37:00 GMT
Here's a neat trick that takes normal 16-round DES and adds 96 bits to
the key.
Change all the sboxes from "y = S1(x)" to
y = (c(S1((ax + b) mod 64)) + d) mod 16
Where a,b are in {0,1}^6 and c,d are in {0,1}^4.
Each sbox can have log2((64)(63) + (16)(15)) bits of entropy added
since the values (a,b,c,d) can be anything except that (a,c) cannot be
zero.
Since the inputs into the second decorrelation simply (cx' + d) are not
known the function should (?) be secure from standard diff/linear
attacks.
And this does not slow down standard des since the sboxes can be
precomptuted with this in mind.
Please comment.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How to add 96 bits of key to DES
Date: Thu, 24 Aug 2000 03:59:04 GMT
In article <8o258q$a3g$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Here's a neat trick that takes normal 16-round DES and adds 96 bits to
> the key.
>
> Change all the sboxes from "y = S1(x)" to
>
> y = (c(S1((ax + b) mod 64)) + d) mod 16
>
> Where a,b are in {0,1}^6 and c,d are in {0,1}^4.
>
> Each sbox can have log2((64)(63) + (16)(15)) bits of entropy added
> since the values (a,b,c,d) can be anything except that (a,c) cannot be
> zero.
>
> Since the inputs into the second decorrelation simply (cx' + d) are
not
> known the function should (?) be secure from standard diff/linear
> attacks.
>
> And this does not slow down standard des since the sboxes can be
> precomptuted with this in mind.
>
> Please comment.
Duh, I can't add sorry. There is (6+6) bits of input key and (4+4)
bits of output material... so the key is really 216 bits of key
material... or more exactly log2(63*64*15*16) ~
19.8841705191084349996735055785647.
Sorry.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Michael Brown <[EMAIL PROTECTED]>
Subject: A few big primes?
Date: Thu, 24 Aug 2000 16:17:08 +1200
Hi there,
I was wondering where I could pick up a few big primes (Around 256-512
bits), preferably in an easy to read (ie hexidecimal or raw binary, not
decimal or BCD) format. Alternatively, how to programs like PGP generate
primes? Then I could do a DIY job of it.
One other thing, how, umm "random" is about as close as I can get, is
the distribution of bits in a prime. What I mean is that, on average
over a thousand or two random primes, is the probobility of any
particular bit being on approximately 50%. Or does the chance of it
being on (ie 1) increase/decrease with the length of the prime and the
bit number in the prime. Sorry if this makes no sense. It's just a quick
thought I had.
Thanks in advance,
Michael
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: SHA-1 program (cool!)
Date: Thu, 24 Aug 2000 04:29:30 GMT
Mack wrote:
[snip]
> Also check the method of appending the length code.
>
> You may be overwriting data with the length or vice versa.
> Or you may be overwriting the low 32 bits of the length with
> the high 32 bits. Also possible is not shifting properly since
> the 'normal' word size is 32 bits and the length is 64 bits
> and expresses the total length of data in bits.
Also, it might be a good idea to keep track of the number of *blocks*
processed, up till the very end, rather than the number of bytes or
bits; You have to do fewer additions this way, and can shift the
appropriate amounts during the finishing step.
--
"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: [EMAIL PROTECTED] (Mack)
Subject: Re: Comment from Hardware Experts Please
Date: 24 Aug 2000 04:30:46 GMT
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Mack) wrote:
>> >My question is about performming a hardware multiplication in GF(2^n)
>> >modulo an appropriate primitive polynomial. Sorry if my questions
>> >seems vague, I am not a hardware expert.
>> >
>> >Generally I have two questions:
>> >
>> >1. Can it be done with relatively low amounts of hardware. I.e
>> >cheaper unit. Low power as well.
>> >
>> >2. Can it be done with a relatively high output rate. Relative to
>> >what I am not sure, i.e can it be done quickly? Say something close
>to
>> >nlog n steps?
>>
>> lets see.
>>
>> Note that Bits is a class
>> of bit strings with operation ^ and <<
>> and functions zero,bit and log 2
>>
>> Bits mulpol(Bits X,Bits Y,Bits M)
>> {
>> int n,i;
>> Bits R;
>>
>> n=M.log2();
>> R.zero();
>> for (i=0;i<N;i++)
>> {
>> if (Y.bit(i)) R=R^X;
>> X=X<<1;
>> if (X.bit(n)) X=X^M;
>> }
>> return R;
>> }
>>
>> let me know if I have it wrong but that
>> seems like the algorithm to me.
>>
>> for 64 bits it can be simplified
>> note that the highest bit of M is dropped
>> this assumes a type equivalent to U64
>> and corresponding operations
>>
>> #define U64 unsigned long long
>>
>> U64 mul64(U64 X,U64 Y,U64 M)
>> {
>> int i;
>> for (i=0;i<63;i++)
>> {
>> if ((Y&(((U64)1)<<i)!=0) R^=X;
>> if ((X&(0x8000000000000000))!=0) X=(X<<1)^M;
>> else X<<=1;
>> }
>> if ((Y&(0x8000000000000000))!=0) R^=X;
>> return R;
>> }
>>
>> >
>> >I want to design a 128-bit block cipher using decorrelation in eight
>> >rounds, this requires a 64-bit GF multiply which is very costly in
>> >software. In hardware this cipher would require 1024 bits of SRAM
>but
>> >this could be fed into the unit any way (i.e fed into latches in the
>> >execution pipeline), and if the GF multiply is efficient in hardware
>> >then the cipher could be practical for real usage.
>>
>> In hardware you have a trade off in speed and silicon usage.
>>
>> you can use a single shift register (fixed shift) and one bit
>selector and
>> two xor units (both bit controlled) with a 6 bit counter.
>>
>> or you can use 64 shift registers (fixed shift) and 64 xor units
>> all of them bit controlled and 64 polynomial division units.
>>
>> Note that the polynomial division units take a LOT of silicon.
>
>Hmm thanks for the info. Wouldn't it be possible to speed up the
>routine by pipelining it such that as one quantity is being xor'ed to
>the result the next 'shift' value is being found?
>
>Tom
>
Yes.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: "Spud" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Wed, 23 Aug 2000 21:38:59 -0700
[snips]
"Kaz Kylheku" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >CHAR_BIT == 8
> >Value = 32
> >Type holding value == char
> >
> >That is, char val = 32; under the text above tells us that the value 32
is
> >represented by CHAR_BIT * sizeof(char) bits, which, in this case, is 8.
So
> >far so good. What's the size of char in bytes? Well, on the
hypothetical
> >implementation I'm examining, it _should_ be 0.5 - but the standards
decree
> >that, in fact, sizeof(char) is 1. It still only occupies half the byte,
> >though.
>
> That's fine; thanks to padding bits, it can have a smaller range than what
the
> occupied storage allows.
>
> >Still nothing indicating that bytes and chars are, by definition or
> >otherwise, precisely the same size; only that chars must fit in bytes.
>
> Every C object, other than a bitfield, has a memory representation that
> is some multiple of one byte.
>
> The bits that make up the representations of integral types are divided
> into value bits and padding bits.
>
> The character types have representations that fit into one byte.
>
> The type unsigned char has no padding bits.
>
> Therefore, the type unsigned char uses all of the bits of the byte that it
> is stored in.
No, no, no, and NO. Watch.
> Every C object, other than a bitfield, has a memory representation that
> is some multiple of one byte.
Right; both unsigned char and byte, as discussed on this implementation, are
size 1.
> The bits that make up the representations of integral types are divided
> into value bits and padding bits.
>
> The character types have representations that fit into one byte.
Right; and an 8-bit char fits quite handily in a 16-bit byte, with room to
spare.
> The type unsigned char has no padding bits.
Right. The byte, however, does.
> If the byte is 16 bits wide, that is, CHAR_BIT is 16,
No, the byte is 16 bits, char is 8 bits, CHAR_BIT is 8. There has *still*
been *no* indiciation offered anywhere that byte and char are neessarily the
same size (other than the determination that sizeof(char), measured in
bytes, evaluates to 1 - which is true of the implementation I discussed).
> then UCHAR_MAX must be 65535.
Or 255, as discussed earlier - unless one *assumes* that char and byte are
the same size in bits - the very point under discussion. I can't find that
laid out in the standard, nobody's so far pointed it out, so simply assuming
it to be true doesn't seem to help.
> >unsigned int x = 32; /* assume 32-bit int */
> >unsigned char *ptr = &x;
> >
> >Under my hypothetical implementation, x could be aliased by ptr, without
> >holes, as 4 elements: *ptr, *(ptr+1), etc. No inconsistency involved.
Nor
>
> No etc. Just *ptr and *(ptr+1).
But that would _only_ be the first 16 bits under the implementation I
discussed, because CHAR_BIT is 8.
> Since in the hypothetical implementation,
> bytes are 16 bits wide, then the 32 bit int object takes only two bytes
Hmm... but sizeof(char) is 1, CHAR_BIT is 8, so therefore we have the
situation that a 32-bit int is 4 chars but 2 bytes wide? I don't think so.
> (assuming it has no padding). So *ptr refers to 16 bits of it,
> and *(ptr + 1) to the other 16 bits.
But when addressed as discussed, since CHAR_BIT is 8, *(ptr+1) only
evaluates 8 bits, not 16.
> >> 6.2.6.2 Integer types
> >>
> >> [#1] For unsigned integer types other than unsigned char,
> >> the bits of the object representation shall be divided into
> >> two groups: value bits and padding bits (there need not be
> >> any of the latter).
> >>
> >> In other words, unsigned integer types may have padding bits, but
unsigned
> >> char must not have any. It uses all the available bits in the
underlying
> >byte.
> >
> >No; it says except for _unsigned char_, there shall be two groups; it
says
> >nothing about the bytes.
>
> Yes it does. That's what ``bits of the object representation'' is all
about.
> The bits of the object representation are divided into bytes.
"If there are N value bits..." Nope. Still not a thing in there that
says my proposed implementation isn't conforming. Why? Simple; unsigned
char has no padding bits, missing bits, anything of the sort. Further,
another type (say unsigned long) can be aliased by this implementation
without introducing holes, padding bits, or anything else - because while
the _byte_ is 16 bits, the aliasing isn't dony byte-by-byte but unsigned
char-by-unsigned char. Still no help in answering the question.
> There
> are n*CHAR_BIT of these bits in an object that is n bytes big.
>
> >There's an underlying assumption being made in this discussion that chars
> >and bytes are synonymous.
>
> There is no such assumption. The assumption is that *unsigned char*
> and byte are roughly synonymous, at least in the sense that the type
unsigned
> char provides a logical a way, thorugh a binary enumeration, to access
> every bit of a byte of storage.
That's a hell of a big assumption. As I keep pointing out, the
implementation I propose seems to be, from everything I read in the draft,
conforming, and not a single argument listed so far contradicts that; the
few that seem to all make the failing of _assuming_ that equivalency. In my
implementation, the type unsigned char provides a logical way to access
every bit of an _object_, just not a _byte_.
> The two correspond so neatly that it's
> easy to substitute one for the other in many discussion contexts without
> loss of clarity or precision.
Except as I noted; the fact that the equivalency does not seem to actually
be delineated, either explicitly or implicitly, by the draft document, means
there is a hole in the document. While it's true that any sane
implementation will regard byte and char as equivalent, I see no guarantee
that this is, in fact, the case. All I ask is that you, or someone more
familiar with the matter, actually provide this assurance.
> >Note that it remains lossless - from the C implementation's point of
view -
> >even if the distinction between byte and char is maintained; the fact
that
> >it actually loses data, because the implementation regards chars as 8
bits,
> >but the data coming in is doing so in 16-bit bytes, is irrelevant...
except
> >that it means you cannot safely read any files written by any programs on
> >this machine other than those written by programs compiled with this
> >compiler.
>
> A C stream records data in the same bytes that are used for the
representation
> of data objects.
> A file of 16 bit bytes would have to be converted to an 8 bit
> file before being processed by a C implementation with 8 bit bytes.
Okay, I don't see how that comes about. You seem to be treating it as you
would treat the case of reading 32-bit ints when your native setup only has
16-bit ints; that is, read them in in chunks and process accordingly. With
ints, that makes sense... with chars, it may not.
Example: on the hypothesized implementation, the native character set is 12
bits wide; anything beyond that simply gets truncated to 12. So when the C
program reads in a char, what is it reading? Well, it can't be the full
12-bit wide value, nor the 16-bit byte; the C implementation only has an 8
bit char. So we're left with the situation of having to read _two_ chars,
that is, making _two_ calls to fgetc(), in order to retrieve a _single_
character from the file. Either that, or the C compiler can choose another
alternative, such as discarding (truncating, for example) anything outside
the range of a char.
Now all that seems to be entirely legal. Nothing said so far even _hints_
that it's not... nor does anything said so far even _hint_ that chars and
bytes really are synonymous; what we keep seeing is the assumption that this
is true, and what happens if we assume that it is true. I'm examining what
happens if we _do not_ assume it is true, and bad things happen... but I
cannot find any assurance that, in fact, this equivalence *is* true.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: A few big primes?
Date: Thu, 24 Aug 2000 04:41:03 GMT
In article <[EMAIL PROTECTED]>,
Michael Brown <[EMAIL PROTECTED]> wrote:
> Hi there,
>
> I was wondering where I could pick up a few big primes (Around 256-512
> bits), preferably in an easy to read (ie hexidecimal or raw binary,
not
> decimal or BCD) format. Alternatively, how to programs like PGP
generate
> primes? Then I could do a DIY job of it.
>
> One other thing, how, umm "random" is about as close as I can get, is
> the distribution of bits in a prime. What I mean is that, on average
> over a thousand or two random primes, is the probobility of any
> particular bit being on approximately 50%. Or does the chance of it
> being on (ie 1) increase/decrease with the length of the prime and the
> bit number in the prime. Sorry if this makes no sense. It's just a
quick
> thought I had.
>
Perhaps you wanted to ask about "The distribution of primes" within a
specific range say 10^100 -> 10^250 generated by a given algorithm.
Unfortunately that is a subject I am not at all familiar with.
I know that if you want to make primes just do this
1. Make up random n bit odd integer
2. Trial division of primes from 2 to 521
3. Do five or more Rabin-Miller loops
This is all explained in various places such as Schneier's Applied
Crypto.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Crypto Coprocessor on Javacard
Date: 24 Aug 2000 04:50:41 GMT
>>
>> The assymetry in the times suggests that the GPK400 has not been corrected
>> for some of the more recent attacks on small public keys.
>>
>
>What kind of attack do you mean - could you point me to some papers?
>
>thanks
>Tom
>
>> Mack
>> Remove njunk123 from name to reply by e-mail
>
>
The attack is based on small public keys. IIRC the
public key should be > about 1/4 of the modulus.
For a general safety recommendation 1/3 should be
sufficient.
I don't have any specific references for it but it was
fairly recent.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Re-using CD-R discs
Date: 24 Aug 2000 04:53:38 GMT
><<I have no doubt that there is some temperature sufficiently
>high to erase the CD-R.>>
>
>14 billion degrees ought to do it, no?
>
>"To erase, add one supernova"
>
>-*---*-------
>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! :->
>
>
About 1000 celcius is more than sufficient.
Only takes a carbon arc furnace.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Hideo Shimizu <[EMAIL PROTECTED]>
Subject: Re: Testvectors for DES and 3xDES
Date: Thu, 24 Aug 2000 13:44:36 +0900
See my page, http://www.yokohama.tao.go.jp/shimizu/des_test.html
Hideo Shimizu
TAO, Japan
kihdip wrote:
>
> Has somebody knowledge of a site with testvectors for DES and 3xDES ??
>
> Thanks
> Kim
------------------------------
From: "Spud" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Wed, 23 Aug 2000 21:55:43 -0700
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Kelsey Bjarnason wrote:
> > Nope; neither of those do it. #2 refers to the size "in bytes";
> > if a "byte" on the implementation is 16 bits, but a char 8, the
> > implementation is still free to refer to both as having size 1.
>
> No, because a char has no padding bits.
So? A char doesn't _have_ to have padding bits for this to hold true.
Byte: 16 bits
char: 8 bits, no padding
sizeof(char): 1
> Whatever a "byte" is,
> the fact that a char has size precisely 1 byte means that every
> bit of the byte is used in the representation for type char.
No, it means that every bit of the _char_ is used; unless and until it is
shown that a byte _cannot_ be bigger, physically, than a char. As long as
sizeof(char) still evaluates to 1, and as long as the _char_ has no unused
bits, all of what you say above still holds true - despite the _byte_ having
more bits than the char.
> Keep in mind that I'm not guessing -- if there is ever any
> reason to request an official interpretation on this point,
Well, here's a reason: it's not specified by the document, and as I've
pointed out in a couple of different places, unless it is specified, some
*very* nasty things can potentially occur. See the issue of reading files
written by a Pascal program which _does_ use 16 bit chars, then being read
by a C program which uses 16 bit bytes but 8 bit chars. I still see nothing
to indicate that this isn't perfectly legal.
> you *will* be informed by the committee that every "active"
> bit of a byte (that is, every bit that might be used in the
> representation for some object type) is accessible via
> aliasing to type (unsigned) char.
I'm sure that is, indeed, the intent. However, at least from the draft, you
_cannot_, apparently, show that this is, in fact, guaranteed to hold true.
All you can know for sure about the representation of them is that a char
can fit "in" a byte - and as I've pointed out, an 8 bit char fits "in" a
16-bit byte quite well.
>We have already affirmed
> that on numerous occasions. Thus, memmove can be used to
> copy any object (if you know its size), even though it is
> specified (in C89 at least; my copy of C99 is not at hand)
> as operating on arrays of "characters" (objects of type char).
Right... of chars. As I've already pointed out, though, memcpy could
*still* continue to work as documented under this implementation. Where all
hell breaks loose is in doing things such as accessing files written by
programs.compiled by another language compiler, or even another C compiler
on the same machine, but one which _does_ assume that char and byte are
equivalent.
If the committee means for chars and bytes to be equivalent... that a
conforming compiler _cannot_ use 16 bit bytes and 8-bit chars, the document
should probably say so. As it stands, all the issues brought up - aliasing
types via arrays of unsigned char, no padding in unsigned char, memcpy,
etc - would *still* continue to work on such an implementation; data
storage, however, would _only_ continue to work if the _only_ programs
accessing the data files were ones written with this specific compiler.
Now ponder for a moment that if this is _not_ documented to be the case,
that doing something as basic as reading a file becomes an excercise in
futility. What does fgetc() return? Currently, it's an unsigned char
converted to int, representing the value read (or an EOF), but under the
conditions I discussed, fgetc would have to return either halfbytes - where
it takes two calls to fgetc() to retrieve a single byte from the file - or
it has to truncate the data being read so it will fit in an unsigned char.
Neither seems a good idea - and it's all totally avoidable by simply making
it explicit that yes, byte and char are in fact equivalent.
Again, I know this is a largely pedantic issue... but it is, nonetheless, an
apparent hole in the draft, at least.
------------------------------
From: "Alexis Machado" <[EMAIL PROTECTED]>
Subject: Re: Provably secure stream cipher
Date: Thu, 24 Aug 2000 01:59:25 -0300
<[EMAIL PROTECTED]> wrote in message news:8o23sj$89h$[EMAIL PROTECTED]...
> Here is an idea for a somewhat slow provably secure (as long as the
> underlying prng is statistically random, but need not wholely random).
>
> Based (yet again) on the simple pair-wise decorrelated function
>
> f(x) = ax + b
>
> in GF(2^n) (n = 8, 32, 64 ...)
>
> The idea is that the prng will make the (a, b) values for each 'x' that
> is being encrypted. Since this is pairwise decorrelated and the values
> (a, b) are made anew with each output this is provably secure if the
> stream (a, b) is not guessable (in this case without any known stream).
>
> The only big flaw is that if the attacker sends a stream of zeroes into
> the cipher 'b' will be recovered. Any ideas? I could change it to be
>
> f(x) = a(x + b) + c which would make the attack impossible to exploit,
> but this requires three clockings per output...
>
> And I was thinking of primarly doing this in GF(2^8) where the
> multiplicative inverses could be stored in a LUT.
>
> I think the prng could be a simple lagged fibonacci generator say
> (83,258) or something... The key schedule could be a 16 -> 258 type
> function using a 16 stage LFSR as the expansion function
>
> Any comments please?
>
Let your RNG be the function g. Then try:
f(x) = g(a + x) + b
or
f(x) = g(a xor x) xor b
Normally, the RNG function do multiplications between the input and the
state variables.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: New algorithm for the cipher contest
Date: 24 Aug 2000 05:07:33 GMT
>
>Oh, by the way, could someone please stop Tom from being so obnoxious?
>
>-- [mdw]
>
>
>
Tom is not as obnoxious as some of the others that
are here now were when they first started. I won't
list any names. But many are now very civil.
Annoying to those that disagree with him yes.
Obnoxious not very. Nothing seriously wrong with
that. It is human nature.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
** 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
******************************
