Cryptography-Digest Digest #926, Volume #10 Wed, 19 Jan 00 03:13:01 EST
Contents:
Re: LSFR (Rob Largent)
Re: New Crypto Regulations (Mike McCarty)
Re: RSA survey (Tom St Denis)
Re: RSA survey (Tom St Denis)
Re: LSFR (Rob Largent)
Re: New Crypto Regulations (Guy Macon)
Re: New Crypto Regulations (Guy Macon)
Re: RSA survey (NFN NMI L.)
Re: NTRU Cryptosystems Inc. ("Scott Fluhrer")
Re: ECC vs RSA - A.J.Menezes responds to Schneier (DJohn37050)
Re: Java's RSA implimentation (Bill Unruh)
Re: New Crypto Regulations [off-topic] (David Hopwood)
----------------------------------------------------------------------------
From: Rob Largent <[EMAIL PROTECTED]>
Subject: Re: LSFR
Date: Wed, 19 Jan 2000 13:58:15 +1100
Reply-To: [EMAIL PROTECTED]
Hi Terje,
This is a very clever way of approaching the problem!
Regards,
Rob
Terje Mathisen wrote:
>
....
>
> You have another quite simple approach:
>
> Use a carry-save adder!
>
> This doubles the amount of storage needed, but the electronics becomes
> dead simple:
>
> Each stage of the counter will have two inputs:
>
> carry_in and data_in
>
> and it will generate two outputs:
>
> carry_out and data_out
>
> The truth table is obvious:
>
> carry_in 0 0 1 1
> data_in 0 1 0 1
>
> carry_out 0 0 0 1
> data_out 0 1 1 0
>
> I.e. carry_out = data_in AND carry_in, data_out = data_in XOR carry_in
>
> To sample this counter, just read both the data and carry array, and add
> them together.
>
> To do this in sw for a 64-bit counter I'd use code like this:
>
> static u64 data, carry;
>
> void increment(void)
> {
> u64 temp_carry;
>
> // Generate the new carry array:
> temp_carry = data & carry;
>
> // Generate the next state of the data array:
> data = data ^ carry;
>
> // Shift up the carry array and set the bottom bit, ready for the next
> iteration:
> carry = (temp_carry << 1) | 1;
> }
>
> So, to generate this counter, you'll need to use a single two-input XOR
> and a similar two-input AND gate, with the bottom bit of the carry array
> hardwired to shift in '1' bits.
>
> The latches needed to be able to read out the current value of the
> counter will take more hardware than the counter itself, but this is
> true for the LFSR approach as well.
>
> Terje
>
> --
> - <[EMAIL PROTECTED]>
> Using self-discipline, see http://www.eiffel.com/discipline
> "almost all programming can be viewed as an exercise in caching"
--
________________________________________________
Robert Largent
Manager, Design Assistance Division
Photovoltaics Special Research Centre
University of New South Wales, Sydney, Australia
[EMAIL PROTECTED] http://www.pv.unsw.edu.au
------------------------------
From: [EMAIL PROTECTED] (Mike McCarty)
Subject: Re: New Crypto Regulations
Date: 19 Jan 2000 02:54:20 GMT
In article <[EMAIL PROTECTED]>,
wtshaw <[EMAIL PROTECTED]> wrote:
)In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
)<[EMAIL PROTECTED]> wrote:
)
)> John Savard wrote:
)> > Democracy in the United States may have a bad cold, but it isn't
)> > terminal.
)>
)> To the extent that people think a democracy is desirable,
)> the US ideal of government that promotes individual rights
)> has already died.
)
)It is not dead as long as so many see it as a live promise that must be
)kept. If there is no hope there is no life. If some feel they have won
)is destroying what people will go into battle for, they have
)underestimated their adversaries, us.
What he meant was, IIUC, that so long as people continue to think that
democracy is desirable, there is no hope for this country. And I agree.
This country was founded as a REPUBLIC. We need to stop treating it as
a democracy, and work to restore the republic.
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel <- They make me say that.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RSA survey
Date: Wed, 19 Jan 2000 03:43:18 GMT
In article <863103$[EMAIL PROTECTED]>,
"Tommy Lacroix" <[EMAIL PROTECTED]> wrote:
> Considering that the government says that 1024 should be safe enough,
I
> would go for 8192 bits or longer (I always go a few times over
government
> recommendation, except when they say 0 .. =o)
The only problem here is like symmetric ciphers, the TIME/SPACE
required for n-bit RSA keys is not 8 times less that of 8n-bit RSA keys.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RSA survey
Date: Wed, 19 Jan 2000 03:44:45 GMT
In article <[EMAIL PROTECTED]>,
lordcow77 <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (NFN NMI L.) wrote:
> > 4096 bits. 8192 would make me feel better, though.
> > S.T.L.
>
> You're absolutely clueless. A 1024 bit modulus is more than enough.
Apparently so. I would say 1024 as well...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Rob Largent <[EMAIL PROTECTED]>
Subject: Re: LSFR
Date: Wed, 19 Jan 2000 14:43:43 +1100
Reply-To: [EMAIL PROTECTED]
Hi Scott,
This is interesting. I showed your post to my wife who
is also an engineer. She works on finding patterns in
data (she usually looks at hex dumps). Here response after
4 seconds was that it was funny that all the others bit lengths
that use four taps (e.g., 102 bits) had the properties of having
the last two taps (e.g., 36 & & 35 for 102 bits) being either
consecutive number or varying in value by 2 or 3 (e.g., taps
101 & 99 for 128 bits)--and--that none of them seemed to have
just a single tap number stuck way out at number 5 as you
have indicated is correct for 102 bits.
"102,101,36,35 isn't maximal length - probably
should have been 102,101,36,5 which is maximal."
Do you have any idea why 102 seems to be unusual?
and
Now that you've triggered my curiosity about this, do you have
any references on how to determine if the tap values for large bit
value LFSR's are indeed maximal? I've always just trusted the
tables.
Regards,
Rob
Scott Nelson wrote:
>
> On Fri, 14 Jan 2000 Robert Largent <[EMAIL PROTECTED]> wrote:
> [big snip]
> >...
> >If you are interested in lfsr, a very nice Application
> >Note with all of the taps listed for maximum-length
> >lfsr up to 168 bits can be found at
> >http://www.edtn.com/scribe/reference/appnotes/md000769.htm
> >
> An interesting read.
>
> I note there's an error in the table.
> (probably a transcription error)
> 102,101,36,35 isn't maximal length - probably
> should have been 102,101,36,5 which is maximal.
>
> All the others seem to be correct.
>
> Scott Nelson <[EMAIL PROTECTED]>
--
________________________________________________
Robert Largent
Manager, Design Assistance Division
Photovoltaics Special Research Centre
University of New South Wales, Sydney, Australia
[EMAIL PROTECTED] http://www.pv.unsw.edu.au
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: New Crypto Regulations
Date: 18 Jan 2000 23:17:54 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(wtshaw) wrote:
>
>In article <860cil$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Guy
>Macon) wrote:
>
>> In article <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] (wtshaw) wrote:
>> >
>> >Here is my simple proposed regulation: If you know a county or individual
>> >is on unfriendly terms with our country, is on a list as an enemy or
>> >realistic potential enemy, do not trade, sell, or funinsh any information
>> >to them. If they are publically defined as bad kind of folks, you will be
>> >in big trouble under laws against trading with an enemy and may even be
>> >punished as a traitor, conspiring to help known criminals as you become
>> >one yourself, or acting really, really stupid for which you will be
>> >publically denounced as as stupid as would any offical caught with their
>> >pants down. If in doubt, the government should be able to tell you the
>> >status of the intended receiver, investigate the threat for you, or become
>> >a direct party in the transaction so as to catch them redhanded.
>> >
>>
>> Alas, a case can be made that such barriers support despots and hurt
>> the common people who are under their tyranny.
>
>That twist is mere rationalization for doing wrong if used. Justice
>require using good sense, which is at the root of the situation in the
>first place.
I disagree with your logic. You are begging the question; if you
assume that laws such as you propose do not support despots and do
not hurt the common people who are under their tyranny, then it may
be "rationalization", but if laws such as you propose do indeed
support despots and hurt the common people who are under their
tyranny, then it is you that are guilty of "rationalization". You
can't assume that an assertion is true and then base your argument
for the truth of that assertion on the assumption. You need to
decide what "doing wrong" is first, and I am unconvinced that what
you propose to punish is indeed "doing wrong".
Please note that there are real-world examples of both methods
available for study. The US has done a fair job of cutting off
Cuba, while South Korea is taking just the opposite path towards
North Korea, allowing them as much info and trade as they are
willing to accept. It is unclear which path is superior.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: New Crypto Regulations
Date: 18 Jan 2000 23:19:59 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Douglas A. Gwyn) wrote:
>
>JPeschel wrote:
>> "Douglas A. Gwyn" [EMAIL PROTECTED] writes:
>> >To the extent that people think a democracy is desirable,
>> >the US ideal of government that promotes individual rights
>> >has already died.
>> This is, of course, pessimistic nonsense.
>
>No, it isn't. A democracy is merely a slowed-down version of mob rule.
>Mobs aren't known for watching out for individual rights.
...which is why Jefferson, Franklin, etc. chose not to form a
democracy in 1776. Instead they chose to form a republic.
------------------------------
From: [EMAIL PROTECTED] (NFN NMI L.)
Subject: Re: RSA survey
Date: 19 Jan 2000 04:58:25 GMT
<<A 1024 bit modulus is more than enough.>>
When 512-bit moduli can be cracked by large corporations with enough funds?
Sorry. I want strength that will keep messages secure until I'm in the cold,
hard ground. Better too much than too little. Just you wait.
S. T. "andard Mode" L.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: NTRU Cryptosystems Inc.
Date: Tue, 18 Jan 2000 21:35:32 -0000
David Wagner <[EMAIL PROTECTED]> wrote in message
news:85u53k$7dl$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> lordcow77 <[EMAIL PROTECTED]> wrote:
> > RSA with low exponents may not be equivalent to factoring.
>
> RSA with large exponents may not be, either. And so it goes....
>
> > That notwithstanding, I believe the 100x figure refers to generation
> > of public/private key pairs.
>
> Ahh, that would explain it. Thanks for pointing out that possibility!
Actually, I happened upon the NTRU exhibit at the RSA conference, and
asked about that. The salesman in the booth claimed that the
100x figure was for encryption/decryption. And, for key generation, it was
"thousands of times faster". Make of the saleman's comments as you
will...
--
poncho
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: 19 Jan 2000 06:01:33 GMT
There are many advantages of ECC over RSA. See my PKS '99 paper.
Montgomery gave a talk at RSA 2000 on doing the matrix reduction on a connected
machine. Montgomery is one of the best in this area.
Also see www.cryptosavvy.com for an independent analysis of strength of RSA and
ECC by Arjen Lenstra who is one of the best.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Java's RSA implimentation
Date: 19 Jan 2000 06:37:14 GMT
In <862upd$vr$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>Is anyone aware of any effort to analyse the RSA implementation in Java;
>specifically focusing on key generation.
??? Java is a language, much like C in many essentials. It is up to you
to code what you want it to do.
>Does Java use a table of primes? If so, how big is the table?
No, Java does not. But you can enter a table of primes if you wish. And
you can encode a prime testing routine in Java just as you can in C.
>Otherwise how good is it's prime number generation routines ie. what is
>the probability of a generated number not being prime.
I do not know that Java has a "prime number generating routine". but you
can code one up in Java.
Jus tread the code in any RSA implimentation.
>Thanks.
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
Date: Tue, 18 Jan 2000 05:52:47 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: New Crypto Regulations [off-topic]
=====BEGIN PGP SIGNED MESSAGE=====
Arturo wrote:
>
> On Fri, 14 Jan 2000 10:27:17 -0700, "John E. Kuslich"
> <[EMAIL PROTECTED]> wrote:
>
> >I hereby dare anyone to tell me that he/she has read and understood the
> >new crypto regulations. They are simply beyond comprehension and
> >deliberately so. These regs will make many a lawyer rich!
> >
> >see http://www.cdt.org/crypto/admin/000110cryptoregs.shtml
> >
> >What kind of government can get away with making laws the meaning of
> >which are not clear until such time as one is prosecuted for violating
> >such laws?
>
> Currently, about 90% of them
Only 90%?
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOIP/kTkCAxeYt5gVAQE+lggAoQAY1Ov2TtikPNHyBJ1l04eyJCyWErrJ
C4lUzNrcTUSc0kU3XjDsYUzRXqiPBgYCC50OKSK57Fo9ZXGeNkpxQROJbP8DCjhz
vMA414r+6DZqK9/OCLdR7A2LlxlBzhVXJdoyeVUXfLlSUtIwrKddBrQ6Bn2i1dyN
p5dFkVJwRWASmyC425Cs8wGKcIoNRP92RuR0o+Hj8AB4UyqNxfTmcSxY9EnpnhvN
gYd/I2l2iOnHLnFCggRbuNGugcSgWwizkO1zzuL09BbjUwbJZS18Llrm8km4Ybw/
Ed9BArx1BBGhYoFDnwg3Qe9sJOVtln/FvO+x5Ur27CdO/UcjRYy+hQ==
=pFky
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
