Cryptography-Digest Digest #523, Volume #10 Mon, 8 Nov 99 03:13:05 EST
Contents:
Re: Montgomery vs Sqr & Mul -- Specifics (Doug Stell)
Re: Best Asymetric Key System? (Doug Stell)
Re: The Code Book Mailing List
Re: Understanding Cryptograpy--Where to start?
Re: U-Boat Enigma Machines ("Charles R. Lyttle")
Re: The Code Book Mailing List ("Trevor Jackson, III")
Re: Kerberos Question (Thomas Wu)
Signals From Intelligent Space Aliens? Forget About It. (Anthony Stephen Szopa)
Re: Montgomery vs Sqr & Mul -- Specifics (Paul Rubin)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Terry
Ritter)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Terry Ritter)
Re: Signals From Intelligent Space Aliens? Forget About It. (Anthony Stephen Szopa)
Re: Lenstra on key sizes (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: Montgomery vs Sqr & Mul -- Specifics
Date: Mon, 08 Nov 1999 04:10:59 GMT
On Sun, 07 Nov 1999 22:32:41 GMT, [EMAIL PROTECTED] wrote:
Derek,
>Anyway, that's why I was asking about "Montgomery" vs Knuth's "Sqr &
>Mul", but maybe the specifics will make my original question clearer.
Read the Efficient Implementations chapter of the Handbook of Applied
Cryptography. It's free and on line. It covers Montgomery
exponentiation quite well.
Montgomery method can only be used with RSA under certain conditions.
To be useful, the Montgomery modulus should be a power of 2 and,
therefore, even. The montgomery modulus and RSA modulus must be
relatively prime. Therefore, the RSA modulus must be odd.
Montomery method is most often used with the private key and the
Chinese Remainder Theorem method. This guarantees that the two smaller
RSA moduli are odd.
Good luck. I can send you a worked example of 3-digit RSA with CRT and
Montomery method, if you need it.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: Best Asymetric Key System?
Date: Mon, 08 Nov 1999 04:16:44 GMT
On Sat, 6 Nov 1999 15:34:40 -0500, "Wynne Crisman"
<[EMAIL PROTECTED]> wrote:
>I'm currently building a app that requires message verification. I am
>already using TwoFish and SHA for generating encrypted message digests, but
>need to use an asymetric system to distribute the session key. Does anyone
>have suggestions as to which asymetric key system I should be using?
>(Preferably one I can get the source to and use in a commercial app.)
If you have to distribute, i.e., encrypt, symmetric keys, ElGamal is
your best bet.
If you can use a key agreement algorithm, I'd recommend the
now-declassified Key Exchange Algorithm (KEA).
doug
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: The Code Book Mailing List
Date: 8 Nov 99 04:09:18 GMT
[EMAIL PROTECTED] wrote:
: Trevor Jackson, III ([EMAIL PROTECTED]) wrote:
: : I consider One a prime because it is only divisible by one and itself.
: I tend to think that one is prime (adjective) and zero is composite
: (adjective), but to call one _a_ prime (noun) is not a good idea. That's
: because multiplying a number by one doesn't change it; so, if you get one
: when you factor a number, what is to stop you from getting one to the
: fifth power, or one squared, instead of just one as a factor?
To avoid confusion, it should be noted that since mathematicians don't
call one a prime, they don't use the word prime as an adjective applied to
it either; since, on a ruler, the tick corresponding to no sixteenths of
an inch is large, and the one corresponding to one sixteenth of an inch is
small, and the same would be true if the large ticks came every third tick
or every fifth, however, it is understandable that the quality of
primeness is seen as present with 1 and the quality of compositeness is
seen as present with 0, and so I simply note that the inclination to think
of 1 as prime is understandable, while giving the reason why
mathematicians do not do so: multiplying by 1 changes nothing, and thus
unlike the numbers acknowledged as primes, 1 is not a "building block of
the integers" (by multiplication; by addition, it is _the_ building block
of the integers...).
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Understanding Cryptograpy--Where to start?
Date: 8 Nov 99 04:04:22 GMT
Jim Gillogly ([EMAIL PROTECTED]) wrote:
: AIfred E Neuman wrote:
: > I'd like to develop an understanding of encryption technologies and am hoping
: > that this newsgroup can give me a place to start. What reference materials
: > should I access? Thanks in advance.
: Read the sci.crypt FAQ. If you're still interested, read Kahn's
: "The Codebreakers" and Bauer's "Decrypted Secrets". If you're
: still interested, you'll know by then where to look next.
And for those too cheap to do that (or too lazy to visit their local
public library...but, to be fair, my local public library doesn't have
copies of either book, although it has Applied Cryptography by Bruce
Schneier, and it _used_ to have David Kahn's "The Codebreakers", many
years ago) there is always my web site,
http://www.ecn.ab.ca/~jsavard/index.html
recently improved with updated sections on quantum computing and
Kerberos...you can even read about transfinite ordinals while you're
there.
John Savard
------------------------------
From: "Charles R. Lyttle" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc
Subject: Re: U-Boat Enigma Machines
Date: Mon, 08 Nov 1999 04:30:48 GMT
Jim Reeds wrote:
>
> In article <[EMAIL PROTECTED]>, "Charles R. Lyttle" <[EMAIL PROTECTED]>
>writes:
> ...
> |> To add an aside to the story probably not covered on British TV. The US
> |> did capture a U-boat with a working Enigma, but the US and Britian were
> |> not sharing info as well as might be expected. Sometimes one party
> |> worried about the Axis finding out, other times the "NIH" syndrome
> |> prevailed. A common worry was that the information would be used in such
> |> a way as to make it possible for the enemy to deduce that the codes were
> |> broken.
>
> Referring to the U-505, captured on 31 May 1944 (I think), now on display
> in Chicago. By the time this capture was made the important info about
> what the Naval Enigma was, etc, had long been worked out. So the profit
> from the capture did not balance the risk factor that the Germans might
> hear about it and draw conclusions. (Of course there must have been lots
> of other intelligence value to the capture, including current key lists
> and signal files, as well as engineering info.) Although allies often
> squabbled, the US Navy had better relations with BP than the US Army,
> sharing Enigma info much earlier, for instance.
>
> --
> Jim Reeds, AT&T Labs - Research
> Shannon Laboratory, Room C229, Building 103
> 180 Park Avenue, Florham Park, NJ 07932-0971, USA
>
> [EMAIL PROTECTED], phone: +1 973 360 8414, fax: +1 973 360 8178
I thought the capture was a year earlier. We can look it up, though. I
understand the machines were taken from the Navy, so they couldn;t have
shared if they wanted to, But the Navy got to use the map overlays
giving grid co-ordinates by names of flowers.
--
Russ Lyttle, PE
<http://www.flash.net/~lyttlec>
Thank you Melissa!
Not Powered by ActiveX
------------------------------
Date: Sun, 07 Nov 1999 23:47:16 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: The Code Book Mailing List
[EMAIL PROTECTED] wrote:
> Trevor Jackson, III ([EMAIL PROTECTED]) wrote:
> : I consider One a prime because it is only divisible by one and itself.
>
> I tend to think that one is prime (adjective) and zero is composite
> (adjective), but to call one _a_ prime (noun) is not a good idea. That's
> because multiplying a number by one doesn't change it; so, if you get one
> when you factor a number, what is to stop you from getting one to the
> fifth power, or one squared, instead of just one as a factor?
I'm aware of the reasons for one not normally considered a prime. The fact
that the product does not change if you leave it out, and the fact that the
exponent is indeterminate, as you pointed out are a couple of basic reasons.
I defined one as a prime in order to extend the concept of "factoring prime
numbers" to cover an ambiguous wording of a request aiming at composite of
two factors. The definition of one as a prime is about the same seriousness
as a special method of factoring extremely large prime numbers very quickly.
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Kerberos Question
Date: 07 Nov 1999 20:41:53 -0800
[EMAIL PROTECTED] (Daniel S. Riley) writes:
> Kerberos 5 with preauthentication required greatly reduces the
> exposure of this vulnerability (you have to sniff the response from
So V5 is vulnerable to a sniffer. I think that's what the original
poster was worried about, and the weak preauthentication schemes being
discussed don't eliminate the dictionary attack.
> You have something better to suggest? Keep in mind that Kerberos is a
> complete single-sign-on authentication and key management system that
> handles mutual authentication, key exchange, and cross realm
> authentication. While EKE, SPEKE, or SRP might be candidates for
> improving the security of the initial ticket exchange within Kerberos,
> they aren't anywhere close to providing the functionality necessary to
> replace Kerberos.
I can't find any evidence that this is true - secure password methods
are a drop-in replacement for weak C/R and would provide the exact
combination of functionality and security that would make K5 a viable
solution. If you know of any technical reasons not to use strong
password auth., I'd be interested in hearing them.
> Or let me ask the question another way--would you rather Microsoft had
> another go at designing their own authentication system? Kerberos,
> even without a session key in the preauth data, is still superior to
> Microsoft's previous attempts.
True enough, but that shouldn't stop the watchdogs from pointing out
deficiencies where they occur.
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.military,talk.politics.misc,talk.politics.crypto
Subject: Signals From Intelligent Space Aliens? Forget About It.
Date: Sun, 07 Nov 1999 21:37:33 -0800
Reply-To: [EMAIL PROTECTED]
Signals From Intelligent Space Aliens? Forget About It.
I believe the United States and the rest of the world will adopt a
universal communications transmission protocol as soon as the
technology becomes available to not only encrypt all communications
transmissions worldwide but to conceal these transmissions as nearly
as possible among the back ground radiation remnant of the big bang
in space or other terrestrial back ground noise.
Quantum digital circuits should make this feasible.
Let us not fool ourselves, the Earth is obviously the most import piece
of real estate in this solar system and possibly in this part of the
galaxy. It is just as obvious that to announce this fact to the rest of
the galaxy is quite stupid.
National Security necessitates that we must assume that there are no
friendly space aliens.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Montgomery vs Sqr & Mul -- Specifics
Date: 8 Nov 1999 05:46:11 GMT
In article <804um9$q56$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>My project that I'm attempting is to embed RSA into a 6811
>microcontroller. This thing runs at 2 MHz and needs 10 clocks to do an
>8-bit multiply. In other words, it has very limited capabilities
>compared to the processors that everyone else does RSA on....
>
>So, I'm just trying to figure a time estimate for encryption/decryption
>to see if this project is even possible. If it takes < 30 seconds to
>decrypt, that's good, but if it takes 30 hours, that's not good.
This has been done a number of times. I don't know of any free
implementations but you could ask around. If you want a commercial
68hc11 implementation, I think that RSADSI has one available
($$$$$$$$$$$$$$$$$). Decryption speed (512 bits) is likely to be on
the order of 1/2 a minute if you code carefully. It won't take hours.
Remember that the Intel 8088 took 40+ clocks to do a 16x16 bit
multiply, and the original IBM PC (4.77 mhz 8088) was considered an
useable (though somewhat short of wonderful) platform for PGP. I'm
actually surprised that your 6811 does 8x8 in only 10 clocks.
Depending on your application, you might consider one of the 68HC11SC
series (I don't remember exact part numbers) intended for use in smart
cards. Some of these have public key accelerators and can do that 512
bit decryption in under a second. They also have improved security
compared to typical microcontrollers, i.e. they're more resistant to
hardware attacks that attempt to get the secrets out.
Also depending on your application, you might not need RSA at all.
If you can say more about what you're doing, people here might
be able to offer alternative suggestions.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 08 Nov 1999 05:51:17 GMT
On Fri, 05 Nov 1999 05:18:13 GMT, in <7vtpaj$gg$[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] wrote:
>Terry Ritter wrote:
>>
>> [EMAIL PROTECTED] wrote:
>
>> >You certainly have heard such a suggestion. Yes, you
>> >failed to consider the chosen cipher attack, and now
>> >it seems that you confuse failure to recognize the
>> >problem with not having it.
>>
>> A "chosen cipher attack" would imply that the opponent could choose
>> the cipher to be used. That is not possible here.
>>
>> Under my proposals (multi-level ciphering, dynamically changing
>> ciphers, and many ciphers), the cipher would be chosen at random from
>> the set of ciphers acceptable to both ends. The cipher lists may or
>> may not be secret, but the negotiation and selection *would* be
>> secret. This process would be conducted under cipher.
>
>One more time: secret is not the issue. Authenticated
>is the issue.
Well, in cryptography, there are various kinds of authentication:
There is "user authentication," where we identify a particular user as
compared to some other. There is "message authentication," where we
identify that a message has not been changed in transit. There is
"key authentication," where we show that a particular public key is in
fact the current key, and belongs to who we expect. There is
"algorithm authentication," where we identify that the code we wish to
use is in fact the code which the reputable source produced and has
not somehow been modified in transit. Presumably there are other
forms as well. Perhaps you should indicate what form of
authentication is your particular issue.
>One side can certainly make a random
>choice, but your method calls for them to agree, and
>thus the choice must be influenced by messages between
>them. You have simply assumed the choice would be
>random, without ever presenting how they ensure it
>will be random when an attacker may modify the messages
>that influence the choice.
First of all, the "random" selection I propose is exactly the same
sort of thing which produces message keys (or "session keys," if they
are used for multiple messages), which are used in almost every
serious cipher system. Normally, the public-key component transfers
the message key, which is then used in a secret-key system. This is
very well known technology, and the issues are also well known, so
there should be little need to repeat these well known details.
Next, it is true that messages must be sent between the ends to
coordinate cipher changes. But these messages are -- once again --
sent *under cipher*. By "under cipher," I mean that I require that a
cipher already have been established and be in effect. Whatever
cipher system has been established will authenticate received messages
in some way (often with a hash of the plaintext), and thus will detect
"any" attempt by an attacker to "modify the messages." This is very
well known technology, and -- again -- there should be little need to
describe it in detail.
>[...]
>Ritter:
>> >> On the contrary, I have suggested
>> >> that each user be able to create a list of ciphers they will
>accept,
>> >> and then negotiate agreement -- automatically, in the background,
>and
>> >> secretly, under the cover of cipher. This would be an ordinary
>> >> handshake selection, not a cryptographic protocol, but nevertheless
>> >> clearly neither exposed to nor under the control of the opponents.
>> >> How is that related to the adversary choosing the cipher?
>> >
>> >As I noted some time ago, your writings made the point
>> >that the choice of cipher was secret, but were clearly
>> >oblivious to the fact that authentication of the choice
>> >is more important.
>>
>> OBVIOUSLY, any cipher code can be compromised. [...]
>
>Whether an authentication code be compromised is
>beyond the scope of the protocol. The point is the
>need for authentication and its absence from your
>proposal.
If you are describing a need for message authentication, I wholly
agree. This should be a part of any cipher, and is in fact a part of
all of my commercial ciphers. This is very well known technology.
But message authentication is *not* part of the cipher-change
protocols, because those protocols *assume* that message
authentication is performed by the covering cipher. That cipher also
carries normal message traffic, of course, in addition to the
negotiation conversation or channel. The negotiation is the simple
use of the ordinary and expected features of any serious cipher
system.
>> >The details of your protocols have
>> >never appeared, so we cannot tell whether the attack
>> >would work. The fact that you still compare the
>> >negotiation of the cipher to modem protocols, and call
>> >it "an ordinary handshake selection, not a cryptographic
>> >protocol" is rather ominous.
>>
>> How hard do you want to make this?
>>
>
>That could be the mantra of designers of failed
>protocols.
>
>> Selecting a cipher from among a list of approved ciphers simply does
>> not require a cryptographic protocol. I'm sure we could do all sorts
>> of fancy things, and it may be that the selection channel should have
>> additional protection. But the selection itself is straightforward.
>> It is just like two people talking. It is unimportant which cipher we
>> select, as long as both ends agree. The idea is not to select the
>> "best." Indeed, we want to *avoid* selecting "the" best cipher, so
>> that we can select arbitrarily from among a rather large set.
>
>A communications protocol specifies the procedure
>each node executes, including the messages it sends
>and its response to each possible message received.
>The attack people are pointing out is one in which
>the adversary looks at the protocol, and tries to
>find how he can alter the messages to influence the
>choice of cipher towards those that he would prefer.
>It does not weaken the choice to below the strength
>of weakest cipher that the sender would agree to use.
>
>Whether such attacks would work depends upon the
>protocol, and yours has never appeared.
One might reasonably expect the cipher system which encloses the
cipher-change negotiation to have at least the characteristics one now
expects to see in serious ciphers. Identifying those messages whose
contents have changed in transit is a common and expected feature of
serious cipher systems. It thus hardly seems odd that I would expect
such a feature to be included in the enclosing cipher. And, since it
is a feature of *that* system, it is *not* a feature of my protocol
per se, any more than that the enclosing cipher should be secure, and
keys should be properly managed, and public keys certified, and on and
on. These things are to be expected in serious cipher systems. As I
have said over and over again, the negotiation occurs *under* some
established cipher.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Mon, 08 Nov 1999 05:52:50 GMT
On 5 Nov 1999 01:08:04 GMT, in <7vtalk$n8p$[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] (Michael Kagalenko) wrote:
>
>Terry Ritter ([EMAIL PROTECTED]) wrote
>]
>]On 31 Oct 1999 02:39:57 GMT, in <7vga5t$i9m$[EMAIL PROTECTED]>, in
>]sci.crypt [EMAIL PROTECTED] (Michael Kagalenko) wrote:
>]
>]>Terry Ritter ([EMAIL PROTECTED]) wrote
>]>
>]>]
>]>]Whatever frequency "inaccuracies" may exist, will continue to exist,
>]>]in the exact same way, over time. We don't expect crystal oscillators
>]>]to accumulate or generate entropy.
>]>
>]> That's not entirely accurate. Since the quartz crystals dissipate mechanical
>]> energy (by not being ideally elastic), they must then neccessarily produce
>]> random, thermal vibrations (look up fluctation-dissipation
>]> theorem in Graduate Stat. Phys. text)
>]
>]Quartz crystals do dissipate energy, they just dissipate very little
>]energy.
>
> "Very little" is meaningless unless you specify with respect to what
> it is "very little," which you didn't.
Then it seems odd that *you* did not define "very little".
It is well known that dissipation of energy in a resonant system is
related to the "Q" of that system. It is also known that crystal
resonators often have a Q above 100,000. The implication is that less
than one-thousandth of one percent of the energy in the crystal is
dissipated as heat. Does .001 percent seem like "very little" to you?
It does to me.
In any oscillator or resonator system, the frequency determining
element essentially integrates energy over many cycles, here 100,000.
But noise, alas, is incoherent, and so does not accumulate. And that
is why noise has little effect on narrowband systems.
>]I suspect that thermal energy in crystals will produce electrical
>]noise, but of course thermal noise is uncorrelated across the surface
>]plating, so it will mostly "average out."
>
> You do not understand what I wrote, unfortunately. The thermal
> fluctations im mechanical vibration of the crystal will not cancel
> out to the extent that the crystal dissipates the energy. That is
> what fluctutation-dissipation theoprem is about.
Presumably you have some published experimental data on crystal
resonators which will clarify your claims. What are your literature
references for these claims?
>] We know that any such noise
>]is far below the level of normal crystal operation,
>
> No. You do not know it, because it is incorrect.
Quote the literature.
>] even when crystals
>]are used at very low powers (as in narrow-band IF filters in
>]receivers), because if crystal noise was an issue, there would be
>]crystals optimized to produce the minimum amount of noise.
>
> It is no more possible to produce crystals without noise then it is
> possible to produce crystals that do not dissipate mechanical energy,
> as the fluctuation-dissipation theorem ensures.
I have stated that I expect that crystals *do* create some noise. I
have also stated that over long use in detecting very small signals,
with heavy instrumentation intended to expose receiver noise figures,
this "crystal noise" has played such an insignificant role that the
crystal devices are not even optimized for minimum noise production.
This in itself tells us how little effect crystal noise has in real
systems.
>]>]
>]>](Small frequency drifts over minutes or hours or days do exist which
>]>]have a thermal origin. Start-up variations may be very similar from
>]>]one start to the next.)
>]>
>]> It's not just drifts. That is, I would expect those drifts to be like
>]> brownian random walk. It would probably make a neat exercise for
>]> a Graduate level statistics course.
>]
>]You expect incorrectly.
>
> Unfortunately, you did not understand the point that I made.
Then you obviously need to make your point in detail, with additional
clarity and examples. Quoting the literature would be nice.
>] Crystals have been used in radio engineering
>]since the 20's, and their basic properties are well known. The
>]crystal resonant frequency does vary with temperature, and this is
>]repeatable, not random.
>
> That the crystal frequency varies with temperature is both known to me and
> not quie relevant to the poit that I made.
The issue is that the variation of frequency with temperature is well
known to be repeatable and not random.
>]
>]>]
>]>](Picosecond-scale phase variations do exist which are noise-like; I
>]>]attribute those to thermal noise in the analog-to-digital squaring
>]>]process. But these tiny cycle-by-cycle bipolar variations average out
>]>]to what we know as the frequency, and are not detectable using normal
>]>]computing equipment.)
>]>
>]> No, no, no. You are not correct.
>]
>]In crystal oscillators, only the tiny cycle-by-cycle "phase" jitter is
>]noise-like, and that is not detectable with normal computing
>]equipment.
>
> Nonsense. "Phase" jitter accumulates into thermal drift statistically similar
> to the brownian random walk.
Quote the literature which will back this up. I don't want to hear
about the physics which "must" imply this. I want to see published
data which show that thermal drift in crystal oscillators is best
described by a random walk model, rather than a direct correlation
between temperature and frequency. And if you have no such data, you
don't know what you think you know.
>] This phase noise is detectable with precision radio
>]equipment, or with precision logic and super-high-frequency clocks
>]intended to measure periods of fast signals. Phase noise "averages
>]out" over the many cycles needed to establish frequency by counter or
>]timing methods.
>
> You do not understand the statistics very well. Please read introductory book
> on the mathematics of brownian motion.
Not relevant.
>]You may wish to read an earlier Usenet discussion about pulling
>]randomness out of PC crystal oscillators:
>]
>] http://www.io.com/~ritter/RAND/NICORAND.HTM
>]
>]And you may wish to look at the background technical information on
>]the Fox Crystals site:
>]
>] http://www.foxonline.com/techinfo.htm
>
> Unfortunately, you do not display enough knowledge for me to take your suggestions
> seriously.
Right.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.military,talk.politics.misc,talk.politics.crypto
Subject: Re: Signals From Intelligent Space Aliens? Forget About It.
Date: Sun, 07 Nov 1999 21:46:39 -0800
Reply-To: [EMAIL PROTECTED]
Anthony Stephen Szopa wrote:
> Signals From Intelligent Space Aliens? Forget About It.
>
> I believe the United States and the rest of the world will adopt a
> universal communications transmission protocol as soon as the
> technology becomes available to not only encrypt all communications
> transmissions worldwide but to conceal these transmissions as nearly
> as possible among the back ground radiation remnant of the big bang
> in space or other terrestrial back ground noise.
>
> Quantum digital circuits should make this feasible.
>
> Let us not fool ourselves, the Earth is obviously the most import piece
> of real estate in this solar system and possibly in this part of the
> galaxy. It is just as obvious that to announce this fact to the rest of
> the galaxy is quite stupid.
>
> National Security necessitates that we must assume that there are no
> friendly space aliens.
Sorry. I forgot to add my conclusion: Any space alien signals will not be
recognized by us because of space alien security measures. We must assume
they will not be fools.
The question for us: Are we going to fools?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Lenstra on key sizes
Date: Mon, 08 Nov 1999 07:02:57 +0100
Tom St Denis schrieb:
>
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > Paul Schlyter wrote:
> > >
> > > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > >
> > > > A probably very stupid question concerning symmetric ciphers: Does
> > > > it cost terribly more if one uses 512 bits of key instead of 256
> bits?
> > >
> > > I'm not aware of any symmetric cipher having even 256-bit keys.
> > > 128-bit symmetric keys are now considered safe (and will remain so
> > > for perhaps a decade, but certianly not for billions of years.. :-)
> >
> > The question concerns the comparative cost of using longer vs
> > shorter keys. The figures chosen are 'for example' only, i.e. one
> > assumes for the purpose of discussion that a particular symmetric
> > algorithm has two variants, with one having a key double as long
> > as the other. The question is then whether the cost would be
> > prohibitive if one uses the variant with the longer key. (I surmise
> > that the answer would be different, if the question were about
> > asymmetrical ciphers instead of symmetrical ciphers.)
>
> Just because a cipher accepts a larger key doesn't make that the most
> efficient means of attack. If you will assume 128 bits keys as too
> small [say for] blowfish, then 256 bit keys are no more secure [unless
> you send a single block or something].
As my last sentence above indicated, the question is not about
the relation of key length to strength, but about whether the
supply and management of more (say, double) amount of key material
could be a critical 'bottleneck', causing too much cost, inconvenience,
etc. etc., and I surmise that probably isn't one for symmetic ciphers.
M. K. Shen
------------------------------
** 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
******************************
