Cryptography-Digest Digest #710, Volume #10 Thu, 9 Dec 99 13:13:02 EST
Contents:
Re: Synchronised random number generation for one-time pads ("Tony T. Warnock")
Re:NASA measurements, was: NSA future role? ("Tony T. Warnock")
Re: low exponent in Diffie-hellman? (jerome)
Re: Curious Phenomena....Re: High Speed (1GBit/s) 3DES Processor (MegaZone)
Re: low exponent in Diffie-hellman? (jerome)
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Re: High Speed (1GBit/s) 3DES Processor (Helger Lipmaa)
Re: Synchronised random number generation for one-time pads (Guy Macon)
Re: weak algorithm, too hard for me (Guy Macon)
Seeking Free Internet CA ("Erich Trowbridge")
Re: NSA future role? (CLSV)
Re: Random Noise Encryption Buffs (Look Here) ("Tony T. Warnock")
Re: Random Noise Encryption Buffs (Look Here) (John Myre)
Re: How can you tell? ("Tim Wood")
Re: weak algorithm, too hard for me (JPeschel)
Re: NSA should do a cryptoanalysis of AES (Tim Tyler)
Compiling TwoFish with DJGPP (Roger Carbol)
Re: Curious Phenomena....Re: High Speed (1GBit/s) 3DES Processor (Paul Koning)
Re: AES and perl (encryption) ("Shaun Wilde")
Re: low exponent in Diffie-hellman? (Ian Goldberg)
Re: Shamir announces 1 sec break of GSM A5/1 (Ian Goldberg)
Re: Synchronised random number generation for one-time pads (doc)
Re: Synchronised random number generation for one-time pads ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: Random Noise Encryption Buffs (Look Here) ("Douglas A. Gwyn")
Re: Shamir announces 1 sec break of GSM A5/1 (Paul Koning)
----------------------------------------------------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Synchronised random number generation for one-time pads
Date: Thu, 09 Dec 1999 08:09:21 -0700
Reply-To: [EMAIL PROTECTED]
Tim Tyler wrote:
> amadeus wrote:
>
> : OTP is totally secure given it is properly used. The problems are key
> : distribution and key cancellation/deletion. [...]
>
> Then there's the issue that a known-plaintext attack reveals the key - and
> possibly allows inauthentic messages to be passed off as the real one.
>
> Authenticity is a problem for OTPs.
>
> With your typical block cypher, knowing the plaintext does *not*
> instantly reveal the message key, and allow forged message(s) to be sent.
> --
This cannot be a problem in correct use of a OTP. The O means "one" no reuse
allowed. No segment of the OTP can be reused. Else it's not a OTP, perhaps a
1.05TP. See the Venona site.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re:NASA measurements, was: NSA future role?
Date: Thu, 09 Dec 1999 08:19:11 -0700
Reply-To: [EMAIL PROTECTED]
NASA people told me that the problem was a bit more subtle. Reporting of
measurements in US units was changed to reporting in metric units for
some items. This was done quietly. People deal with measurements in
differing systems all the time. It's harder when things are changed
quietly. No one with enough experience to see the difference in the
numbers was working on the project.
As usual, it takes several failures for something not to work.
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: low exponent in Diffie-hellman?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 09 Dec 1999 15:18:30 GMT
thanks for the answer
On Thu, 09 Dec 1999 14:28:19 GMT, Bob Silverman wrote:
>>(some RSA implementations got issues about that
>
>Citations please?
>This is another "urban legend".
probably my formulation of the problem is wrong but i don't think
it is a urban legend. There is an article of weiner about it.
i found a post on coderpunks of somebody quoting you.
http://www.privacy.nb.ca/cryptography/archives/coderpunks/new/1998-05/0127.html
------------------------------
Crossposted-To: comp.dcom.vpn,comp.security.firewalls
Subject: Re: Curious Phenomena....Re: High Speed (1GBit/s) 3DES Processor
From: [EMAIL PROTECTED] (MegaZone)
Date: 09 Dec 1999 15:39:44 GMT
[EMAIL PROTECTED] shaped the electrons to say:
>Because his headers contain the following:
>> Content-Type: text/plain; charset=iso-2022-jp
Weird. I guess something is changing that before my server gets it, as I
checked his headers and found:
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
-MZ, CISSP #3762, RHCE #806199299900541
--
<URL:mailto:[EMAIL PROTECTED]> Gweep, Discordian, Author, Engineer, me..
Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
"A little nonsense now and then, is relished by the wisest men" 781-788-0130
<URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: low exponent in Diffie-hellman?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 09 Dec 1999 15:37:41 GMT
On Thu, 09 Dec 1999 14:28:19 GMT, Bob Silverman wrote:
>> can i reduce x to 128bits (enougth to prevent a brute force) ?
>
>A variation of the Lambda method allows finding x in time
>O(sqrt(b-a)) if x is known to lie in the interval [a,b]. So,
>if you reduce x to 128 bits, it can be found in about 2^64
>group operations. ---> not secure!
i don't know the method you are speaking about but i think about a
possible trick.
if g is constant across several g^x mod p calculations, i can have a
x of 768bits with only the 128 most significant ones which are
modified. the 640 least significant ones will be contants and
precomputed. so my exponantiation loop does only 128 iterations.
O(sqrt(b-a)) is in my case O(sqrt(2^768-2^640)) defeating this attack.
we can avoid the precomputation of the 640 bits if we set them to 0,
thus it is no more needed to have g constant.
is "my fix" silly ?
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: 09 Dec 1999 10:49:00 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Trevor Jackson, III) wrote:
>> >The most probable waiting time between decays is zero.
>>
>> No it isn't.
>
>How do you figure otherwise? Given an exponential decay
>expectation the maxima will be at zero.
I was under the impression that the exponential decay came
from the fact that there are a finite number of atoms in
the sample and that each atom decays only once. I don't
think (correct me if I am wrong) that individual radium
atoms have an exponential decay expectation.
------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Crossposted-To: comp.dcom.vpn,comp.security.firewalls
Subject: Re: High Speed (1GBit/s) 3DES Processor
Date: Thu, 09 Dec 1999 17:39:51 +0200
Paul Koning wrote:
> Same here, but I expect he was referring to the work of Hans Eberle,
> still quoted in the second edition references (from Crypto '92). Or you
> can read the DEC SRC research report, number 90, "A High-speed DES
> implementation for network applications", H. Eberle, Sept 23, 1992.
>
> > Apply Moore's law (and divide by
> > three to get 3DES;).
>
> Don't divide by three, just triple the transistor count. Trivial
> these days, as David pointed out.
Well, you can do everything.
> I guess this discussion implies that crypto protocols should start
> using interleaved CBC rather than classic uninterleaved CBC. That
> would fix the pipeline bottleneck we currently have.
The url I pointed to (http://home.cyber.ee/helger/fastidea) and the numbers
I refered to (>300 Mbit/s on a 700 MHz P3) correspond to a parallel
implementation of IDEA. Haven't looked closely at the hardware implementations
of 3DES, but the fastest hardware for IDEA also works in a parallel mode
(achieving 200 Mbit/s - less than the software implementation). So... Yes, you
are true (and it's a point I've been personally pressing for more than a year).
Parallel implementations can be used in counter mode and CBC decryption,
however - I personally don't feel that easy about interleaved CBC.
Helger Lipmaa
http://home.cyber.ee/helger
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Synchronised random number generation for one-time pads
Date: 09 Dec 1999 10:57:56 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Jim Dunnett) wrote:
>OTP is totally secure given it is properly used. The problems are key
>distribution and key cancellation/deletion. With more than two correspondents
>it becomes a nightmare, or degenerates into something which is no longer OTP.
You hit the nail on the head.
>People on this newsgroup would probably question the need for an OTP system
>if you already have a secure route. But that secure route need not be
>electronic, normally you would deliver the key physically on some physical
>media.
To my way of thinking, it is a great advantage to be able to transfer
a CD-ROM to someone by hand when we are together, then later send a
secure message through unsecure channels when we are apart. Of course
a memorized keyphrase is much better than a CD-ROM in this respect.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: weak algorithm, too hard for me
Date: 09 Dec 1999 11:04:38 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Gaccm) wrote:
>ok, the reason that i am a moron, is that i forgot an important
>password. I had it connect automatically, and thus forgot it. I connect
>to a server with WS_FTP Pro 6.02, and it saves your passwords but does
>not display them. so, i tried a few combos and saved the encrypted
>version of the password. I checked the manual, and it said that is was
>very easy to break the encrytion, but i can't. I was hoping that someone
>here could: 1)do it for me, 2)show me how to, 3) tell me where i should
>post.
If all else fails, who has administrator rights to that server? Is it
an ISP? Can you phone someone and ask what it is?
Another alternative would be a sniffer program. Sometimes the password
is sent to the server without encryption. Are you ethernet or dialup?
------------------------------
From: "Erich Trowbridge" <[EMAIL PROTECTED]>
Subject: Seeking Free Internet CA
Date: Thu, 9 Dec 1999 08:19:13 -0800
I am looking for a free Internet certificate authority capable of
providing IKE services for a distributed IPSec business implementation. The
number of keys needing housing will probably never exceed 100.
Does such a service exist?
Please forward all responses to the group and [EMAIL PROTECTED]
Thanks in advance,
erich
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: NSA future role?
Date: Thu, 09 Dec 1999 16:19:09 +0000
"SCOTT19U.ZIP_GUY" wrote:
[...]
> To even quote Mr BS himself he even stated on this forum that for him
> designing long key crypto methods that are secure would be much harder
> for him.
Long key crypto certainly has its uses. But I also believe that
it is *much* harder to write an algorithm that uses a long key
in a useful way. It doesn't make much sense to design an algorithm
that uses 16384-bits keys but can be broken using *only* 1024-bits.
> This was to help foster the flase impression that the NSA wants
> people to belive. Yes he and the NSA will do a good job on selling the
> AES stuff as secure. But do you really think the NSA would allow a
> secure crypto system to become a US standard that they could
> not easily brake.
I think you look up too much to the NSA. If the NSA can brake
an algorithm than there are probably two or three other agencies
that can brake it. The NSA knows this as well and I think they
rather have a secure algorithm than one that gives the Russians,
Chinese, Israeli, French (...) easy access to commercial secrets.
Regards,
Coen Visser
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Thu, 09 Dec 1999 09:21:32 -0700
Reply-To: [EMAIL PROTECTED]
Guy Macon wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Trevor Jackson, III)
>wrote:
>
> >> >The most probable waiting time between decays is zero.
> >>
> >> No it isn't.
> >
> >How do you figure otherwise? Given an exponential decay
> >expectation the maxima will be at zero.
>
> I was under the impression that the exponential decay came
> from the fact that there are a finite number of atoms in
> the sample and that each atom decays only once. I don't
> think (correct me if I am wrong) that individual radium
> atoms have an exponential decay expectation.
Since I started the thread by mentioning the most probable waiting time is zero, I'll
also
comment that the is is true for individual atoms. The exponential decay applies to each
atom. QM's like that. An individual acts like it was an ensemble.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Thu, 09 Dec 1999 09:16:09 -0700
Tim Tyler wrote:
<snip>
>
> *Perhaps* you thought I was talking about the frequency of the *radiation*
> rather than the frequency of the rays hitting the Earth - and didn't
> consider the other interpretation.
*Perhaps* if you had written "intensity" (as per the quoted material!)
instead of "frequency" then your post would not have needed
"interpretation".
"When Tim uses a word, it means what *he* wants it to mean".
Sigh.
------------------------------
From: "Tim Wood" <[EMAIL PROTECTED]>
Subject: Re: How can you tell?
Date: Thu, 9 Dec 1999 16:30:02 -0000
This software is obviously bad, I'll crack it soon.
Encrypted with A ( 65)
A file containing
A -> 250 (extended character code)
B-> 251
C-> 248
D-> 249
E-> 254
F-> 255
Also
A under A -> 250
A under AA -> 250
in fact A under always seems to encrypt to 250 under any password beginning
with A.
Also
AA under A encrypts to 250 125
AB under A encrypts to 250 124
AC under A encrypts to 250 127
AD under A encrypts to 250 126
It's eminently breakable I feel, I'm just not to good at this kind of thing.
tim
--
**<Stolen line alert>**
>From my one-bit brain with a parity error.
**</Stolen line alert>**
Mike Andrews wrote in message ...
>John <[EMAIL PROTECTED]> wrote:
>: If I experiment with passwords, have the program, but no source, isn't
>: it possible to deduce what the encrypter is doing?
>
>Only in the sense that you can compile a "dictionary" or
>"codebook" showing all your inputs and all the outputs
>from the program. The idea behind encryption programs
>is that the algorithm is _very_ difficult to invert
>without knowing the specific encryption key, even if
>you _do_ have the program.
>
>: http://www.aasp.net/~speechfb
>
>Ah, I see a challenge and some snake-oil. Anyone got a sacrificial
>machine to run this on?
>
>--
>Mike Andrews
>[EMAIL PROTECTED]
>Tired old sysadmin since 1964
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: weak algorithm, too hard for me
Date: 09 Dec 1999 16:29:34 GMT
[EMAIL PROTECTED] writes:
>If all else fails, who has administrator rights to that server? Is it
>an ISP? Can you phone someone and ask what it is?
>
>Another alternative would be a sniffer program. Sometimes the password
>is sent to the server without encryption. Are you ethernet or dialup?
>
Gee, it's not that tough, guy!
I already gave him the password.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Reply-To: [EMAIL PROTECTED]
Date: Thu, 9 Dec 1999 16:24:25 GMT
Johnny Bravo <[EMAIL PROTECTED]> wrote:
: (SCOTT19U.ZIP_GUY) wrote:
:> Since we are being hypathetical. lets assume our Jewish
:>friends have captured 3 Moslem terroists. And that Isreally
:>intellagnce knows that 3 three have encrypted the message
:>Such that the first one encrypted the message.
: This is where the entire scenario falls apart. They just torture
: the plaintext out of this guy, bypassing the encryption entirely.
What if this guy is the radio operator? You expect him to memorise
the text of every message he sends?!
He may no longer have access to the plaintext of the message - while he
may still remember the password he used as a key to encrypt it.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
HePL! Imat arppdei sndi eht eDP-P1.
------------------------------
Subject: Compiling TwoFish with DJGPP
From: Roger Carbol <[EMAIL PROTECTED]>
Date: Thu, 09 Dec 1999 16:58:28 GMT
I was able to successfully compile the TwoFish source code
under DJGPP by adding the following section to PLATFORM.H
#ifndef _M_IX86
#ifdef __DJGPP__
#define _M_IX86 300
#endif
#endif
This was placed right after the code testing for __BORLANDC__
and before the code testing for _M_IX86 (of course.)
I also used, instead of COMPILE.BAT, the command
gcc -O3 -v -DGetCodeSize tst2fish.c twofish2.c -o tst2fish.exe
in order to produce the executable.
Hopefully this proves useful to others wishing to use and/or
study this algorithm.
.. Roger Carbol .. [EMAIL PROTECTED]
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: comp.dcom.vpn,comp.security.firewalls
Subject: Re: Curious Phenomena....Re: High Speed (1GBit/s) 3DES Processor
Date: Thu, 09 Dec 1999 11:55:42 -0500
Casey wrote:
>
> Hi Paul. I was wondering... Starting with the post you made on or about
> 11/17 on this thread, everytime I read messages from you, I get a window
> panel that says I should download a Japanese symbol interpreter. It is only
> messages that you originate. Subsequent messages on the thread from other
> people don't require it, but subsequent messages from you on the thread do.
> Any ideas why?
Defective news reader (Netscape). I once had it set to handle
Japanese text, but I changed the default back to Western (ISO 8859-1)
because of that problem. But it still mentions the Japanese
character set in the headers it constructs. So it's a bug.
I'll see if I can beat it into submission. Meanwhile, sorry
about that...
paul
------------------------------
From: "Shaun Wilde" <[EMAIL PROTECTED]>
Subject: Re: AES and perl (encryption)
Date: Thu, 9 Dec 1999 17:12:34 -0000
I can call C from Perl? I didn't know that but then I am a beginner to
Perl - however not to C (C++) so it does make a sensible route to go.
Volker Hetzer <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Shaun Wilde wrote:
> >
> > Has anybody ported the the AES submission Twofish to perl?
> >
> > Also does anyone know of any Perl sites that have info relating to
> > encryption
> For perl you should be able to use the C-Version of AES as a shared
> library shouldn't you?
>
> Greetings!
> Volker
> --
> Hi! I'm a signature virus! Copy me into your signature file to help me
> spread!
------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Subject: Re: low exponent in Diffie-hellman?
Date: 9 Dec 1999 17:14:07 GMT
In article <[EMAIL PROTECTED]>,
jerome <[EMAIL PROTECTED]> wrote:
>On Thu, 09 Dec 1999 14:28:19 GMT, Bob Silverman wrote:
>>> can i reduce x to 128bits (enougth to prevent a brute force) ?
>>
>>A variation of the Lambda method allows finding x in time
>>O(sqrt(b-a)) if x is known to lie in the interval [a,b]. So,
>>if you reduce x to 128 bits, it can be found in about 2^64
>>group operations. ---> not secure!
>
>i don't know the method you are speaking about but i think about a
>possible trick.
>if g is constant across several g^x mod p calculations, i can have a
>x of 768bits with only the 128 most significant ones which are
>modified. the 640 least significant ones will be contants and
>precomputed. so my exponantiation loop does only 128 iterations.
>O(sqrt(b-a)) is in my case O(sqrt(2^768-2^640)) defeating this attack.
>we can avoid the precomputation of the 640 bits if we set them to 0,
>thus it is no more needed to have g constant.
>
>is "my fix" silly ?
Well, maybe not "silly", but it doesn't work.
Let your secret (768-bit) x = a*x^640 + b, where a is a random 128-bit
number, and b is a fixed 640-bit number.
If b is known to your attacker (if it's all 0's, say), then when she sees
g^x, she knows g^x = h^a * g^b, where h = g^(2^640), so h^a = g^x / g^b
is known. Then finding a is a 64-bit problem, and you're done.
If b isn't known, just divide two outputs to remove the g^b part,
and continue as above. (You'll end up with the *difference* of the x's,
but I think you can make progress from there.)
In any case, I was under the impression that the attack Bob mentioned
is actually more general, and it's actually the case that using exponents
where all but b of the bits are fixed (*any* choice) gives a 2^(b/2) attack.
The "normal" case is where you fix all but the bottom b bits to 0.
Bob is invited to correct me if I've misremembered. :-)
- Ian
------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Subject: Re: Shamir announces 1 sec break of GSM A5/1
Date: 9 Dec 1999 17:19:40 GMT
In article <[EMAIL PROTECTED]>,
Gurripato <[EMAIL PROTECTED]=NOSPAM> wrote:
>On 09 Dec 1999 05:37:45 GMT, [EMAIL PROTECTED] (JTong1995) wrote:
>
>>Cell Phone Crypto Penetrated
>>by Declan McCullagh
>>10:55 a.m. 6.Dec.1999 PST
>
>>James Moran, the fraud and security director of the GSM Association in
>>Dublin, says that "nowhere in the world has it been demonstrated --an
>>ability to intercept a call on the GSM network. That's a fact....
>
> Another proof is that, in many countries, that demonstration
>would break the law, so researchers are forbidden from proving it.
>Absence of proof does not imply proof of absence.
>
>>To our knowledge there's no hardware capable of intercepting."
>
> Guess the NSA didnīt invite them to their annual
>see-all-our-surveillance-hardware, hmm?
It's dumber than that. His *member companies* _sell_ such equipment,
either for testing purposes, or for Law Enforcement access. It's
inconceivable that he doesn't know that.
- Ian "You keep using that word. I do not think it means what you
think it means."
------------------------------
From: doc <[EMAIL PROTECTED]>
Subject: Re: Synchronised random number generation for one-time pads
Date: Thu, 09 Dec 1999 12:16:00 -0500
"Tony T. Warnock" wrote:
>
> > Authenticity is a problem for OTPs.
> >
> > With your typical block cypher, knowing the plaintext does *not*
> > instantly reveal the message key, and allow forged message(s) to be sent.
> > --
>
> This cannot be a problem in correct use of a OTP. The O means "one" no reuse
> allowed. No segment of the OTP can be reused.
I think that the point was that while it cannot be reused,
it
might be intercepted and changed.
DOC
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Synchronised random number generation for one-time pads
Date: Thu, 9 Dec 1999 02:04:09 GMT
Charles Meigh wrote:
> Would it be practicable to set up a system that creates the random numbers
> for the key from some globally consistent, 'natural' source like, say,
> cosmic radiation readings; the sender and receiver obviously having had
> exchanged brief, secure messages agreeing on exactly when to take these
> key-generating readings? You could then (if i'm thinking right) create as
> many completely secure one-time pads as you like, without the overhead of
> distributing vast amounts of data first, just your synchronising messages.
There is no such source, but even if there were, the cryptanalyst
would presumably have equal access to it, hence could try various
possible key locations against the intercepted messages until he
found the right one.
There is also the problem that communicants generally need to send
more than a single message, so your idea would need considerable
elaboration to be practical.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Thu, 9 Dec 1999 02:05:44 GMT
karl malbrain wrote:
> Again, that's the exact same SUBJECTIVE point. It's just a round-about way
> of OBJECTIVELY DEMANDING more money go to bomber manufacturers. The first
> `bombers' in WORLD WAR I were just STANDARD bi-planes. Karl M
Yeah, well this isn't the World War I era.
Basically, Proxmire misled you guys, and you should be mad at him,
not trying to make up excuses.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Thu, 9 Dec 1999 02:09:22 GMT
"Trevor Jackson, III" wrote:
> Guy Macon wrote:
> > [EMAIL PROTECTED] (Tony T. Warnock) wrote:
> > >The most probable waiting time between decays is zero.
> > No it isn't.
> How do you fogiure otherwise? Given an exponential decay expectation
> the maxima will be at zero.
And the probability that the interval is precisely 0
is precisely 0. You ought to talk about the density instead.
Although this all seems irrelevant to the original topic.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Shamir announces 1 sec break of GSM A5/1
Date: Thu, 09 Dec 1999 12:05:19 -0500
JTong1995 wrote:
>
> Cell Phone Crypto Penetrated
> by Declan McCullagh
> ...
> Although the paper describes how the GSM scrambling algorithm can be
> deciphered if a call is intercepted, plucking a transmission from the air
> is not yet practical for individuals to do.
> James Moran, the fraud and security director of the GSM Association in
> Dublin, says that "nowhere in the world has it been demonstrated --an
> ability to intercept a call on the GSM network. That's a fact.... To our
> knowledge there's no hardware capable of intercepting."
That sounds like a lie.
Consider what a cell phone base station does. It's a collection
of radio receivers that receive the phone transmissions. How is
that different from "intercepting"? If a base station can receive
the signal, so can anyone else nearby.
Yes, it's a little harder than just turning on your Radio Shack
scanner. But NOT a lot harder. A couple hundred dollars of DSP
hardware and a bit of programming will do the job.
> The GSM Association, an industry group, <AHREF="HTTP: annual_page25.html?
> about www.gsm.orgtouts the standards as "designed to conform to the most
> stringent standards of security possible from the outset [and] unchallenged
> as the world's most secure public digital wireless system."
Ha...
paul
------------------------------
** 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
******************************
