Cryptography-Digest Digest #712, Volume #11 Fri, 5 May 00 16:13:01 EDT
Contents:
Re: Sample Output from SBOXGEN (Mike Rosing)
Re: Silly way of generating randm numbers? (stanislav shalunov)
Re: quantum crypto breakthru? (Mike Rosing)
Re: AEES Advanced ([EMAIL PROTECTED])
Re: Different encryption results in Java/Perl ([EMAIL PROTECTED])
Re: RC6 as a Feistel Cipher (David A. Wagner)
Re: RC6 as a Feistel Cipher (David A. Wagner)
Re: quantum crypto breakthru? (Roger)
Re: RC6 (tm) as a Feistel Cipher (David A. Wagner)
Re: Silly way of generating randm numbers? (David A. Wagner)
Re: GPS encryption turned off (Paul Rubin)
Re: RC6 as a Feistel Cipher (John Myre)
Re: GPS encryption turned off (Paul Schlyter)
Re: GPS encryption turned off (Paul Schlyter)
Re: GPS encryption turned off (Paul Schlyter)
Re: SBOX program using ideas from CA and ST (CAST design) (Tom St Denis)
Re: RC6 (tm) as a Feistel Cipher (Tom St Denis)
Re: Sample Output from SBOXGEN (Tom St Denis)
Re: KRYPTOS Something new ? (Jim Gillogly)
Re: GPS encryption turned off (Mike Andrews)
cryptographically secure (Ali Tofigh)
Re: quantum crypto breakthru? (Diet NSA)
----------------------------------------------------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Sample Output from SBOXGEN
Date: Fri, 05 May 2000 11:15:27 -0500
Tom St Denis wrote:
> ln2 = size of output in bits
> S = 0
> for x = 0 to n-1
> for y = 0 to log2(n)
> S += HT[f(x) xor f(x xor (1<<y))];
>
> And expect S to be around nlog2(n)(ln2/2), nlog2(n) = number of
> itterations, (ln2/2) = half the bits change...?
That's a basic brute force method, I'd expect S to be a factor of 2
too big since you loop over every possible x. But it should give
the right statistics otherwise.
Patience, persistence, truth,
Dr. mike
------------------------------
Crossposted-To: sci.math
Subject: Re: Silly way of generating randm numbers?
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Fri, 05 May 2000 17:23:03 GMT
[EMAIL PROTECTED] (David Formosa (aka ? the Platypus)) writes:
> Don't all PRNG fail this test?
Yes, but nothing prevents hybrid approaches like Yarrow from producing
sequences with better KC.
--
stanislav shalunov | Speaking only for myself.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: quantum crypto breakthru?
Date: Fri, 05 May 2000 11:34:38 -0500
Roger Schlafly wrote:
> But I see big problems.
>
> (1) QC cannot be used with any router, switch, or repeater
> (with today's technology).
> (2) QC offers no authentication.
> (3) QC offers little protection against active attacks.
> (4) A QC communication could leak a few bits with every
> transmission.
> (5) Imperfect equipment could leak some more info.
>
> Point (4) is just rephrasing your "negligible fraction
> stolen by an eavesdropper". For some applications, leaking
> a small number of bits is acceptable, but for others it is
> deadly.
>
> All of these problems can be addressed by applying some
> conventional cryptographic constructions, but then the
> advantages of QC are negated.
>
> I'd like to hear from anyone who think QC will ever be
> advantageous for anything. What good is it?
There's QC == quantum crypto and QC == quantum computing.
At present, quantum crypto only creates a OTP, and the way
it works there's no leak (what the evesdropper gets, the
2 ends don't get). If or when quantum computers are
made to work, we'll have crypto based on quantum algorithms.
The transmission of the data will be the same as now (but
I would assume a lot faster :-) and not based on matching
photons.
I don't know of any "quantum crypto algorithms" yet. We
really don't have nice quantum computers to play with so
I suspect that it'll be a while before the academics
delve into this area. A 20 or 30 qubit quantum computer
might be able to compete with present day algorithms simply
because simulating the QC would take more computing power
than is available. Making something like that cheap and
reliable is another problem :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: AEES Advanced
Date: Fri, 05 May 2000 17:45:37 GMT
In article <8eun9u$it2$[EMAIL PROTECTED]>,
"ink" <[EMAIL PROTECTED]> wrote:
>
> <[EMAIL PROTECTED]> wrote
> > Hi Scott,
> <cut>
> >
> > Performance of AEES is not good in this comparison. But this is only
> > a question of time,hardware and development.
>
> I'm not a cryptographer and although I've studied your documents
> don't consider myself able to comment on the strength or weakness
> of your cipher. Yet the performance issue you mention is something
> I'd like to comment on. IMHO it is a bad thing to develop a
> software that runs slowly in comparison to existing software,
> essentially doing the same thing and to say that it will get
> faster as soon as better hardware is available. Software should
> offer the best possible performance on *any* platform. Simply
> tying the software performance to the hardware performance is
> what brought us monsters like MS Windows or SAP. A statement
> like "If the program is too slow, use a faster computer" should
> be banned.
>
> Just my 2 cents.
>
> Regards
> Kurt
>
>
Dear Kurt,
There is no existing software for this architecture.
Regards.
Alex.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.lang.java.security
Subject: Re: Different encryption results in Java/Perl
Reply-To: [EMAIL PROTECTED]
Date: Fri, 05 May 2000 18:29:01 GMT
In article <8eppfe$sq9$[EMAIL PROTECTED]>,
Erik Chow <[EMAIL PROTECTED]> wrote:
>I would say it's due to little endian and big endian issue. Java is big
>endian, and I think Perl is platform dependent. Make sure they are the same
>before going any furthuer. If not, convert one of them.
Hi,
I'm author of Perl Crypt::CBC and have worked with the Cryptix and
SSLEay people to ensure compatibility amongst our software. I doubt
that endianness is an issue, as Crypt::CBC, Crypt::Blowfish and the
other Crypt:: modules are all careful to implement the algorithms
using platform neutral "network order" as called for by the
specifications. I can encrypt a stream on a 32-bit big-endian Linux
system and decrypt it on a 64-bit little-endian Solaris system.
More likely, JCE doesn't process the input key and IVs in the same way
that Crypt::CBC does. Crypt::CBC passes the input key through a round
of MD5 hashing in the manner implemented in RSAref and the SSL
libraries. Crypt::CBC also chooses a random initialization vector in
order to protect against known plaintext attacks and transmits this at
the head of the encrypted stream. This stuff may seem frivolous, but
it makes all the difference between an effective CBC encoding and one
that is trivially broken.
Hex encoding is never used in Crypt::CBC, so those of you who think it
involves some funniness in Perl pack/unpack functions are barking up
the wrong tree. I also hasten to reassure you that Perl's
base64-generating functions are platform independent; otherwise none
of the MIME-encoding modules would work properly.
Why doesn't someone compare the JCE source to the Crypt::CBC source
and let me know what the differences are. I'm sure that it will be
easy to fix.
Lincoln
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
[EMAIL PROTECTED] Cold Spring Harbor, NY
========================================================================
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: RC6 as a Feistel Cipher
Date: 5 May 2000 10:58:33 -0700
In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
> Anyway, I have another question. Clearly + doesn't actually
> have to be a group operation, it just needs to have an inverse,
> to create a cipher.
Yes. I think Terry Ritter has pointed out in the past that
it suffices for + to form a Latin Square. I'd be happy to accept
such a generalization as still a "Feistel" cipher, but maybe that's
just me...
> (You can probably see how easy we can make it to "prove" that
> RC6 is a Feistal cipher, if we choose the right definition).
Yes, I see what you mean. I must admit I still have no idea what
Bob Silverman meant by his suggested exercise, or what number theory
has to do with it... (I thought the only number theory in RC6
was in the permutation polynomial stuff, i.e., in showing that
its squaring-like map mod 2^32 is bijective.)
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: RC6 as a Feistel Cipher
Date: 5 May 2000 11:01:19 -0700
In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
> Here's another thought. What about input and output
> whitening? I guess if + is round-dependant, then we can
> subsume the whitening in as special rounds (at least two
> rounds at each end so as to get the swapping right).
Good point! I'd never thought of that...
> Or is that "cheating"?
For that, you'll have to ask Bob Silverman what he meant, I guess...
------------------------------
From: Roger <[EMAIL PROTECTED]>
Subject: Re: quantum crypto breakthru?
Date: Fri, 05 May 2000 11:41:32 -0700
Mike Rosing wrote:
> At present, quantum crypto only creates a OTP, and the way
> it works there's no leak (what the evesdropper gets, the
> 2 ends don't get).
Actually, the implementations can leak bits because of
physical errors. For some current work, see:
http://www.quantum.univie.ac.at/research/crypto/
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: RC6 (tm) as a Feistel Cipher
Date: 5 May 2000 11:09:08 -0700
In article <[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> input = (a, b, c, d)
> t = F(c); a = ROTL(a ^ d, t) + S[4*r+4];
> t = F(d); b = ROTL(b ^ c, t) + S[4*r+5];
> t = F(a); c = ROTL(c ^ b, t) + S[4*r+6];
> t = F(b); d = ROTL(d ^ a, t) + S[4*r+7];
Well, I think 20 rounds of this variant (5 repetitions of the above)
can be broken with something like O(2^25) chosen plaintexts, using a
birthday attack (the internal pipe between the a/d and the b/c halves
is very narrow).
That doesn't sound good, and it doesn't compare well to RC6.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Crossposted-To: sci.math
Subject: Re: Silly way of generating randm numbers?
Date: 5 May 2000 11:13:15 -0700
In article <[EMAIL PROTECTED]>,
Richard Heathfield <[EMAIL PROTECTED]> wrote:
> As far as I'm aware, pi passes all mathematical tests for randomness.
Apart from the trivial fact that pi is fixed (and thus hardly random) :-),
it turns out there is also an ever-so-slight bias in its digits, if I
remember correctly. See the rec.puzzles archive for details.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Crossposted-To: sci.geo.satellite-nav
Subject: Re: GPS encryption turned off
Date: 5 May 2000 19:15:37 GMT
In article <8eujh5$rg9$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>In article <8ethgo$lp$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Paul Rubin) wrote:
>>
>> That seems like a serious vulnerability to me.
>
>There is always a trade-off between operational vulnerability and
>hardware vulernability. The operational vulnerability from propagating
>physical keys currently outweighs the hardward vulnerability from
>receiver exploitation. Hence, OTAR is less vulnerable than physical
>re-keying...TODAY.
I don't understand this reasoning (which doesn't mean it's wrong).
What is the operational vulnerability of propagating physical keys?
I've heard (not sure) that current units must be re-keyed in a secure
facility.
>> I can't bring myself to believe the tamper resistant circuitry will
>> stay secure, especially over a long period of technology advances.
>
>You're right about the advance of technology. As the bad guys build
>their multi-billion dollar material science forensic labs, the advantage
>will swing back to the operational side. Of course, by then, the new
>tamper resistant technology will be on its way out the door and the
>cycle will begin anew.
The trouble is, with OTAR, the new tamper resistance will be
protecting the exact same secret as the old tamper resistance, unless
new tamper resistance developments means obsoleting ALL old receivers
and making them not work any more.
Otherwise, once you can get the secrets out of an old receiver without
getting that receiver blacklisted, you get all the new secrets over
the air. That's why physical key updating seems more secure to me.
Do they have a way around that problem?
>> >Personally and without any substantiating information, I believe that
>> >this new approach is being put into place due to a compromise of the
>> >keys for the current system.
>
>This is the natural evolution within the realm of counter and
>countermeasure security. As you stated earlier, today's tamper
>resistance will not be resistant to future technology advances. You
>always have to be ahead of the enemy.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: RC6 as a Feistel Cipher
Date: Fri, 05 May 2000 13:20:50 -0600
I wrote:
<snip>
> "David A. Wagner" wrote:
> >
> > In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
> > > With respect to (mathematical) proofs, how is "Fiestel Cipher" defined?
> >
> > There's nothing really tricky here.
> >
> > Suppose a cipher may be written as a composition of "rounds",
> > where each round encrypts the input (L,R) to the output (R,L+f(R))
> > for some key-dependent function f and some group operation +
> > (both of which may possibly depend on the round number).
> >
> > Then the cipher is a Feistel cipher.
Just to belabor the subject even more, what about IBM's "Type 3
Fiestal network" (MARS)? Is that a "Fiestal cipher"? What's a
"Type 2"? Is there a "Type 4"? (For that matter, is "Type 1"
a traditional Fiestal network, or something else?)
And then, Schneier and Kelsey coined some terminology, as well
(including concepts like "balanced" and "unbalanced", "homogeneous"
vs "heterogeneous", and others) in a paper on the subject.
I'm beginning to suspect that "Feistal cipher" is not rigorously
well defined. So a challenge like "prove RC6 is a Fiestal Cipher"
probably needs to be more specific. Unless, I suppose, you want
to treat it like a term paper or something, and you want to explore
what definitions work, and which don't, and why.
John M.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: GPS encryption turned off
Date: 5 May 2000 19:23:21 +0200
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
> Paul Rubin wrote:
>> ... and
>> only three of them need to be in view for a GPS fix,
>
> Four, actually -- unless you know one of your four
> coordinates already with high accuracy. For example,
> when at sea you know z.
Some GPS receivers (including my own Garmin 12XL) will, when only 3
satellites are available, do a solution based on the assumption that
z = sea level.
Also: many GPS receivers (including my own Garmin 12XL) seem to try
to solve for longitude and latitude more accurately than for altitude.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: GPS encryption turned off
Date: 5 May 2000 19:04:58 +0200
In article <a0wQ4.1305$[EMAIL PROTECTED]>,
Stou Sandalski <tangui [EMAIL PROTECTED]> wrote:
> "Paul Schlyter" <[EMAIL PROTECTED]> wrote in message
> news:8esuno$fus$[EMAIL PROTECTED]...
>> In article <[EMAIL PROTECTED]>,
>> Paul Koning <[EMAIL PROTECTED]> wrote:
>>
>>> Neither does GPS; in fact, GPS satellites are in lower orbits
>>> (a few thousand miles if memory serves) than TV satellites (which
>>> are in the Clarke orbit).
>>
>> The GPS satellites orbit in 12-hour orbits, which will put them
>> approx. 20,000 km above the Earth's surface. The Clarke orbit is
>> 36,000 km above the Earth'ss surface.
>
> I am again OTicking here but I was under the imression that the gps
> sats are in geosyncronous orbit,
They aren't -- if they were, coverage at high latitudes would be bad.
> since if they are moving with relation to you, you will constantly
> need to calculate where the sats are in relation to earth's
> surface and where you are in relation to them?
That's exactly what the GPS receivers are doing. The GPS satellites
send out ephemeris information about themselves, as well as accurate
time information (each GPS satellite carries an atomic clock), all
the time (presumably simple Keplerian orbital elements which are
updated frequently will do fine here), which enables the GPS receiver
to compute where they all are. Then by measuring small differences
in arrival time of the GPS signals, the GPS receiver can figure out
where it resides relative to the GPS satellites. Finally, a model of
the size and shape of the Earth is applied, which yields longitude,
latitude and altitude above sea level, for any geodetic datum of your
choice.
Yes, it's complex. But it works.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: GPS encryption turned off
Date: 5 May 2000 19:22:57 +0200
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
> Guy Macon wrote:
>
>> Clarke (AKA Geostationary) orbits miss the poles, but LEO (Low Earth
>> Orbit) military satellites typically cover the entire planet with
>> satellites that (oversimplified explaination alert!) orbit from
>> pole to pole as the earth turns underneath.
>
> Right, that's one good reason why GPS satellites use
> lower orbits (and inclined ones). And they cover the
> whole earth with the constellation -- but any individual
> satellite at any particular instant only covers a medium
> size patch. So it could operate with SA part of the time
> (when over the bad guy's territory) and without it the
> rest of the time.
Another reason to use LEO rather than GEO is that the distance to the
satellite will be smaller, and the received signal will then be
stronger. Which means the receiver will work with a smaller antenna.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: SBOX program using ideas from CA and ST (CAST design)
Date: Fri, 05 May 2000 19:30:52 GMT
Tim Tyler wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> : I currently test if each individual boolean function (2^n by 1) is
> : non-linear [1] and follows SAC. Then I compose the log2(n) functions
> : together and check if it's a bijection [2]. After that I do a Bit
> : Independance Test.
>
> 2^n /and/ log2(n)? That seems strange.
>
> The order of the tests can make big performance differences.
>
> For example, if you can arrange things so that you can generate a
> new permutation by shuffling the current shuffled set when a test
> on the set fails, that can help.
>
> : [1] I am having trouble knowing how to bound the WalshTransform output
> : of a n-bit function so that I can be sure it's non-linear... any help?
>
> I know of no way of calculating the maximum non-linearity of a
> variable-size boolean function (and would be interested to learn of
> any that accurately determine it and are much faster than testing all
> functions of that size).
>
> The maximum non-linearity values for small values of n are known, though.
I read up that a function is perfectly non-linear (i.e bent) if
|FW(f)w| = 2^(n-2) for all w
Where FW is the walsh transform of the GF(2)^n -> GF(2) function 'f'
and 'n' is the number of bits in the input, 0 <= w < 2^n.
Is that right?
Then you can't have perfectly non-linear functions when 'n' is odd? Of
course the first check works, 2^(n-2) for a 4x1 is 2^(4-2) = 4, where 4
is actually the best you can do. This means for 8x8 I should expect 2^6
= +-64 as the FW output?
How does this notation of bent extend to n by n functions? Do I do this
FW function
for alpha = 0 to 2^n-1
for beta = 0 to 2^n-1
test if |FW(f)(alpha, beta)| is too high?
What should I expect as the maximum for any n by n function in this
case?
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RC6 (tm) as a Feistel Cipher
Date: Fri, 05 May 2000 19:32:13 GMT
"David A. Wagner" wrote:
>
> In article <[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > input = (a, b, c, d)
> > t = F(c); a = ROTL(a ^ d, t) + S[4*r+4];
> > t = F(d); b = ROTL(b ^ c, t) + S[4*r+5];
> > t = F(a); c = ROTL(c ^ b, t) + S[4*r+6];
> > t = F(b); d = ROTL(d ^ a, t) + S[4*r+7];
>
> Well, I think 20 rounds of this variant (5 repetitions of the above)
> can be broken with something like O(2^25) chosen plaintexts, using a
> birthday attack (the internal pipe between the a/d and the b/c halves
> is very narrow).
>
> That doesn't sound good, and it doesn't compare well to RC6.
Yeah we already discussed this actually. Can you consider the
modification I replied with?
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Sample Output from SBOXGEN
Date: Fri, 05 May 2000 19:33:22 GMT
Mike Rosing wrote:
>
> Tom St Denis wrote:
> > ln2 = size of output in bits
> > S = 0
> > for x = 0 to n-1
> > for y = 0 to log2(n)
> > S += HT[f(x) xor f(x xor (1<<y))];
> >
> > And expect S to be around nlog2(n)(ln2/2), nlog2(n) = number of
> > itterations, (ln2/2) = half the bits change...?
>
> That's a basic brute force method, I'd expect S to be a factor of 2
> too big since you loop over every possible x. But it should give
> the right statistics otherwise.
Yes it actually is twice as big as it should, how would I change it?
Tom
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: KRYPTOS Something new ?
Date: Fri, 05 May 2000 19:50:20 +0000
[EMAIL PROTECTED] wrote:
> after analysis and hints from Gillogly, the following pattern emerges:
>
> if you write all the 97 chars in rows of 7 chars you'll see
> that there are 5 out of 6 DOUBLE-LETTERS patterns that are
> ALIGNED i the same COLUMN:
I agree that this is unusual and probably significant, but I haven't
been able to make any thing of it. I tried several things relating
to this a few months ago, including combined poly/transp with period
14 (which would cause this effect if there were a repeated word at
offset 14), but that doesn't seem to work... at least not the way I've
been trying it.
Keep after it -- something this odd and consistent is probably causal.
--
Jim Gillogly
15 Thrimidge S.R. 2000, 19:46
12.19.7.3.5, 4 Chicchan 8 Uo, Second Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Mike Andrews)
Subject: Re: GPS encryption turned off
Date: Fri, 05 May 2000 19:53:08 GMT
Scripsit Guy Macon <[EMAIL PROTECTED]>:
: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul Koning)
: wrote:
:>Interestingly enough, SA has been turned off before. For
:>example, during the Gulf War, so the US military could use
:>commercial off the shelf GPS units and get good accuracy.
:>(Apparently they couldn't get enough P/Y units.)
: I thought that they *disabled* the commercial GPS boxes.
The SPS (public and unclassified) signal is used by the military
GPS boxes to synchronize to the P(Y) signal. Unless there is
something new that I'm unaware of, a military GPS _can't_ sync up
in precision mode without the SPS signal.
And during the Gulf War, IIRC, the US military was still ramping
up production of high-precision military GPS receivers (PLGR, etc.),
and that's why commercial SPS receivers became scarce for a while.
Under those circumstances, it would make sense to turn off SA and
let the Allied forces have the best tool possible -- the more so
since the Iraqui forces didn't have many (if any) GPS receivers
at all.
--
>From RFC 1925: "(3) With sufficient thrust, pigs fly just fine. However,
this is not necessarily a good idea. It is hard to be sure where they are
going to land, and it could be dangerous sitting under them as they fly
overhead."
------------------------------
From: Ali Tofigh <[EMAIL PROTECTED]>
Subject: cryptographically secure
Date: Fri, 5 May 2000 22:01:18 +0200
Hi!
I'm in urgent need for a cryptographically secure random number
generator... I'm studying cryptography and implementing an RSA-system
and therefore I need a random number generator that can generate
large numbers. Around 400-500 bits long at least.
Regards
A.T.
------------------------------
Subject: Re: quantum crypto breakthru?
From: Diet NSA <[EMAIL PROTECTED]>
Date: Fri, 05 May 2000 13:08:17 -0700
In article <[EMAIL PROTECTED]>, Roger Schlafly
<[EMAIL PROTECTED]> wrote:
>(2) QC offers no authentication.
There are various potential quantum authentication protocols.
>(3) QC offers little protection against active attacks.
At least one scheme has been theoretically proven secure against
a MITM attack. Depending on what kind of active attacks you are
thinking about, they may be detected.
>(4) A QC communication could leak a few bits with every
>transmission.
>(5) Imperfect equipment could leak some more info.
The concept of unicity distance can be generalized to apply to
quantum situations. It is possible to calculate how much a
potential eavesdropper would have to know about the qubits being
used.
>I'd like to hear from anyone who think QC will ever be
>advantageous for anything. What good is it?
>
>
It is rumored (e.g., in Singh's book) that the NSA is developing
quantum encrypted fiber optic networks for the Pentagon.
"If we do not prevent highly classified secrets from being stolen,
then how are we going to sell them to the Chinese?"
- Madeleine Albright (addressing recent thefts)
========================================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
** 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
******************************
