Cryptography-Digest Digest #499, Volume #13 Fri, 19 Jan 01 15:13:00 EST
Contents:
Re: Kooks (was: NSA and Linux Security) (Greggy)
Re: Kooks (was: NSA and Linux Security) (Greggy)
Re: Kooks (was: NSA and Linux Security) (Greggy)
Re: Membership Signature Scheme (Mike Rosing)
Re: Why Microsoft's Product Activation Stinks (zapzing)
Re: Dynamic Transposition Revisited (long) (Mike Rosing)
Re: Why Microsoft's Product Activation Stinks (zapzing)
Re: Why Microsoft's Product Activation Stinks (zapzing)
Re: Membership Signature Scheme (Splaat23)
Re: Why Microsoft's Product Activation Stinks (zapzing)
Re: Light Computers (Mike Rosing)
3G crypto algorithms (Janos A. Csirik)
Re: block algorithm on variable length without padding? ("Joseph Ashwood")
Re: Comparison of ECDLP vs. DLP (Splaat23)
----------------------------------------------------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Kooks (was: NSA and Linux Security)
Date: Fri, 19 Jan 2001 18:00:29 GMT
> If you can't stand the fire, get out of the kitchen.
So that is the way you carry on a discussion. Attack the messenger
rather than reason and then tell him to leave if he can't stand your
attacks? I let others decide between us.
> > It is also interesting that NO ONE during the period in question in
> > the position of legislature or judicial screamed or even complained
> > about the Virginian process to publish the 13th amendment in its
1819
> > publication,
>
> Gibberish.
>
> Contemporary scholars understood that the amendment had
> not been ratified. William Rawle wrote that it "has been
> adopted by some of the states...
Yes, but that was not the group I was referring to - perhaps my fault
for not being clear.
Entire legislatures published the 13th amendment without people within
those bodies crying foul.
To assume that they were all fools is beyond any credible argument you
can put forth, but apparently that is what you would have us believe.
To imagine that each of these legislatures were conspiring to place
into law an improperly ratified amendment is also incredible.
You would have us believe that those who knew the truth intimately
would have stood by and said nothing - and many were present when these
votes were taking place.
Their actions show us that they knew TONA was ratified and was law.
> If one believes that TONA became part of the Constitution
> merely because it was frequently published, one should
> immediately mount an expedition to find Buss Island, a
> "phantom" island in the North Atlantic which appeared on
> maps from 1592 until 1856. See Donald S. Johnson, Phantom
> Islands of the Atlantic 80 (1994). Buss Island had its own
> conspiracy theorists; in 1770, an anonymous author accused
> the Hudson's Bay Company of keeping its location a secret
> in order to maintain financial control over it.
I think everyone can see that you are desparate with such folly
parallels.
> And on that subject, still unwilling to reveal...
What are you talking about? I just explained your reasoning is too
incredible to accept. My points were made by Richard Green's The
Demons of Discord. There is no secret here.
You would have us believe that entire legislatures conspired or were
totally ignorant of what they were choosing to publish.
You would have us believe that those involved in publishing Virginia's
state law books were not certain, raised no question or objections, and
yet published anyway. A quick history lesson on who those publishers
were would clear that up quickly, but you don't do your research - you
just attack.
You would have us believe they knew little and were confused or
mislead. As Richard Green shows in his essay, this is an assertion
that defies all the knowledge we have of these men.
You are embarassing yourself. I suggest you retire.
--
13th amendment to the US Constitution:
If any citizen of the United States shall accept, claim, receive,
or retain any title of nobility or honour, or shall, without the
consent of Congress, accept and retain any present, pension, office,
or emolument of any kind whatever, from any emperor, king, prince,
or foreign power, such person shall cease to be a citizen of the
United States, and shall be incapable of holding any office of
trust or profit under them, or either of them.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Kooks (was: NSA and Linux Security)
Date: Fri, 19 Jan 2001 18:05:10 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> On Thu, 18 Jan 2001 22:24:02 GMT, "Douglas A. Gwyn"
> <[EMAIL PROTECTED]> wrote, in part:
> >Greggy wrote:
>
> >> > > > legally declared the citizens of the US enemies of the US
> >> "During time of war or during any other period of national
emergency
> >> declared by the President, the President may ... regulate ...
> >> any transactions in foreign exchange, ... hoarding, melting, or
> >> earmarkings of gold or silver..., by any person within the United
> >> States or anyplace subject to the jurisdiction thereof".
>
> >That is not a declaration of US citizens as "enemies". You're
> >reading too much into the title of the Act -- does the Gun Owners'
> >Protection Act of 1968 really protect gun owners? The titles are
> >for mnemonic and reference purposes only.
>
> >It is obvious that the purpose behind the amendment was to close
> >a loophole whereby US citizens could abet the enemy by acting as
> >their agent in such transactions.
>
> Oh? That was the concern during the period from 1933 to 1975?
Actually, he is being a bit deceiving here. By regulating allies of
enemies under the original act, the president was able to stop American
businesses from working with them. He is suggesting that the amendment
was necessary to prevent what the president already had the power to
accomplish.
> Of course, the United States is a large and powerful country. Thus, it
> bears a big responsibility for the world.
>
> So it makes sense that sometimes U.S. citizens face certain
> limitations that people in other countries do not, such as
>
> - a limit on owning gold, during a time when it was felt the world
> needed more currency in circulation to keep the economy going,
>
> - conscription for the war in Vietnam that few other nations
> (Australia was one of that few) felt was essential to the defence of
> freedom,
>
> - restrictions on crypto export, since the U.S. is a world leader in
> computer technology.
>
> Instead of criticizing the U.S. for this, I can understand why some
> people might feel other countries should look at themselves to see if
> they are freeloading.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
>
--
13th amendment to the US Constitution:
If any citizen of the United States shall accept, claim, receive,
or retain any title of nobility or honour, or shall, without the
consent of Congress, accept and retain any present, pension, office,
or emolument of any kind whatever, from any emperor, king, prince,
or foreign power, such person shall cease to be a citizen of the
United States, and shall be incapable of holding any office of
trust or profit under them, or either of them.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Kooks (was: NSA and Linux Security)
Date: Fri, 19 Jan 2001 18:10:48 GMT
In article <949m9b$h20$[EMAIL PROTECTED]>,
digiboy | marcus <[EMAIL PROTECTED]> wrote:
> In article <948fut$j3p$[EMAIL PROTECTED]>,
> Greggy <[EMAIL PROTECTED]> wrote:
> > So we can see who the real kook is.
>
> I think it's clear to everyone...
The truth is first ridiculed, then violently attacked, then accepted as
obvious.
Let others decide between us. I have stated the obvious and cited
material which cites US law.
What have you done?
--
13th amendment to the US Constitution:
If any citizen of the United States shall accept, claim, receive,
or retain any title of nobility or honour, or shall, without the
consent of Congress, accept and retain any present, pension, office,
or emolument of any kind whatever, from any emperor, king, prince,
or foreign power, such person shall cease to be a citizen of the
United States, and shall be incapable of holding any office of
trust or profit under them, or either of them.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Membership Signature Scheme
Date: Fri, 19 Jan 2001 12:19:04 -0600
Splaat23 wrote:
>
> For a project I am working on, I am in need of a signature scheme that
> allows for a signature to be verfied offline as to its having been
> signed by a member of a group of people, without having to know the
> identity of the person or anything else about him/her. Essentially, the
> protocol would be as follows:
>
> 1) A trusted arbiter of the group generates a secret key, and uses that
> secret key to generate unique keys for each member, and transmits those
> keys to each member securely.
> 2) A member, with his secret key, computes a signature on a message and
> sends the message + the signature (or just the signature if it support
> message recovery) to another member of the group. The generation of the
> signature cannot depend on knowing which member he is sending to,
> because sometimes he will be broadcasting the message to multiple
> people.
> 3) The recipient can, using only publicly available data (and
> optionally his secret key) verify the signature.
>
> Obviously, each member's signature of identical messages must be unique.
>
> Most crucial is the space such a signature would take up. My best idea
> right now involves sending a conventional RSA signature + a (trusted
> arbiter) signed RSA public key, but that is very large. For
> reasonablely secure signatures it would be > .5K in size.
>
> I have searched all the math I know and can find and have found nothing
> really useful. If anyone has ideas on how to implement this or
> something close to this, please respond. Thanks in advance!
I'm not sure I completely understand the purpose, but you could go a
different route and accomplish the veification with anonymity portion.
Let each person generate their own secret key. Use common public parameters
so they can generate public keys. Each person sends their public key to
the arbiter. The arbiter packages all the keys and sends every person the
whole packet. If the arbiter wishes, they can destroy all knowledge of
who sent which key, so everyone stays anonymous.
The packet size can be small if you use ECC instead of RSA, a factor of 2 to
4 smaller (or more depeding on security level). Since everyone generates
their own secret, there's no central "authority" which knows them all. Everyone
can check that a message came from someone in the group, but does not know
which person sent it. (I assume no traffic analysis.)
This seems straight forward, but may not be the correct solution.
Patience, persistence, truth,
Dr. mike
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Fri, 19 Jan 2001 18:32:59 GMT
In article <[EMAIL PROTECTED]>,
Eric Smith <[EMAIL PROTECTED]> wrote:
> zapzing <[EMAIL PROTECTED]> writes:
> > First of all, under what conditions will MS
> > *refuse* to activate the product. It seems
> > to me that if they never refuse activation,
> > then putting in product activation code is
> > pretty useless.
>
> They probably will refuse if you don't provide
> them with your name, address, phone & fax number,
> email address, etc.
>
> They probably can't validate much of this info
> before activation though.
>
> Perhaps they'll email you the activation code to
> ensure that you've provided a valid email address,
> similarly to how the California DMV mails out
> drivers' licenses.
Yikes. I didn't even think of that but they
probably will. Does the CA DMV sell your info
to junk mailers?
--
Void where prohibited by law.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 19 Jan 2001 12:53:08 -0600
Terry Ritter wrote:
>
> Dynamic Transposition Revisited
>
> Terry Ritter
>
> 2001 Jan 18
>
> ABSTRACT
>
> A novel approach to block ciphering is remembered for
> relevance to modern ciphering issues of strength, analysis
> and proof. A rare example of a serious transposition
> cipher, it is also an unusual example of the simultaneous
> use of block and stream techniques.
[...]
Thanks Terry, that was nice writing. I agree that double transposition
is useful, otherwise one could accumulate lots of plaintext-ciphertext
pairs and begin to attack the RNG. Doubling the transpositions squares
the number of possible states, so brute force is probablely easier.
Patience, persistence, truth,
Dr. mike
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Fri, 19 Jan 2001 18:40:45 GMT
In article <[EMAIL PROTECTED]>,
Val Mehling <[EMAIL PROTECTED]> wrote:
> So - if we really do see TSHTF and Microsoft is one of the casualties
> and, some time later on, if someone starts setting up computers again
> they won't be able to use the new Windoze cause they won't be able to
> get it "activated." Better keep those Win 98SE CD's in a safe place.
Exactly. But I just had an amusing idea.
What if we require microsoft to submit
a universal access code to the
government. The govt. could keep it in
esgrow in case of national emergency.
I'm sure MS would love that idea :)
> zapzing wrote:
>
> > Upcoming versions of windows may have, I
> > read, something called "product activation".
> > This means that you must call up microsoft
> > so that the OS can have permission to run.
> > I have a few questions about this. First of
> > all, under what conditions will MS
> > *refuse* to activate the product. It seems
> > to me that if they never refuse activation,
> > then putting in product activation code is
> > pretty useless. And if they do, they may
> > deny legitimate users who reconfigure their
> > systems frequently.
> >
> > Also, what about the possibility of a major
> > computer virus that requires many machines
> > to restore. This would of course require
> > that the OS be reactivated, but in that case
> > the product reactivation lines could be
> > jammed. This would make me think about it
> > very carefully before I bought an OS that
> > included product reactivation code.
> >
> > I understand MS's desire to protect their
> > intellectual property, but please try to think
> > of something that will not cause the collapse
> > of civilization.
> >
> > --
> > Void where prohibited by law.
> >
> > Sent via Deja.com
> > http://www.deja.com/
>
> --
> Val Mehling - anti-spam in effect.
> For e-mail reply to: [EMAIL PROTECTED]
>
> http://home.earthlink.net/~valjm/
> Libertarian for Bush * Cheney
>
>
--
Void where prohibited by law.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Fri, 19 Jan 2001 18:47:08 GMT
In article <[EMAIL PROTECTED]>,
"Adrian S. Thompson" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm not 100% with US law (from Canada), but isn't it illegal to
*require*
> personal information to make a sale? I beleive it is here.
>
> Take Care,
> -=Adrian=-
Thsy can require just about anything
they want, as long as they don't
discriminate on the basis of race,
I think.
As an interesting digression, I do
know that you can legally make a
credit card purchase without giving
the store your personal information,
but this is just a part of the
agreement between the merchant and
the credit card issuing company.
And I think you can complain to the
credit card issuer if they refuse.
Not sure what the issuer would do to
the merchant, though (slap their
wrists?)
--
Void where prohibited by law.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: Membership Signature Scheme
Date: Fri, 19 Jan 2001 18:58:04 GMT
Yeah, that would be a good system if it weren't for a few things I
forgot to mention. First, the system is very, _very_ large. Second, it
is dynamic enough that too much bandwidth would be wasted on updating
clients with the new public keys.
Anonymity is NOT a requirement. These signatures most likely will need
to be anonymous in order to preserve bandwidth and prevent anyone other
than the manager from generating keys, but it really doesn't matter;
whatever works would be great.
An important thing is that abritrary users must NOT be able to generate
keys or signatures with those keys if they are not part of the group.
And users are not authorized to bring anyone into the group. Therefore,
if there were public parameters to generate keys, and those parameters
were leaked, then anyone could generate a public/private key pair (but
obviously, with your system, not get them published)
Hopefully, this clarification might help.
In article <[EMAIL PROTECTED]>,
Mike Rosing <[EMAIL PROTECTED]> wrote:
> Splaat23 wrote:
> >
> > For a project I am working on, I am in need of a signature scheme
that
> > allows for a signature to be verfied offline as to its having been
> > signed by a member of a group of people, without having to know the
> > identity of the person or anything else about him/her. Essentially,
the
> > protocol would be as follows:
> >
> > 1) A trusted arbiter of the group generates a secret key, and uses
that
> > secret key to generate unique keys for each member, and transmits
those
> > keys to each member securely.
> > 2) A member, with his secret key, computes a signature on a message
and
> > sends the message + the signature (or just the signature if it
support
> > message recovery) to another member of the group. The generation of
the
> > signature cannot depend on knowing which member he is sending to,
> > because sometimes he will be broadcasting the message to multiple
> > people.
> > 3) The recipient can, using only publicly available data (and
> > optionally his secret key) verify the signature.
> >
> > Obviously, each member's signature of identical messages must be
unique.
> >
> > Most crucial is the space such a signature would take up. My best
idea
> > right now involves sending a conventional RSA signature + a (trusted
> > arbiter) signed RSA public key, but that is very large. For
> > reasonablely secure signatures it would be > .5K in size.
> >
> > I have searched all the math I know and can find and have found
nothing
> > really useful. If anyone has ideas on how to implement this or
> > something close to this, please respond. Thanks in advance!
>
> I'm not sure I completely understand the purpose, but you could go a
> different route and accomplish the veification with anonymity portion.
> Let each person generate their own secret key. Use common public
parameters
> so they can generate public keys. Each person sends their public key
to
> the arbiter. The arbiter packages all the keys and sends every
person the
> whole packet. If the arbiter wishes, they can destroy all knowledge
of
> who sent which key, so everyone stays anonymous.
>
> The packet size can be small if you use ECC instead of RSA, a factor
of 2 to
> 4 smaller (or more depeding on security level). Since everyone
generates
> their own secret, there's no central "authority" which knows them
all. Everyone
> can check that a message came from someone in the group, but does not
know
> which person sent it. (I assume no traffic analysis.)
>
> This seems straight forward, but may not be the correct solution.
>
> Patience, persistence, truth,
> Dr. mike
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Fri, 19 Jan 2001 18:55:08 GMT
In article <[EMAIL PROTECTED]>,
"buddy_holly" <[EMAIL PROTECTED]> wrote:
> here are some good free PC operating systems:
> (you can burn these ISO images with most cd-r software and a cd
burner)
>
> Red Hat Linux 7.0:
> ftp://ftp.redhat.com/pub/redhat/current/i386/iso/7.0-respin-disc1.iso
> ftp://ftp.redhat.com/pub/redhat/current/i386/iso/7.0-respin-disc2.iso
>
> FreeBSD 4.2:
>
ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/4.2-install.i
so
>
Most people. like me, won't want to deal
with the installation hassles of Linux, so
the danger remains that a national crisis
could be made much worse by MS's Product
Activation scheme.
In the past, the FedGov has required
private companies to come up with plans
just in case of a national emergency, and
MS might have to do the same as regards
Product activation.
--
Void where prohibited by law.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Light Computers
Date: Fri, 19 Jan 2001 13:04:03 -0600
Benjamin Goldberg wrote:
>
> Very interesting. I wonder, if the light was split first, and both
> resulting photons were stored in this manner, would they retain their
> polarization properties, and be usable in the same way as entangled
> atoms?
I would guess not. It sounds like the energy goes into an atomic spin
state rather than an electronic energy level. The spin state won't
care what the polarization level was, and once absorbed the entanglement
is lost (it's been "observed").
What would be really cool would be to know if this could be done on
the nuclear level. Trapping x or gamma-rays in nuclear spin states would
make for a mighty compact computer :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Janos A. Csirik)
Subject: 3G crypto algorithms
Date: Fri, 19 Jan 2001 19:05:28 GMT
In contrast with GSM, the 3GPP organisation (responsible for 3G
wireless phone standards) is making all of its documents public.
However, the way in which these documents are made public is
unlikely to result in immediate gratification for those who would
just like to go in and look at the crypto algorithms.
For that reason, I have undertaken to construct a Web page to
help cryptographers learn about and study the crypto algorithms
for 3G wireless phones. I believe that the algorithms will
receive much more and better scrutiny if it is easy to find them
(and other 3G documents that are relevant to them). This page
can be found at
http://www.research.att.com/~janos/3gpp.html
Thank you for your attention!
Janos A. Csirik.
--
Janos A. Csirik, Mathematics & Cryptography, AT&T Labs - Research
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: block algorithm on variable length without padding?
Date: Fri, 19 Jan 2001 11:06:53 -0800
"Splaat23" <[EMAIL PROTECTED]> wrote in message
news:948h6h$k17$[EMAIL PROTECTED]...
> Maybe I'm missing something, but if the main point of this is to
> encrypt a message without expanding it, why not pick any of the secure
> block cipher modes that generate a keystream like a stream cipher.
> That's basically what we want here anyway if space is that important.
> Use the block cipher in a stream mode, and cut the keystream to message
> length and XOR. Done!
There are many circumstances where stream modes of block ciphers are
unacceptable. They offer no diffusion, the offer no protection from known
plaintext attacking to send an incorrect message, etc. (see our common
discussions on the problems with OTP). And you can never use a key twice.
For some purposes they are an ideal solution. For others, particularly those
where the need is a block cipher (aka diffusion), the stream modes are
unacceptable.
Joe
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: Comparison of ECDLP vs. DLP
Date: Fri, 19 Jan 2001 19:08:37 GMT
The C rand() was just an example of a PRNG passing statistical tests
yet not being secure. After key generation, you don't need anything
_nearly_ as time consuming as a regen to verify your results. Just some
trial encryptions of random data should suffice.
You are correct that we must not assume everyone is a good guy. In
fact, the best assumption to make is that everyone is a bad guy - that
way you are prepared. However, in terms of RSA, most PKI infrastructure
also provides validity certification. I'm not well-versed in how PGP
PKI works, but I think in order to submit a key it is checked for
validity using an interactive protocol. In any case, with RSA a well-
designed private key ownership test using random challenges would be
sufficient to verify someone else's key is valid and owned by them.
However, you point is well made. There are ways an invalid key can be
used for evil, but most of them involve the _first_ use of that key. If
a key has been used before, and certified as such, high-value comms can
take place. If not, a simple challenge protocol would reassure anyone
of the validity of the key.
Program coding _speed_ is not a standard metric, yet the program
_quality_ is, and I'm sure the simplicity of the code has a high
correlation with speed of coding and quality. In terms of execution
speed, as I said before, both have advantages and disadvantages. My
main problem with DH/DSA is that signature verification takes a good
bit more time than generation when in most applications the
verification is done >= the generation.
- Andrew
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> Splaat23 wrote and I intersperse my comments inside prefixed with DJ:
> "Just because it passes statistical tests doesn't mean it's
> cryptographically secure. No amount of statistical testing can prove
> that a RNG is unpredictable and thus secure. For example, most every
> good CSPRNG passes statistical tests, but if I know the key it is 100%
> predictable until the key changes. Even the C library rand() probably
> passes a bunch of tests, but it is worse than worthless.
>
> DJ: I do not think C rand() passes the FIPS 140 tests, but am not
sure and it
> should not be used. As I say, security is about assurance, if you
need
> assurance, do the tests, if not, do not. The tests give added
assurance of
> conformance.
>
> In general, this dialog has been fairly ridiculous. In any scheme,
> there has to be some trust in the implementor of the scheme. Both RSA
> and DLP can both be verified by the key generator after keygen is
> complete to check for errors, and even if some weird error occurred
> during keygen the checker will pick it up because the likelihood of
the
> checker having an error that will EXACTLY counter the other error is
> small.
>
> DJ: Yes, you can regen the key using other code/hw and see if you get
the same
> result. This can give assurance to the owner.
>
> In the case of RSA, _that is it_. A faulty RSA key has no bad aspects
> aside from not working, and it is in the keyholder's best interest to
> make sure his key is valid and secure against attacks.
>
> DJ: Just not working, this means the data from encryption is not
recoverable,
> for example.
>
> DJ: I think a better statement is that it is in the best interest of
a good
> guy. A bad guy can make something not work for many reasons, to
repudiate a
> signature, to allow someone to decrypt a sensitive message while
still claiming
> he did not reveal it (due to a bug on his system that is not his
fault), just
> to cause trouble with the trust model, etc. I think it is naive to
assume all
> users of PKI are good guys.
>
> In the case of
> DLP, there are situations where someone else, to preserve his own best
> interests, must remotely verify the validity of someone else's key.
> This is just an aspect of DLP, has been solved in both interactive and
> non-interactive proofs, and is one of the many differences between RSA
> and DLP that keep both of them as viable methods. Personally, EC-DLP
> and RSA are really almost tied, and the circumstances will totally
> guide me in my choice. This is not the place to mention the
> comparisons, but just search the web if you want a side-by-side
> comparison.
>
> However, if speed of implementation is a factor, I _do_ choose RSA
> because in any language with access to multi-precision integer math,
it
> takes 15 mins to implement RSA keygen, encryption and decryption with
> 20 mins black box testing of each section.
>
> DJ: You are looking at program coding speed, which is not a normal
metric.
> Usually of concern is speed of the operations, key gen, sig gen, sig
ver, etc.
> after they have been coded.
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (DJohn37050) wrote:
> > Yes, you can guard against an RNG failure by use of statistical
> randomness
> > tests ala FIPS 140-1 or -2.
> > Don Johnson
> Don Johnson
>
Sent via Deja.com
http://www.deja.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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
