Cryptography-Digest Digest #921, Volume #10 Tue, 18 Jan 00 03:13:01 EST
Contents:
Re: how to encipher ([EMAIL PROTECTED])
Re: ECC ("HRook")
Re: how to encipher (Tom St Denis)
Not a OTP - Re: cruft-0.2 - file encryption package (Christopher Browne)
Re: how to encipher (Christopher)
comcrypt4000 decoder/i wanna brake it ("tasos")
Re: New Crypto Regulations (Guy Macon)
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Greg)
Re: New Crypto Regulations ("Trevor Jackson, III")
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Greg)
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Greg)
Re: New Crypto Regulations ("Trevor Jackson, III")
Re: how to encipher (Bill Unruh)
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Greg)
Re: ECC (Greg)
Re: New Crypto Regulations (JPeschel)
Re: 1on1lite (Was: Re: Echelon monitors this group) (Arturo)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: how to encipher
Date: 17 Jan 2000 22:51:16 -0500
Christopher <[EMAIL PROTECTED]> wrote:
> I am a beginner. I use p=20507,q=55889, e=67.
> So if I only obtain n=pq=1146115723 and e=67. I have find the private
> key from the public key, private key is d=85525323.
> Pls tell me how to decipher a text use d,
> since M^d mod n, M and d is too large handle is my computer.
Well, you could use UBASIC and its modpow function.
Other than that...
suppose you want x^d mod n.
First write d in binary: d=SUM[a_n*2^n]
Now consider the sequence:
x_0=x
x_(j+1)=x_j^2 mod n
(at each step you reduce mod n, so you never have to do more than mutliply
two number which are no larger than n)
Now we accumulate to get the product:
ANS=1:j=0
LOOP:
IF a_j=1 then ANS=ANS*x_j mod n
j=j+1
If we haven't finished with all the bits of d, then GOTO LOOP:
Suppose, for example (smaller numbers) d=114
d=(binary)=1110010
a_0=0,a_1=1,a_2=2_3=0, a_4=a_5=a_6=1
x_0=x, x_1=x^2 mod n, x_2=x_1^2=x^4 mod n,
x_3=x_2^2 mod n=x^8 mod n
x_4=x_3^2 mod n = x^16 mod n
x_5=x_4^2 mod n = x^32 mod n
x_6=x^5 mod n = x^64 mod n
(x_j = x^(2^j) mod n)
NOTE that one does not have to multiply anything but two numbers (smaller
than n) because after each multiplication one reduces mod n.
NOTE that there aren't 114 calculations done here! Only about
log_2(d) x_j's (many fewer): (six successive squarings to get x_0=x
through x_6=x^64 mod n)
What you want is x^d mod n = PROD[(x^(2^j))^a_j] mod n
or x^d=PROD[x_j: for those a_j which are equal to 1] mod n
(x_j=x^(2^j) and we don't have to do 2^j multiplications to get x_j, just
j successive squarings ... many fewer. a_j is either 0 (does not
contribute) or a_j=1)
One gets x^d by doing the multiplications and reducing mod n each time
(keeping the numbers small)
In the example with d=114=2+16+32+64 we want:
x^(2+16+32+64) mod n = x^2*x^16*x^32*x_64 mod n
x_1=x^2 mod n
x_4=(((x^2)^2)^2)^2=x^16 (four successive squarings) mod n
x_5=x^32 mod n (only five multiplications to get x^32! By successive
squarings)
x_6=x^64 mod n (not 64 multiplications! only 6!)
So we want x_1*x_4*x_5*x_6 mod n
So we take:
ANS=1*x_1 mod n (x_1 mod n=x^2 mod n)
ANS=ANS*x_4 mod n (x_1*x_4 mod n=x^18 mod n)
ANS=ANS*x_5 mod n (x_1*x_4*x_5 mod n=x^50 mod n)
ANS=ANS*x_6 mod n (x_1*x_4*x_5*x_6 mod n=x^114 mod n)
(each multiplication is reduced mod n)
(this is another 4 multiplications)
This is just x_1*x_4*x_5*x_6 mod n, or x^d mod n.
(each time we reduce mod n, so never have a large number to work with)
NOTE that there are only on the order of log_2(d) calculations to do (even
if you could do the calculations without overflow, doing 85525323
calculations, in your case, is just too many, anyway).
(in this case, 6 multiplications, successive squarings, to get the x_0 to
x_6 mod n and then another 4 to accumulate ANS: so a total of 10
multiplications, each reduced mod n: many fewer than the 114 calculations
and as we reduce mod n each time, we never have to worry about numbers
that could be so large as n^114!)
Generally you will see routines to do this, which check the j'th BIT in d
(the a_j) and if it is one, multiply ANS by x_j mod n: then
square x_j mod n (to get x_(j+1)) and check the next bit and loop.
I could post a routine to do this, but it would probably be better if you
tried programming it yourself.
UBasic can handle number of thousands of digits and has a modpow function
which raises one number to a power modulo another and does, basically, the
above.
------------------------------
From: "HRook" <[EMAIL PROTECTED]>
Subject: Re: ECC
Date: Mon, 17 Jan 2000 20:04:04 -0800
When constructing a ECC, why would one chose F sub 2^m over F sub P?
>From what I've seen, the operations in F sub P are much simpler. Or, am I
just reading things wrong?
Harvey Rook
"Jose Castejon-Amenedo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] wrote:
>
> > Alfred Menezes comments on B.Schneiers article comparing RSA vs ECC.
> >
> > Available at:
> > http://www.cacr.math.uwaterloo.ca/~ajmeneze/misc/cryptogram-article.html
> >
> > Comments?
> >
>
> I have just attended a series of lectures on ECC given by A. Menezes
> and S. Vanstone. AM expressed his views on the subject in a sort-of
> colophon lecture, in which he expanded somewhat on what he says on the
> article above.
>
> My feelings overall are that ECC is a serious contender in the realm
of
> public key cryptography. In a number of senses, it can be argued that its
> potentiality goes beyond that of RSA - not only does it require shorter
key
> lengths to provide security levels analogous to those of RSA but, in
> addition, the hardness of the mathematical problem that one needs to solve
> in order to crack ECC (to wit, that of computing discrete logarithms on
> elliptic curves defined on an appropriately chosen finite field) seems to
> rest on a more solid mathematical footing than its RSA counterpart: the
> modular cube root problem, which corresponds to e=3 in RSA, might be
easier
> than integer factorization. And we don't even know for sure if IF is NP.
>
> On the other hand, it seems to be the case that the resources argument
> in pro of ECC over RSA is losing strength all the time, as the hardware
> associated with smartcards, PDAs and similar gadgets becomes more powerful
> all the time. Likewise, I am not sure AM's arguments on ECC's scrutiny are
> convincing. I still believe that RSA has been subjected to more thorough
> studies, although it is true that any abstract results on the discrete
> logarithm problem apply to ECC.
>
> Perhaps a more serious issue ath this stage a comparative lack of
> standardization in the ECC world. There are standards all right, but they
> don't yet have the pervasiveness that the de facto RSA one has. My feeling
> is that one of the problems in the way of a wider ECC adoption might be
> this one.
>
> The bottom line is, ECC is a valid, quite mature technology that
should
> coexist and compete with RSA on an equal footing. I don't think that the
> shorter keys it has to offer really justify an en masse migration from
RSA,
> at least not yet. At any rate, a leading edge crypto product should
> certainly support them both -- RSA's BSAFE crypto kit already does.
>
>
>
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: how to encipher
Date: Tue, 18 Jan 2000 04:14:30 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Christopher) wrote:
> Hi,
> I am a beginner. I use p=20507,q=55889, e=67.
> So if I only obtain n=pq=1146115723 and e=67. I have find the private
> key from the public key, private key is d=85525323.
> Pls tell me how to decipher a text use d,
> since M^d mod n, M and d is too large handle is my computer.
>
Do it in steps... Like 2^17 is the same as (((((2)^2)^2)^2)^2) * 2,
which you can then perform mod n as
2^17 mod n = (((((2^2 mod n) ^ 2 mod n) ^ 2 mod n) ^ 2 mod n) * 2 mod n
Simple as that... hehehe :)
I calculated 3^16 on paper just for fun in 2 minutes using this
method...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.misc
Subject: Not a OTP - Re: cruft-0.2 - file encryption package
Reply-To: [EMAIL PROTECTED]
Date: Tue, 18 Jan 2000 05:00:11 GMT
On Mon, 17 Jan 2000 00:11:10 GMT, M. Leo Cooper
<[EMAIL PROTECTED]> concluded
we would all be made wiser by knowing that:
>-----BEGIN PGP SIGNED MESSAGE-----
>With the new liberalized Bureau of Export Administration encryption
>regulations now in effect, I am finally able to release my "cruft" file
>encryption package for Linux and generic UNIX. This is a medium security
>symmetrical block cipher system, based on the "one-time pad" algorithm,
>useful mainly for non-critical encryption of files on a workstation
>or network. Open Source / GPL, of course.
The documentation for this package does describe one time pads
reasonably correctly.
Unfortunately, here's how it works:
Using 'keygen' with a "filename" argument generates a key just as
long as the "plaintext" file, in accordance with the principle of
the "onetime pad" cipher. Using a unique ".key" file with each
different plaintext message to be encrypted makes decipherment
virtually impossible by any method. Of course, normal usage does not
require security quite this strict, and a daily, or even weekly
change of the ".key" file should suffice for ordinary purposes. Note
that if the ".key" file is kept in place for any length of time, a
minimum ".key" length of 10k bytes is recommended.
The 'keygen' utility included in this package uses the 'gcc' random
function, which is not, in fact, all that random. This can provide a
hook for cryptographers to attempt to decrypt cruft-encoded files.
In other words, it's *not* a random one time pad, but rather is merely
a block cipher that uses whatever function random() is to do its
encryption.
Seeing as how random() isn't a cryptographically strong RNG, and is in
many cases going to be produced by a linear congruential generator,
this is likely going to be blatantly weak.
If it was instead reading random values from /dev/random, then it
would be getting (theoretically/nearly) truly random values that would
be rather nearer to being strong.
--
"Access to a COFF symbol table via ldtbread is even less abstract,
really sucks in general, and should be banned from earth."
-- SCSH 0.5.1 unix.c
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher)
Subject: Re: how to encipher
Date: Tue, 18 Jan 2000 05:30:53 GMT
Yes, I know 2^17 mod n = (((((2^2 mod n) ^ 2 mod n) ^ 2 mod n) ^ 2 mod
n) * 2 mod n, but M is a very large number that M^2 cannot calculate
in my computer using long int. I am considering using the chinese
remainder theorem to break it into 2 equation.
On Tue, 18 Jan 2000 04:14:30 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Christopher) wrote:
>> Hi,
>> I am a beginner. I use p=20507,q=55889, e=67.
>> So if I only obtain n=pq=1146115723 and e=67. I have find the private
>> key from the public key, private key is d=85525323.
>> Pls tell me how to decipher a text use d,
>> since M^d mod n, M and d is too large handle is my computer.
>>
>
>Do it in steps... Like 2^17 is the same as (((((2)^2)^2)^2)^2) * 2,
>which you can then perform mod n as
>
>2^17 mod n = (((((2^2 mod n) ^ 2 mod n) ^ 2 mod n) ^ 2 mod n) * 2 mod n
>
>Simple as that... hehehe :)
>
>I calculated 3^16 on paper just for fun in 2 minutes using this
>method...
>
>Tom
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
From: "tasos" <[EMAIL PROTECTED]>
Subject: comcrypt4000 decoder/i wanna brake it
Date: Mon, 17 Jan 2000 21:19:36 +0200
i have a comcrypt 4000 decoder
and i whant to brake it did you know enithink about it
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: New Crypto Regulations
Date: 17 Jan 2000 19:36:37 EST
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.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: Tue, 18 Jan 2000 06:52:48 GMT
In article <85ve97$do2$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Alfred Menezes comments on B.Schneiers article comparing RSA vs ECC.
>
> Available at:
> http://www.cacr.math.uwaterloo.ca/~ajmeneze/misc/cryptogram-
article.html
>
> Comments?
He says...
Common advice is that ECC should only be used in constrained
environments where the only alternative is to have no public-key
cryptography at all. What this advice does not take into account
is that many applications involving constrained devices such as
pagers, cell phones, PDAs, and smart cards, involve communications
between these constrained devices and more powerful machines such
as PCs. Another scenario is that of an over-burdened web server
communicating with PC clients each of which has mild performance
requirements. It makes sense then to select the public-key
cryptography that works well in *both* environments. Currently,
ECC is the only public-key system suitable for all such
environments.
What I think would have been a good point to bring out is that
if these smart cards and other devices are using ECC to secure
some of our most vital financial information, then why are they
not generally accepted as good enough for common PC use?
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 18 Jan 2000 02:09:43 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: New Crypto Regulations
John Savard wrote:
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>
> >The question everyone should be asking is, by what *right* does our
> >government control exportation of privately-developed cryptologic
> >technology? Is it necessary to protect the natural rights of our
> >citizens, or is it infringing on those rights? (I say the latter.)
>
> That is certainly one of the questions to ask.
>
> But the claim is made that there is a sufficiently urgent necessity
> involved that worrying too hard about the former question is
> unrealistic. All over the world, there are terrorist groups, all over
> the world there are countries with unstable governments that might
> someday be replaced with regimes that will perpetrate aggression
> against their neighbors.
>
> Signals intelligence was, during World War II, and for some time
> thereafter, *the* major form of intelligence collection.
>
> With export controls on encryption, the U.S. is at least doing what it
> can to prevent the world - a world that uses U.S.-made operating
> systems on its computers - from changing over to unbreakable ciphers.
>
> That is almost a persuasive argument. Wars of aggression and terrorist
> bombs do kill people.
Yes, but the difference is several orders of magnitude. I think the
governments accounted for 170,000,000 deaths in the 20th century. I'd be
hard put to count 10,000 by terrorists. Clearly we should be denying
strong crypto to governments because they are the worst threat extant.
> The freedom to publish cryptographic source code
> on the Internet would, I think, quite reasonably seem to most people
> to be a rather small matter beside that.
I suspect you are wrong here. Further discussion belongs in t.p.c, but
I'd bet most readers here and there would disagree with your statement.
>
>
> Thus, while the question of whether we're dealing with an action which
> is, or should be, covered by the First Amendment is certainly a part
> of the issue, taking time to also argue whether or not the cited
> threat is bogus is not a waste of time.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: Tue, 18 Jan 2000 06:55:40 GMT
In article <85ve97$do2$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Alfred Menezes comments on B.Schneiers article comparing RSA vs ECC.
>
> Available at:
> http://www.cacr.math.uwaterloo.ca/~ajmeneze/misc/cryptogram-
article.html
>
> Comments?
He goes on to say...
The rough estimates of RSA key lengths for equivalent security
are 3072 bits, 7680 bits, and 15630 bits. Imagine the performance
degradation incurred with RSA implementations at these key sizes,
even with e=3!!
Exactly...
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: Tue, 18 Jan 2000 06:59:24 GMT
In article <85ve97$do2$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Alfred Menezes comments on B.Schneiers article comparing RSA vs ECC.
>
> Available at:
> http://www.cacr.math.uwaterloo.ca/~ajmeneze/misc/cryptogram-
article.html
>
> Comments?
He concludes with:
If ECC is considered good enough for the US Treasury, it should
be considered good enough for any application!
I tend to disagree with this assertion. If there was
one branch or segment of the federal government I would
want to emulate it would be the military, not Treasury.
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 18 Jan 2000 02:16:37 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: New Crypto Regulations
John Savard wrote:
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
> >John Savard wrote:
>
> >> With export controls on encryption, the U.S. is at least doing what
> >> it can to prevent the world - a world that uses U.S.-made operating
> >> systems on its computers - from changing over to unbreakable ciphers.
>
> >But terrorists and other criminals can readily get around these
> >controls. As usual, it is the innocent who are adversely impacted
> >when they attempt to obey the controls.
>
> >One would think that it would be evident by now from the so-called
> >"War on Drugs" that the aim of the controllers is more to restrict
> >freedom of non-criminals than it is to apprehend true wrong-doers.
>
> Oh, I agree. My point is only that those arguing for export controls
> _would_ have a case, since they point to serious threats, if there
> weren't good reasons for believing that the threat cited is
> fundamentally bogus. What I do feel is that this is a side of the
> argument that needs to be addressed; the fight can't be won on
> principle alone.
I believe this is a mistake. If the threat turns out to be bogus threats
can be synthesized. Governments do this. The Zimmerman Telegram. the
Polish attack on Nazi Germany. There are always incidents. Look into the
number of arrests the FBI makes based upon actions urged by their informants
and undercover operatives. They only do it because it works (generates
arrests).
It is only arguments based upon principle that have the power to eliminate
justifications for limiting freedom. Practical, pragmatic arguments lead to
compromise. In the realm of freedom, all compromises are losses.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: how to encipher
Date: 18 Jan 2000 07:20:02 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Christopher) writes:
]Yes, I know 2^17 mod n = (((((2^2 mod n) ^ 2 mod n) ^ 2 mod n) ^ 2 mod
]n) * 2 mod n, but M is a very large number that M^2 cannot calculate
]in my computer using long int. I am considering using the chinese
]remainder theorem to break it into 2 equation.
M MUST be less than n for RSA to work. Thus if you have a larger M, you
must break it up into a sequence of smaller blocks.
So if n is 1146115723, break M into blocks each less than 10 digits
long. ( But greater than length(n)/e digits long).
Thus if M= 2325968843552499, break into into two blocks. The first
M1=232596884 The second, M2= 355249900. Then ecrypt each of those.
If your n is sufficiently large, you will have to use long int packages
which can handle arbitrarily length integers. That is the main problem
in implimenting RSA. Everything else is trivial.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: Tue, 18 Jan 2000 07:08:09 GMT
In article <[EMAIL PROTECTED]>,
Jose Castejon-Amenedo <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > Alfred Menezes comments on B.Schneiers article comparing RSA vs ECC.
> >
> > Available at:
> > http://www.cacr.math.uwaterloo.ca/~ajmeneze/misc/cryptogram-
article.html
> >
> > Comments?
> >
>
> I have just attended a series of lectures on ECC given by A.
Menezes
> and S. Vanstone. AM expressed his views on the subject in a sort-of
> colophon lecture, in which he expanded somewhat on what he says on the
> article above.
>
> My feelings overall are that ECC is a serious contender in the
realm of
> public key cryptography. In a number of senses, it can be argued that
its
> potentiality goes beyond that of RSA - not only does it require
shorter key
> lengths to provide security levels analogous to those of RSA but, in
> addition, the hardness of the mathematical problem that one needs to
solve
> in order to crack ECC (to wit, that of computing discrete logarithms
on
> elliptic curves defined on an appropriately chosen finite field)
seems to
> rest on a more solid mathematical footing than its RSA counterpart:
the
> modular cube root problem, which corresponds to e=3 in RSA, might be
easier
> than integer factorization. And we don't even know for sure if IF is
NP.
>
> On the other hand, it seems to be the case that the resources
argument
> in pro of ECC over RSA is losing strength all the time, as the
hardware
> associated with smartcards, PDAs and similar gadgets becomes more
powerful
> all the time. Likewise, I am not sure AM's arguments on ECC's
scrutiny are
> convincing. I still believe that RSA has been subjected to more
thorough
> studies, although it is true that any abstract results on the discrete
> logarithm problem apply to ECC.
>
> Perhaps a more serious issue ath this stage a comparative lack of
> standardization in the ECC world. There are standards all right, but
they
> don't yet have the pervasiveness that the de facto RSA one has. My
feeling
> is that one of the problems in the way of a wider ECC adoption might
be
> this one.
>
> The bottom line is, ECC is a valid, quite mature technology that
should
> coexist and compete with RSA on an equal footing. I don't think that
the
> shorter keys it has to offer really justify an en masse migration
from RSA,
> at least not yet. At any rate, a leading edge crypto product should
> certainly support them both -- RSA's BSAFE crypto kit already does.
I believe that if ECC were to replace RSA as the standard pub key
cipher in massively available and commonly used software packages
like SSL, perception over ECC's quality of strength and its commercial
acceptance would change in one year's time.
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: ECC
Date: Tue, 18 Jan 2000 07:10:35 GMT
> When constructing a ECC, why would one chose F sub 2^m over F sub P?
>
> From what I've seen, the operations in F sub P are much simpler. Or,
am I
> just reading things wrong?
Some math algorithms are far simpler in F2m, particularly with
8 bit processors. Addition is, for example, just XOR of all bits.
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: New Crypto Regulations
Date: 18 Jan 2000 07:23:37 GMT
"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.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Arturo)
Crossposted-To:
alt.anarchism,alt.computer.security,alt.security,alt.security.espionage,alt.security.pgp
Subject: Re: 1on1lite (Was: Re: Echelon monitors this group)
Date: Tue, 18 Jan 2000 07:59:19 GMT
On Mon, 17 Jan 2000 19:13:19 GMT, [EMAIL PROTECTED]
(Jim) wrote:
>On Sun, 16 Jan 2000 18:18:20 +0100, "Thomas J. Boschloo" <[EMAIL PROTECTED]>
>wrote:
>
>And radio-telescopes now radiate, do they?
No, they don�t. They merely pick incoming radiation.
------------------------------
** 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
******************************
