Cryptography-Digest Digest #49, Volume #12 Sat, 17 Jun 00 13:13:00 EDT
Contents:
Re: Logical attack on RSA ("Michael Brown")
Re: Cipher design a fading field? (Tim Tyler)
Re: Cipher design a fading field? (Tim Tyler)
Re: XOR versur MOD (tomstd)
Mixing Xor and Addition (tomstd)
It's About Time (JPeschel)
Announce: Catacomb 2.0.0 prerelease (Mark Wooding)
Sapphire II Stream Cipher ("Andrej Madliak")
Re: XOR versur MOD (Mok-Kong Shen)
Re: Cipher design a fading field? ("Trevor L. Jackson, III")
Re: Is Gretchen down? ("Trevor L. Jackson, III")
Re: XOR versur MOD (tomstd)
Novice: Responsible Implementation ("Cheri & Mike Jackmin")
Re: Cryptographic voting ("Trevor L. Jackson, III")
lsfrcrypt.c ([EMAIL PROTECTED])
Re: Mixing Xor and Addition ("Trevor L. Jackson, III")
Re: Mixing Xor and Addition (tomstd)
Re: lsfrcrypt.c (tomstd)
----------------------------------------------------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Subject: Re: Logical attack on RSA
Date: Sat, 17 Jun 2000 10:10:54 GMT
Hi again,
Using a derivation of my original method I have now sucessfully factored an
8 bit number into two primes and have implemented a basic method in Pascal
(my favourite language). However, it became apparent that further
modifications would be needed to the method: I overflowed a 32 bit numbere
calculating the amount of memory required for a 256 bit key.
I have completed these modifications and the result, although it can be
reduced further, is sufficient for my needs. My 64MB machine should, in
theory, be able to factor as big as 2^16384 without swapfiling. I am now
implementing this method in Pascal and should have it done some time in the
near future. Next weekend maybe. It should definately be done in three
weeks (school holidays - yay yay!).
Anyhow, that's about all. Just mainly an update on where I'm at. I still
don't know how much faster than previous factoring techniques it will be,
although I am confident it will be much faster. It has a lot of logic stuff
(1500 lines and climbing) so this may slow it down. I don't know yet.
For those of you who missed the original post, or those who saw the
original and want a quick look at my new method, here it is (roughly):
--
Let number A, in binary, ab (as in if a=3 then a=1, b=1).
Similarly let B be cd.
For example let A = 2 and B = 3 (so AB = 6 or 0110 in binary).
The product is therefore, by primary school multiplication
a b
c d
========
da db
ca cb 0
========
x4 x3 x2 x1
where the x's are the bits of the product. We know X is 0110 so
x1=0
x2=1
x3=3
x4=0
x1 is entirely dependent on the product bd, so since bd=0 we know the
following:
da*cb = dacb
= bdac
= 0
This may not seem to be important, except for the following:
1) The carry from column that has x2 is one only if da and cb are 1
2) This means that da*cb = 1
3) However, we know that dacb=0, so the carry must be zero.
This can also be obtained by deduction, in that since da+cb is odd, then
the carry must be zero as da+cb cannot be greater than 2.
Now we know the carry into column 3 is 0, so ca=x3=1. Therefore c=a=1.
At this point we can continue no further, so we must assume a value. Lets
assume b = 0. Therefore cb = 0. Using column 2 we have
da + cb = 1
da = 1
d = a = 1
We have solved the equations and know
a = 1, b = 0, c = 1, d = 1
so
A = 2, B = 3
--
The substitution we made decided which of the values A and B will take on.
With all of the numbers I have tried, there only needs to be one
substitution made in order to complete enough equations to solve for A and
B.
I am currently preparing a spreadsheet that shows this on an 8 bit number
and also explains the method in more detail. Look out for an address to be
posted in the next few days.
As an additional note, this method could be used (with minor modifications)
to factorise any equation, even with multiple factors. This would be done
using more than one substitution, probably one for each factor. Anyhow, I'm
concentrating on the factorisation of numbers that are multiples of two big
primes. Just what the doctor ordered for RSA :)
Feel free to try to implement this method in you own favourite language.
Further details on how to do this in the spreadsheet.
Enough for now.
Regards,
Michael Brown
_____________________________
/ [EMAIL PROTECTED] \
| (Remove .nospam) |
\_____________________________/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 17 Jun 2000 10:00:42 GMT
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
: Alan Braggins wrote:
:> Or at least they only accept a finite amount of input, since then we can
:> just encode the possible inputs along with the program (e.g. stick the
:> program encoding and its input on a finite length input to a Universal
:> Turing machine).
:> Which I think means my post was a valid illustration of the argument
:> someone else was making earlier, but that that argument (and my post)
:> was wrong if we include finite programs taking a potentially infinite
:> input, which we should. Rats. This is what comes of not thinking
:> carefully enough before making sci.crypt postings when bored waiting
:> for a long compile to halt....
: How can you conclude that a program accepting an infinite input halts?
: Either it stops reading input after a finite amout, or it attempts to
: read it "all". The latter is a condition that does not halt.
An infinite tape with symbols on could be "accepted" by a TM.
If the TM's first instruction is "STOP", it will still stop.
This is probably the sense in which "accept" should be read on this thread.
FWIW, I'm *not* considering potentially infinite inputs (and to do so
would be mistaken here). I'm considering a potentially infinite tape,
which is initialised to all zeros (except where the finite program lies).
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Niagra falls.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 17 Jun 2000 10:15:53 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: "Trevor L. Jackson, III" wrote:
:> The issue isn't how difficult it is to write the program, but that
:> with sufficient ingenuity it is possible to write the program. The
:> halting problem states that such a program is impossible to write,
:> even for Karnak, if the set of programs is infinite.
: There is nothing about an infinite set of programs in the actual
: theorem. If it required such a condition, that would imply that
: for any given example program P there is a deterministic method M
: that creates a program H = M(P) that will determine in finite time
: whether or not P halts. [...]
I don't think the necessity of considering unbounded programs implies
this (false) statement.
The necessity for unboundedly large programs does apperar to be present.
As Trevor said:
``However, the halting problem is typically constructed by applying a
program to itself (halting if the program it's analyzing does not).
If the lookup program is too large to apply to itself, then the
construction is impossible by the premises of the problem rather than
by the undecidable behavior.''
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ UART what UEAT.
------------------------------
Subject: Re: XOR versur MOD
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 17 Jun 2000 04:29:12 -0700
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
>Jacques Th�riault schrieb:
>
>> Is there any advantages of using XOR instead of Modulo N when
we mix a
>> random stream with plaintext.
>
>Mod 2^n addition, with n equal to the number of bits in
>a computer word, is simply done with the addition operation
>for unsigned integers. Because of the carry-overs, the bits
>of a word from the PRNG and the bits of a word from the
>plaintext are not always combined (one to one) in fixed
>pairs as is the case with xor. This complicates analysis
>at the bit level somewhat and is to be preferred in my
>humble opinion.
Not really since note that the LSB is still an 'xor'.
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Mixing Xor and Addition
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 17 Jun 2000 04:40:19 -0700
It's thought by some that mixing addition and xor operations is
a good idea (and it is) because they are different group
operations. This however is not essentially true. It's been
pointed out time and time again that the lsb is xor-linear.
Well I wrote a program to calc the equalities (a+b) == (a xor b)
for a, b { Z(256).
Out of the 32640 possible equations like the above 4373 of them
lead to equalities which represents a probability of 2^-2.89 or
about 2^-3. Essentially there is a 1/8 chance of xor and
addition modulo 256 being equal operations.
Using 10-bit words I found out of the 523776 possible equations
only 39365 of them lead to equalities, which represents a
probability of 2^-3.73 or about 1/13.
So it stands to reason the farther away from single bit values
you go the more different addition and xor become.
Food for thought.
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: It's About Time
Date: 17 Jun 2000 12:27:06 GMT
To my web site I've recently added some
cryptanalysis tools to the "Historical"
page. These tools are currently being
used in <i>The Codebook</i> contest.
They include a frequency counter, a
program for solving simple substitution
ciphers, a shift-cipher solver, and
a Playfair solver. These programs and
more can be found in the "Files" section
of the book's discussion group, so
I don't think I'm giving anything away.
I've included links on the "Contests"
page to the discussion group on Singh's
book and to <i>The Codebook</i>
leader board, which might otherwise
be known as the Gillogly tracking
page. You'll also find a link on the
"Contests" page to the NOVA "Crack the
Ciphers" page. The three ciphers are
still up, two them, I believe, haven't
been cracked.
I've also added Password Safe Cracker
to the "Key Recovery Tools" page.
I've included an executable as well
as the C source code of "Joe Smith."
Hope "Joe" doesn't mind, but at least
Joe is my real name. :-)
E-mail or post here if you have any
suggestions about what else I should
include on any of my pages.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Announce: Catacomb 2.0.0 prerelease
Date: 17 Jun 2000 14:42:25 GMT
In spite of the lack of demand ;-) I've upgraded my Catacomb
cryptography library, fixed bugs, added new ciphers, modes and other
features (and new bugs, undoubtedly). There is now a prerelease of
version 2.0.0.
In the event that anyone's interested, you can fetch the prerelease from
http://www.excessus.demon.co.uk/misc-hacks/#catacomb
The library is mostly portable. System-specific bits are provided for
Unix, although I suspect that implementing them for other systems isn't
hard.
The library is distributed in source form. Catacomb is free software;
you may modify and/or redistribute it under the terms of the GNU Library
General Public License.
-- [mdw]
------------------------------
From: "Andrej Madliak" <[EMAIL PROTECTED]>
Subject: Sapphire II Stream Cipher
Date: Sat, 17 Jun 2000 17:27:39 +0200
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Hi!
Does anybody know more about the Sapphire II Stream Cipher
(attacks, weaknesses, has been broken, etc.)?
The cipher is used in ATBASH2 package by M. J. Johnson...
Thanks in advance,
Andrej
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.5.3
Comment: Quis custodiet ipsos custodes?
iQA/AwUBOUuK1YaZUlJQw2ggEQIgfgCfdKEG4pzKlgkbRX17fPmnAiL1RYUAoM8n
X1E+WhZg2dklP+Xl/PRLLGiN
=fH3e
=====END PGP SIGNATURE=====
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: XOR versur MOD
Date: Sat, 17 Jun 2000 18:13:02 +0200
tomstd wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >Jacques Th�riault wrote:
> >> Is there any advantages of using XOR instead of Modulo N when
> we mix a
> >> random stream with plaintext.
> >
> >Mod 2^n addition, with n equal to the number of bits in
> >a computer word, is simply done with the addition operation
> >for unsigned integers. Because of the carry-overs, the bits
> >of a word from the PRNG and the bits of a word from the
> >plaintext are not always combined (one to one) in fixed
> >pairs as is the case with xor. This complicates analysis
> >at the bit level somewhat and is to be preferred in my
> >humble opinion.
>
> Not really since note that the LSB is still an 'xor'.
There is a simple, apparently less popularly known, method
of catering for that issue in my humble view, if one really
desires a better combination of two operands using naturally
available computer instructions: Rotate one operand by some
random amount and then perform addition mod 2^n.
M. K. Shen
------------------------------
Date: Sat, 17 Jun 2000 12:19:28 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Tim Tyler wrote:
> Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
> : Alan Braggins wrote:
>
> :> Or at least they only accept a finite amount of input, since then we can
> :> just encode the possible inputs along with the program (e.g. stick the
> :> program encoding and its input on a finite length input to a Universal
> :> Turing machine).
> :> Which I think means my post was a valid illustration of the argument
> :> someone else was making earlier, but that that argument (and my post)
> :> was wrong if we include finite programs taking a potentially infinite
> :> input, which we should. Rats. This is what comes of not thinking
> :> carefully enough before making sci.crypt postings when bored waiting
> :> for a long compile to halt....
>
> : How can you conclude that a program accepting an infinite input halts?
> : Either it stops reading input after a finite amout, or it attempts to
> : read it "all". The latter is a condition that does not halt.
>
> An infinite tape with symbols on could be "accepted" by a TM.
>
> If the TM's first instruction is "STOP", it will still stop.
>
> This is probably the sense in which "accept" should be read on this thread.
In principle I agree, but AB was specifically concerned with the distinction
between the set of programs plus finite inputs and the set of programs plus
potentially infinite inputs. There's little difference between a program of
bounded size accepting an unbounded input tape and program of unbounded size.
The bounded program can be a UTM and the unbounded input a machine definition,
which combination can do anything a program of unbounded size can do.
>
>
> FWIW, I'm *not* considering potentially infinite inputs (and to do so
> would be mistaken here). I'm considering a potentially infinite tape,
> which is initialised to all zeros (except where the finite program lies).
By "program" I assume you mean machine definition + inputs.
------------------------------
Date: Sat, 17 Jun 2000 12:22:49 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.firewalls,alt.privacy.anon-server,alt.privacy
Subject: Re: Is Gretchen down?
I still think you have the difficulty ordering backward. "...slap another set of
wires on
..." is a non-trivial operation when you are dealing with trans-oceanic wires. Yet in
the
digital world setting up another virtual circuit is no big deal.
Patrick Farrell wrote:
> Perhaps I grossly misunderstand the way a telegraph worked, but in my opinion
> your comparing hooking up 2 phones on an analog phone system to 2 on a digital
> system. In the first case, you just slap another set of wires on, in the
> second, you can't. (Can't as in just hooking it up won't work)
>
> Patrick
>
> "Trevor L. Jackson, III" wrote:
> >
> > Patrick Farrell wrote:
> >
> > > A telegraph signal does not fall into the same category as a high speed network
> > > device.
> >
> > Correct.
> > Duplicating telegrams required a massive amount of human effort. Rerouting or
>T'ing a
> > high speed network can be done without a man in the loop, so it's drastically
>easier.
> >
> > > Hell if you add a little impedance to a 100baseT cable it will fail,
> > > yet I saw someone stick 2 computers back to back with arcnet cards in them and
> > > put a coat hanger in between and network them.
> > >
> > > Little bit different :)
> > >
> > > Patrick
> >
> > Those who fail to learn from history are doomed to repeat it.
------------------------------
Subject: Re: XOR versur MOD
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 17 Jun 2000 09:12:32 -0700
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
>tomstd wrote:
>
>> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>> >Jacques Th�riault wrote:
>> >> Is there any advantages of using XOR instead of Modulo N
when
>> we mix a
>> >> random stream with plaintext.
>> >
>> >Mod 2^n addition, with n equal to the number of bits in
>> >a computer word, is simply done with the addition operation
>> >for unsigned integers. Because of the carry-overs, the bits
>> >of a word from the PRNG and the bits of a word from the
>> >plaintext are not always combined (one to one) in fixed
>> >pairs as is the case with xor. This complicates analysis
>> >at the bit level somewhat and is to be preferred in my
>> >humble opinion.
>>
>> Not really since note that the LSB is still an 'xor'.
>
>There is a simple, apparently less popularly known, method
>of catering for that issue in my humble view, if one really
>desires a better combination of two operands using naturally
>available computer instructions: Rotate one operand by some
>random amount and then perform addition mod 2^n.
You mean turn (a + b) into ((a <<< r) + b)?
Unless 'r' changed with each usage that would still be xor-
linear.
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: "Cheri & Mike Jackmin" <[EMAIL PROTECTED]>
Subject: Novice: Responsible Implementation
Date: Sat, 17 Jun 2000 12:26:43 -0400
I work for a small software firm that makes occasional use of encryption for
things like passwords to provide access to our product. Like many programs,
our software uses a ridiculously simple, home-brewed means of providing
encryption for those few times that we use it.
A few months ago, I discovered PGP for my personal use, read a few FAQs and
learned that my company really ought to put a little more care into its
encryption software. I took it upon myself to procure a nice little module
that could provide strong encryption for occasional use, and the responsible
thing to do would be to find a nice, robust implementation of a proven,
public-domain algorithm. How hard could it be?
Well, my boss was not really interested, so it's something I have to do on
my own time, and furthermore, we don't want to spend any money on a
commercial product, which means I have to implement it myself. I consider
myself a skilled C++ application programmer, but I am an absolute novice to
the encryption world so I went looking around for some free source code that
I could put my faith in.
I found lots of free code - Blowfish, Twofish, DES and 3DES, implemented by
various people and offered for unrestricted use, but my problem is that I
cannot really trust it. I don't mean to imply that I suspect malice on the
part of the authors, but I need to be able to understand and test the code
in order to be comfortable that it is implemented correctly. Besides, I'd
usually need to clean it up quite a bit in order to bring it to the
commercial standards of my company's code, and I've long ago learned an
uninformed clean-up process can introduce more bugs than a plague of
locusts. (Sure, most of this code is supplied with test vectors, but how
complete are they? The modules are a black box to me, and that makes me
nervous).
So, I set out to find a simple algorithm that even I could understand,
inside and out. I settled on SHA-1 because it is free, and because I have a
trusted commercial implementation of it that I can use for testing my
version, using test vectors that I develop and that I understand. SHA-1 is
great for hashing, of course, and it looked like a simple matter to apply it
in a straightforward way to generate a slow, but reliable, solution to my
problem.
Needless to say my first attempt at applying it was a grievous failure (see
"Another Beginner Question") but several members of the list were kind
enough to offer more secure means doing it. With their help, I believe I am
finally able to meet my original goals and I have started writing the code
to support it.
I guess there are two thing to be learned from this, First, I now understand
why so few companies like my own use strong encryption in their products;
they don't want to pay for it, and your average application developer is
almost certain to screw it up without some well-informed help. Second, the
assistance of the several listmembers who took the time to come forward was
invaluable to me, and I do appreciate it.
Mike Jackmin
ICQ: 43754558 or 45661022
PGP Public Key available from www.lightlink.com/critters
ID: 0x14D84603 Size: 2048/1024 DH/DSS Fingerprint:
4A4E CB75 C4A4 2585 D953 D855 FA9F 0D98 14D8 4603
------------------------------
Date: Sat, 17 Jun 2000 12:50:45 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Cryptographic voting
Distrubuted decision theory used to be a minor hobby of mine until Lani
Guinier publicized the silly ideas in the field as if they were fundamental
innovations.
The issue of a perfect voting system reduces to a pair of requirements that
are operationally incompatible The first requirement is that of auditing --
the need to insure no fraud has occurred within the voting system. The second
requirement is secrecy -- the need to insure that voting has not been
influenced pressures upon the voters outside the voting system.
The protection against external influence is typically a secret ballot. But
secret ballots create the potential for internal corruption by interfering
with the ability to audit the voting process. Due to this fundamental
conflict there cannot be a perfect voting system.
Greg wrote:
> > For goodness sakes, people could use laundry
> > tickets for money if they wanted to. Actually
> > that gives me an interesting idea about
> > cryptographic money .... I'll have to work on
> > it after I get the *cryptographic* *voting*
> > thing figured out (hint).
>
> After carefull consideration of what would be required for a voting
> system to resist fraud and tampering, I have come to the conclusion
> that given the requirements below, one cannot be made:
>
> 1. It must be secret ballot
> 2. Voters cannot be identified (by law)
> 3. Voters cannot be deduced from the votes
1-3 are all aimed at preventing external influence on the voters.
>
> 4. Votes must be verifiable (not altered) by anyone
> 5. Voters cannot vote more than once
> 6. The system requires no trust of anyone
4-6 all address the need for auditing -- eliminating the possibility of
internal corruption.
>
>
> If you think this through, you will realize that if we don't know WHO
> voted, then we don't know with any certainty how many votes we should
> see. Therefore, the system allows a person (in charge of a precinct)
> to add any number of fraudulent votes to further their agenda.
>
> Requirements 1 and 2 are by law and they stand in the way (I wonder
> why?) of a fraud proof system.
No.
> All other requirements can be met with
> trivial use of web sites, public keys, and other standard technology of
> today. I can go through the steps if anyone is interested, but under
> current law, a fraud proof system cannot be used in US elections.
There is no change to the voting laws that would permit a system that is proof
against both fraud and compulsion.
------------------------------
From: [EMAIL PROTECTED]
Subject: lsfrcrypt.c
Date: Sat, 17 Jun 2000 16:34:02 GMT
hello
a this adress http://www.visto.com/guest/fred9731
you could find a little c prog
lfsrcrypt any comment please !!!
thanks toms for the original
bye bye !!
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Sat, 17 Jun 2000 12:52:54 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Mixing Xor and Addition
Raw counts aren't indicative. To make a useful metric you'd have to weight
the difference by the Hamming distance between the results.
tomstd wrote:
> It's thought by some that mixing addition and xor operations is
> a good idea (and it is) because they are different group
> operations. This however is not essentially true. It's been
> pointed out time and time again that the lsb is xor-linear.
> Well I wrote a program to calc the equalities (a+b) == (a xor b)
> for a, b { Z(256).
>
> Out of the 32640 possible equations like the above 4373 of them
> lead to equalities which represents a probability of 2^-2.89 or
> about 2^-3. Essentially there is a 1/8 chance of xor and
> addition modulo 256 being equal operations.
>
> Using 10-bit words I found out of the 523776 possible equations
> only 39365 of them lead to equalities, which represents a
> probability of 2^-3.73 or about 1/13.
>
> So it stands to reason the farther away from single bit values
> you go the more different addition and xor become.
>
> Food for thought.
>
> Tom
>
> Got questions? Get answers over the phone at Keen.com.
> Up to 100 minutes free!
> http://www.keen.com
------------------------------
Subject: Re: Mixing Xor and Addition
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 17 Jun 2000 09:57:32 -0700
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
>Raw counts aren't indicative. To make a useful metric you'd
have to weight
>the difference by the Hamming distance between the results.
I could do that too, I just felt counting equalities as a good
idea...
Tom?
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: lsfrcrypt.c
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 17 Jun 2000 09:59:49 -0700
[EMAIL PROTECTED] wrote:
>hello
>
>a this adress http://www.visto.com/guest/fred9731
>you could find a little c prog
>lfsrcrypt any comment please !!!
>
>thanks toms for the original
>bye bye !!
My original source was ok, but the polynomial was invalid. You
have to make sure that the ones you pick are ok.
Also this appears to be a shrinking generator which the best I
know should be secure if the polynomials are dense.
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
** 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
******************************
