Cryptography-Digest Digest #907, Volume #11 Thu, 1 Jun 00 05:13:00 EDT
Contents:
Re: RSA/PK Question ("Joseph Ashwood")
Re: Anti-Evidence Eliminator messages, have they reached a burn-out po ("elf")
Re: XTR (was: any public-key algorithm) (Wei Dai)
Help! [Large Prime] (Park Jiho)
Is it possible to use encryption to solve this problem? (Paul)
Re: Is OTP unbreakable?/Station-Station (Nicol So)
Re: Is it possible to use encryption to solve this problem? (Andru Luvisi)
Re: XTR (was: any public-key algorithm) (David A. Wagner)
Re: Is OTP unbreakable? (Guy Macon)
Re: PGP wipe how good is it versus hardware recovery of HD? (Guy Macon)
Re: safer style sboxes (Alain CULOS)
Re: PGP wipe how good is it versus hardware recovery of HD? (Dave Heller)
Re: any public-key algorithm ("Eric Verheul")
Re: any public-key algorithm ("Eric Verheul")
Re: XTR (was: any public-key algorithm) ("Eric Verheul")
Re: XTR (was: any public-key algorithm) ("Eric Verheul")
Re: RIP Bill 3rd Reading in Parliament TODAY 8th May (David Boothroyd)
Re: Is it possible to use encryption to solve this problem? (Mok-Kong Shen)
Re: XTR (was: any public-key algorithm) (Wei Dai)
Re: Use of wasted symmetric key bandwidth in key agreement protocols (Mark Currie)
Re: any public-key algorithm (Paul Rubin)
Re: XTR (was: any public-key algorithm) (Paul Rubin)
----------------------------------------------------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: RSA/PK Question
Date: Wed, 31 May 2000 21:05:02 -0700
You and I both know that many of us (including myself) have
corrected you on this time and time again. If you are so
focused on only protecting against the right here right now,
why don't you use a 57 bit key? 56 bit's is the largest
that's been publically done, 64-bits has been going on for a
long time now, so 57 bits is good enough for now. Instead we
have as a community gone with AES at 128 bits minimum. You
seem to be very much the exception here, instead of the rule
you think you are.
Joe
> But factoring numbers beyond 768 bits is not currently
possible,
> and 1kbit won't be for a long time, how do you reason that
> 8+kbit keys are comporable to a 256 bit symmetric key?
------------------------------
From: "elf" <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
Subject: Re: Anti-Evidence Eliminator messages, have they reached a burn-out po
Date: Thu, 01 Jun 2000 04:19:41 GMT
"James K" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> This is more bullshit SPAM, posted by the dickhead > >
James,
See how irritating repetition is?????
you posted the same bulshit over and over,now who`s the one spamming?james?
elf
>
------------------------------
From: Wei Dai <[EMAIL PROTECTED]>
Subject: Re: XTR (was: any public-key algorithm)
Date: Wed, 31 May 2000 21:26:24 -0700
In article <8h3pa4$lvt$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> Yes. But, LUC had no advantages over RSA / El Gamal.
> (Apart from some exaggerated claims, which were soon debunked.)
The claims were exaggerated, but the LUC variants of DH/ElGamal do have some
real advantages over the GF(p) versions (see
http://www.eskimo.com/~weidai/lucas.html). They are just too marginal to excite
much interest.
> In comparison, XTR does have some claimed advantages.
> (I have no way to know whether they will hold up, but they at
> least seem compelling enough to examine the scheme further.)
XTR's advantages do not appear to be exaggerated, but they do seem marginal
(with respect to ECC). How excited could one get about reducing the number of
modular multiplies from 1700 (for ECC) to 1360 (for XTR, as claimed on page 15
of the XTR paper)? Unless XTR's proponents do a really good marketing job,
probably not enough to want to pay a patent license for it.
That's not to say that XTR is not interesting from an academic/non-commercial
point of view. I'm at least interested enough to want to print out the paper
and read it. :)
--
cryptopp.com - a free C++ class library of cryptographic schemes
------------------------------
Date: Thu, 01 Jun 2000 14:03:00 +0900
From: Park Jiho <[EMAIL PROTECTED]>
Subject: Help! [Large Prime]
Subject: Help! [Large Prime]
Hi, all.
I am developing some crypto application.
Today, I'd like to ask you how
to generate a special form of large prime number
such as a "secure prime" or a "safe prime".
If possible, I hope to get some available library
for such a large prime. Anybody has an idea?
Your prompt help must be greatly appreciated.
Please help me... -_-;;
I would appreciate it much more
if you could send the answer via email to [EMAIL PROTECTED]
Thanks in advance.
Baggio
============================================================
Jiho Park e-mail: [EMAIL PROTECTED]
M.S. candidate, Dept. of Computer Science, Yonsei Univ.
ICQ#:16831068 http://onyx.yonsei.ac.kr/~aveque
I'm listening "Blind" by Korn..... ARE YOU READY...?!
============================================================
------------------------------
From: [EMAIL PROTECTED] (Paul)
Subject: Is it possible to use encryption to solve this problem?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 01 Jun 2000 05:07:14 GMT
We want to have an application that users can buy.
We also can provide add-ons to the application.
We want to be able to sell these add-ons over the Internet via a
subscription service.
However, we want to make sure that one user doesn't simply pay for the
add-ons and then simply give them away to others, bypassing the
subscription service.
Now my question is, what is the best way to try to go about doing
this? Could encryption technology help us? This doesn't seem to be
strictly a cryptographical issue, but seems to be related to it. If
cryptography isn't part of the solution, what might be?
Paul
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?/Station-Station
Date: Thu, 01 Jun 2000 01:06:01 -0400
Reply-To: see.signature
Tim Tyler wrote:
>
> Bryan Olson <[EMAIL PROTECTED]> wrote:
>
> : The method presented by ciphermax is flawed, but a one-time
> : random key does offer provable authentication, and no other
> : technique does.
>
> The scheme you describe - like other sorts of "provable" security does
> not actually /prevent/ the possibility of faking identity. Instead it
> tries to reduce it to 1/S.
I don't think Bryan Olson characterized the protection offered by the
scheme as "prevention". He only referred to it as "provable", which is
true. Reducing the probability of successful spoofing to 1/|S| is the
best you can do (under reasonable assumptions).
> The "proof" also depends on an unprovable assumption - the existence of an
> unguessable random stream.
I think there is some confusion here. The term "proof" only applies to
statements in a (formal) proof system. Loosely speaking, you can say
that it only applies to mathematical statements.
When Bryan Olson analyzed the scheme he described, he's dealing with a
mathematical model. "Unguessable random streams" certainly exists in
this mathematical "world"--they can be modeled/defined in terms of
sequences of independent, uniformly distributed 0-1 random variables,
for example.
Apparently, your objection is that there might not be anything in the
physical world of which a sequence of independent, uniformly distributed
0-1 variables is a good model. That's a fair question, but that has
nothing to do with proofs. It is not the purpose of a mathematical proof
to demonstrate correspondence between something physical and a
mathematical description. No amount of mathematical reasoning can do
that. What is needed is scientific methods.
You seem to be very skeptical about the existence of "unguessable random
streams". What kind of evidence would it take to convince you that
physical phenomena exist that correspond (closely) to idealized unbiased
coin flips? Your "standard of proof" seems to be very high. If you look
at other things in everyday life, you'll find that we accept
mathematical models as _adequate_ based on much lower standards than
yours. We know that Newtonian mechanics is only approximate, yet we
build cars, bridges, buildings etc on it.
This is getting philosophical, but I want to point out that a
mathematical model is only a tool for reasoning. It does not _by itself_
say anything categorically about the objects being modeled. What it
gives you is this: if you have good reasons to believe that the
assumptions are valid (and you can gain confidence using scientific
methods), then you have good reasons to believe in the conclusion
derived from the mathematical model. In other words, it helps you
transfer justified belief in one set of statements to that of another.
> These sorts of concern always make me uneasy about the use of the term
> "provable" in relation to secrecy, or authentication.
>
> It seems to me that "provable" security is almost a sort of academically-
> respectable snake-oil marketing technique :-|
The term "provable" does mean something--rigor of reasoning in the
mathematical model. Unfortunately, many researchers use the term to
refer to results that don't guarantee what a reader might expect when he
sees the word "provable".
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: Is it possible to use encryption to solve this problem?
Date: 31 May 2000 22:21:33 -0700
Encryption is only effective if the endpoints are trustworthy. You
need to assume that the transmitter and receiver are functioning as
intended. When everything is taking place on one machine, the user is
in control and can cause your environment to violate pretty much any
assumption you make about it. Not only is encryption unable to do you
want, but what you want can't be done.
Andru
--
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: XTR (was: any public-key algorithm)
Date: 31 May 2000 22:41:29 -0700
In article <[EMAIL PROTECTED]>,
Wei Dai <[EMAIL PROTECTED]> wrote:
> XTR's advantages do not appear to be exaggerated, but they do seem marginal
> (with respect to ECC).
I'm not sure I'd call them marginal. In purely technical terms, it
is interesting to find a public-key cryptosystem that achieves many of
the benefits of elliptic curves -- but without the elliptic curves! --
for those who are a bit skeptical about the security of elliptic curves.
However, as you say, whether XTR's advantages are compelling enough
to make people want to pay for a patent license when there are free
alternatives is another question entirely.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Is OTP unbreakable?
Date: 01 Jun 2000 01:59:08 EDT
Joaquim Southby wrote:
>My estimates always assume that the adversaries are smarter, richer, and
>better-looking than me.
Smarter, maybe.
Richer, almost certainly.
But Better looking? Never!
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: PGP wipe how good is it versus hardware recovery of HD?
Date: 01 Jun 2000 02:11:05 EDT
Dave Heller wrote:
(snip)
>I cannot comment on the Windows version. but I implemented the
Your post ended at the above line. could you repost? I am wondering
whether you used your OS or wrote low level, device specific code.
------------------------------
From: Alain CULOS <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: safer style sboxes
Date: Tue, 30 May 2000 08:57:56 +0100
zapzing wrote:
> In article <[EMAIL PROTECTED]>,
> Jerry Coffin <[EMAIL PROTECTED]> wrote:
> > In article <8gfjlh$ib5$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> >
> > In fairness, I think there's more than practicality at work here
> > though: as Bruce Schneier has pointed out, it doesn't take much
> > talent to design a cipher that's probably secure as long as you don't
> > mind designing something that's slow, takes lots of memory, and so
> > on. For most cryptologists, the challenge is in creating a cipher
> > that uses the bare minimum of resources, but still makes optimal use
> > of the key and provides as much security as possible for that key
> > size.
> >
>
> I think you have hit the nail on the head.
> Another word for it would be "Brinksmanship".
> Just why cryptologists do this is unclear.
Well, I'm certainly not a cryptologist and can't speak for them, but
my guess is many :
1/ reduce usage of space to get a smaller footprint whereever you go
(that adds much to security).
2/ reduce usage of space (again) to fit more information/key on the
same media.
3/ reduce usage of space may have some time benefits (althouggh it can
also be the opposite).
4/ make it fast and efficient for more versatility of use.
5/ make it fast so that you can use longer keys and thus increase
security much more by comparison to the slow secure algorithm you
suggest.
6/ make it fast just so you will not get caught waiting for
information you were not supposed to get (once again that's a
reduction in your footprint).
I'm sure with a bit of thinking I could find more better reasons in
favour of increasing efficiency (less space, faster) and again, I'm no
expert at cryptography, just an ordinary programmer in the civil
domain.
Regards,
Al.
------------------------------
From: [EMAIL PROTECTED] (Dave Heller)
Subject: Re: PGP wipe how good is it versus hardware recovery of HD?
Date: Thu, 1 Jun 2000 00:45:59 -0700
Guy Macon <[EMAIL PROTECTED]> wrote:
> I cannot comment on the Windows version. but I implemented the
>
> Your post ended at the above line. could you repost? I am wondering
> whether you used your OS or wrote low level, device specific code.
I started to post but decided not to and left the partial post in my
outbox. My bad.
I *was* going to say that I implemented the free space wiping in the
current Mac version of PGP and was going to address some of the
inaccuracies that were being posted, but I then realized that this
discussion was about file wiping, not free-space wiping.
Dave Heller
------------------------------
From: "Eric Verheul" <[EMAIL PROTECTED]>
Subject: Re: any public-key algorithm
Date: Thu, 1 Jun 2000 09:31:56 +0200
David A. Wagner <[EMAIL PROTECTED]> wrote in message
news:8h3upl$m3p$[EMAIL PROTECTED]...
> In article <8h3uiu$ofd$[EMAIL PROTECTED]>,
> Eric Verheul <[EMAIL PROTECTED]> wrote:
> > So your employer is not into either E-commerce (a typical SSL server can
not
> > initiate more than a dozen or SSL at the same time) [...]
>
> What makes you think that key generation is the dominant cost of SSL?
> That wasn't my impression...
Of course I meant Masterkey Decrytion at the server end (i.e. a by the
browser encrypted symmetric
key). That is the bottle neck of SSL, especially when a lot of clients try
to set up a secure session.
------------------------------
From: "Eric Verheul" <[EMAIL PROTECTED]>
Subject: Re: any public-key algorithm
Date: Thu, 1 Jun 2000 09:40:53 +0200
Roger Schlafly <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Eric Verheul wrote:
> > > I also didn't understand the key size comparisons, where you
> > > claim XTR is competitive with ECC. You compare XTR over GF(p^6)
> > > to ECC over GF(p), where p is around 2^170. ISTM an EC public
> > > key is 170+1=171 bits plus whatever is needed for shared
> > > parameters. But XTR need at least 1 (and maybe 3) elements
> > > of GF(p^2), so at least 340 bits are needed, plus shared
> > > parameters. So I don't see how XTR is competitive unless you
> > > always send the shared parameters.
> > Then I suggest you start reading the paper. BTW keys in ECC are 340 bits
> > too, unless you want to do a square root caclulation each time...
>
> Yes, do a square root each time if you want low bandwidth.
> It's not so crazy -- it is what your own paper suggests in
> the 2nd sentence of the 2nd paragraph of sect. 4.4.
There a two kinds of data size concerns in practice: sizes of
sent public keys and sizes of stored public keys (say at a WAP/WTLS
enabled cellular phone). My point is that in ECC, you would rather
*store* the Public Key uncompressed, whence the 340 bits.
> After coming here to sci.crypt to promote XTR, I am surprised
> that you are not more willing to defend your paper.
?
> The comparisons to RSA and ECC in sect. 4.4 are interesting,
> but comparisons to DH and DH-LUC would be more to the point
> because that is what XTR is closely related to. Why didn't
> you put in those comparisons?
The reasons to compare at all, is to give an impression with competing
systems. DH-LUC is not widely used. Next, you blame us of not comparing
XTR with the McEliece system. But XTR is a lot faster than DH-LUC
(and smaller, where DH-LUC requires 512, we require only 340bits).
Perhaps we'll put a comparion in later.
Eric
------------------------------
From: "Eric Verheul" <[EMAIL PROTECTED]>
Subject: Re: XTR (was: any public-key algorithm)
Date: Thu, 1 Jun 2000 09:45:19 +0200
> I agree with you. XTR is not any less susceptible to those
> attacks. In the case of your code, the attacks will depend
> on mod p arithmetic times or power usages depending on the
> data, or on whether the conditional branch can be detected.
> But the XTR algorithm in the paper has the same problems.
Then please *show* me a DPA attack.
Regards, Eric
------------------------------
From: "Eric Verheul" <[EMAIL PROTECTED]>
Subject: Re: XTR (was: any public-key algorithm)
Date: Thu, 1 Jun 2000 09:53:46 +0200
> XTR's advantages do not appear to be exaggerated, but they do seem
marginal
> (with respect to ECC). How excited could one get about reducing the number
of
> modular multiplies from 1700 (for ECC) to 1360 (for XTR, as claimed on
page 15
> of the XTR paper)? Unless XTR's proponents do a really good marketing job,
> probably not enough to want to pay a patent license for it.
- ECC's security is still marred by uncertainty (just have a look at the
recent literature).
- ECC's parameter generation (a curve) is a pain and that's why all people
will typically use
precomputed parameters (curves). Look at IPSec of WAP/WTLS. Ironically, they
had
to revise the IPSec precomputed curves, due to a new attack.
On the other hand XTR is based on the DL problem in a finite field, whose
security is considered
ok. Moreover, parameter generation consists of generation of two 170 bits
primes, which can
(theoretically) be done 81 times faster than the generation of two 512 bits
primes, as in RSA
(for same security). That means you can do XTR key gen on a smartcard
itself, which
is important for real non-repudation of dig. sigs.
Finally, who says that you don't have to pay license fees for using (smart
implementations of)
ECC? Be careful, there are lots of patents filed there..
> That's not to say that XTR is not interesting from an
academic/non-commercial
> point of view. I'm at least interested enough to want to print out the
paper
> and read it. :)
Thanks.
Eric
------------------------------
From: [EMAIL PROTECTED] (David Boothroyd)
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk,uk.telecom
Subject: Re: RIP Bill 3rd Reading in Parliament TODAY 8th May
Date: Thu, 01 Jun 2000 09:26:52 +0000
In article <[EMAIL PROTECTED]>, "Scotty"
<[EMAIL PROTECTED]> wrote:
> David Boothroyd wrote in message ...
> >In article <[EMAIL PROTECTED]>, Andru Luvisi
> ><[EMAIL PROTECTED]> wrote:
> >> [EMAIL PROTECTED] (David Boothroyd) writes:
> >> [snip]
> >> > > Yet there is still a vast weight of legal opinion (more highly
> respected
> >> > > than the government's own law officers),
> >> >
> >> > Is this possible?
> >> >
> >> > Are these mysterious givers of legal opinion in some way connected with
> >> > organisations who have always been against the Bill?
> >> [snip]
> >>
> >> Even if they are, that does not imply that their legal opinion was
> >> influenced by their opposition to the bill.
> >
> >And likewise the opinions of Government law officers were not influenced
> >by their support for the Bill, QED.
>
> So you agree that the governments law officers are not impartial towards the
> bill. :-)
They are members of the government bound by collective responsibility and
by the government whips.
> When two views are mutually contradictory at least one must be wrong.
Which do you think is more likely:
a) The government law officers, with the benefit of the civil service
and direct access to the European Court records to check, and who
are directly responsible for checking whether a Bill complies, and
who would be very strongly criticised for wasting Parliament's time
if they gave a certificate of compliance which turned out to be
incorrect, decided purely on the basis of their political loyalty
to issue a certificate of compliance.
b) A pressure group which wished to have some argument persuaded a
lawyer that one part of the Bill could be questioned as to its
human rights compliance.
It is very easy to question whether something complies with a treaty.
There were two challenges to the House of Lords Bill last year which
were struck out very quickly, one over the legal status of a writ of
summons and the other over the Act of Union with Scotland. Both took
hours of legal argument but neither had any real foundation.
> The important point here is that the section 19 certificate is merely a
> statement about the *Minister's* opinion.
This is the best opinion that is available: the Minister is introducing
the Bill, and so knows what its provisions will be and (more importantly)
how they will be used.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is it possible to use encryption to solve this problem?
Date: Thu, 01 Jun 2000 10:47:36 +0200
Paul wrote:
> We want to have an application that users can buy.
>
> We also can provide add-ons to the application.
>
> We want to be able to sell these add-ons over the Internet via a
> subscription service.
>
> However, we want to make sure that one user doesn't simply pay for the
> add-ons and then simply give them away to others, bypassing the
> subscription service.
>
Do I understand that you sell G and A and you want to prevent the
case that two customers both have G and jointly use only one A?
Couldn't you use license numbers to pair G and A, so that on running
a check is made? If the commodities are software, you could hide
the license numbers somewhere somehow, but there is no way against
determined hacking. Of course, if hacking costs more, then you are
safe.
M. K. Shen
------------------------------
From: Wei Dai <[EMAIL PROTECTED]>
Subject: Re: XTR (was: any public-key algorithm)
Date: Thu, 1 Jun 2000 01:43:03 -0700
In article <8h3thi$n7j$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > However if XTR is a good idea, then so was LUC-DH.
> On the www.ecstr.com website you can find a Asiacrypt99 paper I co-authored,
> in which the basis of XTR was laid, there we discussed LUC. LUC uses
> a subgroup of GF(p^2) of order p+1 (= second cyclotomic polynomial) where
> we use a subgroup pf GF(p^6) of order p^2 - p + 1 (= 6-th cyclotomic
> polynomial).
> Luc uses 1/2 the conventional number of bit, we 2/6 the number of bits.
> Moreover,
> we (implicitly) "tower" to GF(p^6), via GF(p^2) with an optimal normal basis
> on it,
> which partly explains why XTR is so fast.
Have you thought about generalizing LUC/XTR to even higher extension fields? It
sure seems like it should be possible, even if XTR turns out to be the sweet
spot.
> LUC-DH was a good idea, but XTR is an even better one.
XTR does seem to share one problem with LUC-DH though, namely inability to take
advantage of power-table precomputation to speed up exponentiation of fixed
bases. With ECC this precomputation can speed up encryption, signing, and
verifying by at least a factor of 2, giving ECC the edge in everything except
decryption.
On a different note, what exactly is the "generic software" (p.15) that you
used to benchmark RSA and XTR? If this is your own software please say so and
tell us what tricks you used to implement RSA and XTR (Karatsuba? Montgomery
multiplication? addition-chains for exponentiation?). If it doesn't use
Karatsuba for example then Table 1 overstates the relative advantage of XTR
over RSA. If the software is not your, it seems really bad form to not give
attribution. Surely even someone who writes "generic software" deserves credit?
--
weidai.com - crypto benchmarks and stuff
------------------------------
Subject: Re: Use of wasted symmetric key bandwidth in key agreement protocols
From: [EMAIL PROTECTED] (Mark Currie)
Date: 01 Jun 2000 08:42:41 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
>
>On 29 May 2000 08:29:16 GMT, [EMAIL PROTECTED] (Mark Currie) wrote,
>in part:
>
>>I would be interested in any other idea's for the use of these often wasted
>>bytes to increase data security without (ideally) impacting on the data
>>encryption performance.
>
>In the case of RSA, one could use the rest of the block to encrypt
>part of the message, in addition to the key.
>
>With Diffie-Hellman, of course one could use the excess bytes in the
>key to form a larger key. However, the security of Diffie-Hellman for
>a given key size is less than that achievable by a symmetric cipher
>with the same key size; hence, using such a long key might be
>considered 'wasteful'.
Good point.
>However, there are many stream cipher algorithms that could use a
>large key without being slow to execute (while not necessarily
>achieving all the potential security that size of key could offer).
Yes, and given your previous point, rather than try to increase security, it
might be better to exploit performance improvements in the data cipher due to
using a much larger key. Although, using tried and tested ciphers is always
more advisable.
Another use of this extra space, could be to store multiple keys to be used in
subsequent sessions thereby reducing the need for regular key exchanges.
Mark
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: any public-key algorithm
Date: 1 Jun 2000 08:53:14 GMT
In article <8h54nj$mdf$[EMAIL PROTECTED]>,
Eric Verheul <[EMAIL PROTECTED]> wrote:
>
>David A. Wagner <[EMAIL PROTECTED]> wrote in message
>news:8h3upl$m3p$[EMAIL PROTECTED]...
>> In article <8h3uiu$ofd$[EMAIL PROTECTED]>,
>> Eric Verheul <[EMAIL PROTECTED]> wrote:
>> > So your employer is not into either E-commerce (a typical SSL server can
>> >not initiate more than a dozen or SSL at the same time) [...]
>>
>> What makes you think that key generation is the dominant cost of SSL?
>> That wasn't my impression...
>
>Of course I meant Masterkey Decrytion at the server end (i.e. a by
>the browser encrypted symmetric key). That is the bottle neck of SSL,
>especially when a lot of clients try to set up a secure session.
This was a problem a few years ago but computers are faster now. A
midrange server PC (dual processor 750 MHZ Pentium III) should be able
to do over 200 decryptions/sec with 1024 bit RSA (these timings are
scaled from measurements I did with OpenSSL on a 300 MHz Pentium II).
The AMD Athlon is even faster than the PIII (120 decryptions/sec at
650 MHz, measured directly) and it should be possible to improve the
timings by a further few percent by optimizing the code more carefully
(MIRACL seems to beat OpenSSL slightly on the PII).
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: XTR (was: any public-key algorithm)
Date: 1 Jun 2000 08:55:09 GMT
In article <8h55fh$n08$[EMAIL PROTECTED]>,
Eric Verheul <[EMAIL PROTECTED]> wrote:
>On the other hand XTR is based on the DL problem in a finite field,
>whose security is considered ok. Moreover, parameter generation
>consists of generation of two 170 bits primes, which can
>(theoretically) be done 81 times faster than the generation of two
>512 bits primes, as in RSA (for same security). That means you can do
>XTR key gen on a smartcard itself, which is important for real
>non-repudation of dig. sigs.
Most smart cards I know of that do RSA signatures also generate the
keypair internally. It's a slow operation, but not done often.
The Schlumberger cards I'm using take around 30 seconds to generate
a keypair and 1 second to do a signature (1024 bit RSA).
------------------------------
** 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
******************************
