Cryptography-Digest Digest #719, Volume #10 Fri, 10 Dec 99 17:13:01 EST
Contents:
Re: Ellison/Schneier article on Risks of PKI (DJohn37050)
Re: If you're in Australia, the government has the ability to modify your files.
>> 4.Dec.1999 (James Redfern)
Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir (Keith A Monahan)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (wtshaw)
Re: NSA future role? (wtshaw)
Re: NSA future role? (wtshaw)
Re: symmetric encryption based on integer factoring ([EMAIL PROTECTED])
Re: High Speed (1GBit/s) 3DES Processor (Michael Paoli)
Re: Random Noise Encryption Buffs (Look Here) ("Tony T. Warnock")
Re: low exponent in Diffie-hellman? (jerome)
Re: symmetric encryption based on integer factoring (Tom St Denis)
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
Re: Random Noise Encryption Buffs (Look Here) ("Tony T. Warnock")
Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir ("H.
Ellenberger")
Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir ("H.
Ellenberger")
Re: High Speed (1GBit/s) 3DES Processor (Paul Koning)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Ellison/Schneier article on Risks of PKI
Date: 10 Dec 1999 19:10:55 GMT
I think this is a very nice paper that asks some fundamental questions.
For those interested in more info, Peter Landrock of Cryptomathic in Denmark
has also asked some similar questions about the PKI.
Don Johnson
------------------------------
From: James Redfern <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Fri, 10 Dec 1999 18:48:37 +0000
Reply-To: redfern<AT>privacyx<DOT>com
On Tue, 07 Dec 1999 20:08:06 GMT, amadeus @DELETE_THIS.netcomuk.co.uk (Jim
Dunnett) wrote:
| >"These are really untested waters," says Chris Connolly, a vocal Australian
| >privacy advocate. "I don't think there's any example anywhere else in the world
| >that's comparable."
|
| He's a bit out of touch. It's been proposed in 'democratic' Britain, but
| not yet been put into law.
The ELECTRONIC COMMERCE bill passed its first reading 30/11/99 without much
effort. Read it?
You might want to take a look at the DTI web site under something they
euphemistically call "PROMOTING ELECTRONIC COMMERCE":
http://www.dti.gov.uk/cii/elec/ecbill_1.html#Contents
If that doesn't put you off then try:
http://www.fipr.org/ecomm99/part1.html
JR.
-- James Redfern <[EMAIL PROTECTED]> The Redfern Organization
[PGP Key ID:0x8244C43A available from <[EMAIL PROTECTED]> Subject: "get
0x8244C43A"]
...ActiveNames delivers my undeliverable mail at www.ActiveNames.com
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Crossposted-To: alt.privacy
Subject: Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir
Date: 10 Dec 1999 19:19:36 GMT
Douglas,
Your post wasn't incredibly clear and I'd like to fix it up.
Douglas Hinton ([EMAIL PROTECTED]) wrote:
: Intercepting a cell phone conversation isn`t hard.
Intercepting an ANALOG cell phone call isn't hard.
If the scanner was manufactured before the current 'privacy' laws, no
modification is required to listen to the frequency range. I'm speaking
of current US laws(not .dk) and frequencies.
If the scanner was manufactured AFTER, then a small modification, usually
removing a diode perhaps a few resisters, is required to 'open' the radio
to receive those types of calls.
: You need only a
: scanner radio and a Ham Com interface. The scanner radio needs a simple
: modification to by pass the audio circuit.The signal can be put directly
: into a computer and processed.
Yes, performing what's known as a descriminator modification or tap, allows
you to get access to the 'raw' signal received.
: I have intercepted digital signals(not
: cell phone), made .wav files of them , converted the files to binary
: numbers.
If you are referring to POCSAG or FLEX paging or perhaps MDT, thats one thing.
Decoding the paging protocols is simple and there exists software out there
to do just that. POC32 comes to mind.
However, digital VOICE conversations is another story. I haven't seen a
program yet that will take the output from a descrim. tap, decode it, and
then output the voice via your sound system. I keep my ear to the ground
and haven't seen anything like that. By all means, let us know if you
have seen this and provide us a download reference! :)
Furthermore, you're assuming the digital voice is in PLAINTEXT. If it's
encrypted this adds to the complexity of the problem. It doesn't make
it IMPOSSIBLE but it makes the task HARD, assuming cryptanalysis on the
used algorithm yields an easy break. And easy in the crypto world could
mean a month's processing 1 second of encrypted voice.
So, intercepting (possibly encrypted) DIGITAL cell phone calls IS HARD.
Only problem I see with cell phone interception is that they use
: a trunking system. That is that the signal is handed off from one base
: station to another or channels are switched.
This is definitely a problem that makes our task hard too. Keep in mind,
this software would have be running concurrently with our digital decode
AND the 'decrypt' function, too.
Even a standard scanner
: radio can follow most of the hand-offs if the base station frequencies
: are programed in.
The only 'standard' scanner I can think of that will track the progress
of a call is perhaps a Trunk Tracking scanner. But these scanners are
made specifically to watch the data channel coming from Erikson, or
Motorola, or etc trunked systems. These will definitely not function
with the cellular systems that are in place with the US.
Per the original message (and your reply), we're talking about CELLULAR
calls here, not CORDLESS calls. There is a big difference between the
two, but even digital CORDLESS calls are not EASY.
: Douglas
Keith
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Fri, 10 Dec 1999 13:28:44 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> "Trevor Jackson, III" wrote:
> > I thought so too. Then I reied to install the latest Microsoft(tm) tools.
> > Visual C now refuses to install unless Internet Explorer is present. I am
> > unable to conceive of a legitimate reason for such "persuasive" market
> > positioning.
>
> That is simply the result of Visual Studio's help system having
> been changed to HTML rather than Microsoft's old proprietary
> format. Looks like progress to me.
An html format pushed a reliance on the browser, *text* being better.
Reminders: html is not friendly to casual use of what it considers control
characters, while text is. For a full descussion of character sets and
programming, html is a backward's move....a dumbing down.
--
When the horse dies, get off.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: NSA future role?
Date: Fri, 10 Dec 1999 13:40:11 -0600
In article <[EMAIL PROTECTED]>, CLSV <[EMAIL PROTECTED]> wrote:
>
> Using large (number of) S-boxes is a nice idea. OTOH providing good
> key-scheduling will be harder than it is for small key sizes I think.
This depends on the algoritm; "You've got to think high to rise."
> ...
>
> Maybe, but given the flourishing field of academic and commercial
> cryptography I don't think they have the same options as they
> had in the 1980's. I don't think they even could offer all the
> security knowledge that is needed in business today. The demand
> for new kinds of protocols and applications is just exploding.
> So they either have a choice of retreating to their core business,
> just national security, or providing additional services for large
> customers at risk of spreading specific knowledge.
>
Like Microsoft, maybe they need to specialize so that different agencies
concentrate on different missions, rather that making has become the tail,
or a port short of it, wag the dog. Come to think of it, NIST already has
such a role; not that NSA does not try to ride herd on it.
--
When the horse dies, get off.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.politics.org.nsa
Subject: Re: NSA future role?
Date: Fri, 10 Dec 1999 13:53:20 -0600
In article <[EMAIL PROTECTED]>, Jim Dunnett wrote:
> On Thu, 09 Dec 1999 04:21:31 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
> wrote:
>
> > Well it's true no terroist group is likel to put a clean effiecent nuclear
> >device together with out lots of expertise or money to the correct US
> >politican. Any terroist group with money and enriched uranium could
> >build a simple dirty nuclear bomb that could do a lot of damage. It
> >raelly ain't that much to them.
>
> Do you really think they'd have the technology and funds to be able
> to handle plutonium without killing themselves in the process?
>
> Assuming that they can get hold of enough plutonium to make a bang.
Facilities that involve remote handling are availabe for many purposes,
which can be used.
Most speak in money; some even disregard the necessity to do otherwise in
this country, while using it to try to justify anything they do. Money is
not always the most creative solutionp; and, watching the money trail may
cause you to miss something.
--
When the horse dies, get off.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: symmetric encryption based on integer factoring
Date: Fri, 10 Dec 1999 19:16:59 GMT
In article <82rdhk$7ae$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <82qv02$rkl$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > This looks very much like El-Gamal except to decrypt a message you
use
> > division, not an inverse of g^x. Essentially, you have a Discrete
> > Logarithm Problem and you're implementing decryption in a different
> > manner. However, it may become an interesting alternative for
public
> > key encryption since it appears you don't have to send as much
> > information as you do when using El-Gamal. Did you figure out a way
> to
> > create g^-x?
>
> Well ElGamma is a public key scheme, this is just a math-toy symmetric
> scheme. Also g^-x is the same as G^x where G = 1/g mod p.
Ahh, cool. Damn all that math I forgot. It's going to be too damn slow
for bulk encryption unless you use it as a small part of a symmetric
cipher, much like the invertible multiplications are used in IDEA. It
certainly seems to be a bit simpler to work with.
Hmm, here's a rough idea floating off the top of my head. Make g, x,
and p dependant on the key. Now, perform your little encryption scheme
in place of whitening in a cipher. What I mean is, the first and last
steps in this new algorithm would be mathematical encryption. Now, some
things to remember: p will have to be chosen to ensure that the
resulting value remains within the range 0-(2^128)-1, assuming a 128 bit
block cipher. Granted this will be a relatively slow cipher, but in
combination with a few rounds of "regular" block encryption, this may be
very secure. It would be interesting to see what effect this would have
on differential/linear cryptanalysis.
Anyway, it's just something that rolled off the top of my head. Later.
csybrandy
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Michael Paoli)
Subject: Re: High Speed (1GBit/s) 3DES Processor
Date: 10 Dec 1999 11:38:10 -0800
Wouldn't that be 3DES at the same speed, but 3 times the latency?
In article <[EMAIL PROTECTED]>,
Christof Paar <[EMAIL PROTECTED]> wrote:
>Just to give a data point for a non-FPGA, i.e., classic ASIC,
>implementation:
>Folks from Sandia Labs presented a 16-stage pipeline DES design in current
>ASIC technology which encrypts at around 10 Gbit/sec at CHES '99. The
>exact reference is at:
> http://ece.wpi.edu/Research/crypt/ches/ches99/index.html
>3DES should be 1/3 of that speeed.
[Note: Newsgroups trimmed]
--
[EMAIL PROTECTED]
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Fri, 10 Dec 1999 13:36:59 -0700
Reply-To: [EMAIL PROTECTED]
I'd like to re-phrase things to be a little clearer (and perhaps also
correct.)
Using a radioactive source for random number generation: the number of
atoms will have to be large, around 10**20 atoms or so; finite size
effects will be minimal (really small.) The probability of a decay
happening in an interval is proportional to the length of the interval.
This yields a Poisson distribution of counts in an interval and an
exponential waiting time between counts. The difficulty comes with
detecting the decays. A detector will be in a different state right
after detecting a decay than it will when idle for a while. One can
ignore the time right after a detected hit then start waiting; the
starting time of the interval is not important, only the length. One
also has to take into account what happens when the detector receives a
decay while waiting; the wait has to start over.
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: low exponent in Diffie-hellman?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 10 Dec 1999 20:41:12 GMT
On Fri, 10 Dec 1999 17:37:08 GMT, Scott Fluhrer wrote:
>>Which one exactly are you speaking about ?
>>If i understand them correctly, the 14.6.1 ones are all variations
>>of the 'square & multiply'. I haven't look at 14.6.2(fixed exponent)
>>and 14.6.3(fixed base) sections, are they 30% faster ?
>>
>I was thinking of 14.6.3, specifically. The obvious square & multiply
>takes 1.5*lg(N) expected multiplies (where N is the exponent) while
>14.6.3 is closer to 1.1*lg(N) expected for the range of N's we're
>talking about.
>
>Ok, maybe 30% is a little over-optimistic. 25% is realistic.
interresting but unfortunatly i can't use them. My application has indeed
a fixed g and p (with g^x mod p). But i do a diffie-hellman key exchange
with it:
- The offer (g^x mod p) can be precomputed and used several times
so it's cost is amortized.
- The reply (m^x mod p with m=g^y mod p) is harder, it can't be
precomputed or reused.
To optimize my computation, i have to optimize the second case.
I will look at the fixed exponent algorithms to see how efficient
they are in my case.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: symmetric encryption based on integer factoring
Date: Fri, 10 Dec 1999 21:03:13 GMT
In article <82rjj8$bg0$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hmm, here's a rough idea floating off the top of my head. Make g, x,
> and p dependant on the key. Now, perform your little encryption
scheme
> in place of whitening in a cipher. What I mean is, the first and last
> steps in this new algorithm would be mathematical encryption. Now,
some
> things to remember: p will have to be chosen to ensure that the
> resulting value remains within the range 0-(2^128)-1, assuming a 128
bit
> block cipher. Granted this will be a relatively slow cipher, but in
> combination with a few rounds of "regular" block encryption, this may
be
> very secure. It would be interesting to see what effect this would
have
> on differential/linear cryptanalysis.
>
> Anyway, it's just something that rolled off the top of my head.
Later.
Well the whole point behind the exponentiation is to avoid giving out
the key [or one of the keys]. I could just as easily do xa mod p,
using a random 'a' for each message. If the plaintext were known then
so would 'a'.
This technique has been used in ciphers already, it's called
decorrelation. Normally in the form ax + b mod p [I hope that's
right]. It turns out to be effective for making linear and
differential attacks, however it's not perfect. COCONUI'98 was
attacked using the boomerang attack [again I hope, all I know is that
it was Wagner] because the Decorrelation module was used scarcely.
DFC uses one module per round though :)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 10 Dec 1999 16:28:06 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Tony T. Warnock wrote:
> I'd like to re-phrase things to be a little clearer (and perhaps also
> correct.)
>
> Using a radioactive source for random number generation: the number of
> atoms will have to be large, around 10**20 atoms or so; finite size
> effects will be minimal (really small.) The probability of a decay
> happening in an interval is proportional to the length of the interval.
> This yields a Poisson distribution of counts in an interval and an
> exponential waiting time between counts. The difficulty comes with
> detecting the decays. A detector will be in a different state right
> after detecting a decay than it will when idle for a while. One can
> ignore the time right after a detected hit then start waiting; the
> starting time of the interval is not important, only the length. One
> also has to take into account what happens when the detector receives a
> decay while waiting; the wait has to start over.
I don't know why, but this message triggered a small Aha! as I read it. It
may be possible to construct a device that produces quantum derived
radiation at a constant rate -- no exponential decay. I'm certain we don't
have the technology to build such a device today, but if modern crypto is
as old as practical computers, we may be able to build one in the next
period of similar length.
Consider the final phase of an object emitting Hawking radiation. The
final blast of radiation transforms all of the rest mass of the device into
radiation. What's left over? A singularity. Postulate such a singularity
captured and mixed with a gas (say hydrogen). At intervals comtrolled by
the gas density the singularity will interact with (eat) an atom, and
immediately re-emit the energy as thermal radiation. By maintaining a
constant pressure in the enclosing vessel one might produce a mean emission
rate that was constant.
I suppose we don't know enough about the coefficients of interaction of
such a singularity to determine the feasibility of the technique. But the
idea of putting such an object to practical use is appealing.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Fri, 10 Dec 1999 14:37:17 -0700
Reply-To: [EMAIL PROTECTED]
"Trevor Jackson, III" wrote:
> Tony T. Warnock wrote:
>
> > I'd like to re-phrase things to be a little clearer (and perhaps also
> > correct.)
> >
> > Using a radioactive source for random number generation: the number of
> > atoms will have to be large, around 10**20 atoms or so; finite size
> > effects will be minimal (really small.) The probability of a decay
> > happening in an interval is proportional to the length of the interval.
> > This yields a Poisson distribution of counts in an interval and an
> > exponential waiting time between counts. The difficulty comes with
> > detecting the decays. A detector will be in a different state right
> > after detecting a decay than it will when idle for a while. One can
> > ignore the time right after a detected hit then start waiting; the
> > starting time of the interval is not important, only the length. One
> > also has to take into account what happens when the detector receives a
> > decay while waiting; the wait has to start over.
>
> I don't know why, but this message triggered a small Aha! as I read it. It
> may be possible to construct a device that produces quantum derived
> radiation at a constant rate -- no exponential decay. I'm certain we don't
> have the technology to build such a device today, but if modern crypto is
> as old as practical computers, we may be able to build one in the next
> period of similar length.
>
> Consider the final phase of an object emitting Hawking radiation. The
> final blast of radiation transforms all of the rest mass of the device into
> radiation. What's left over? A singularity. Postulate such a singularity
> captured and mixed with a gas (say hydrogen). At intervals comtrolled by
> the gas density the singularity will interact with (eat) an atom, and
> immediately re-emit the energy as thermal radiation. By maintaining a
> constant pressure in the enclosing vessel one might produce a mean emission
> rate that was constant.
>
> I suppose we don't know enough about the coefficients of interaction of
> such a singularity to determine the feasibility of the technique. But the
> idea of putting such an object to practical use is appealing.
Wouldn't there still be Brownian motion type fluxuations?
------------------------------
From: "H. Ellenberger" <[EMAIL PROTECTED]>
Subject: Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir
Date: Fri, 10 Dec 1999 22:50:57 +0100
Douglas Hinton wrote:
> Intercepting a cell phone conversation isn`t hard. You need only a
> scanner radio and a Ham Com interface.
What about using a modified GSM phone for reception?
------------------------------
From: "H. Ellenberger" <[EMAIL PROTECTED]>
Subject: Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir
Date: Fri, 10 Dec 1999 22:57:47 +0100
Douglas Hinton wrote:
> Intercepting a cell phone conversation isn`t hard. You need only a
> scanner radio and a Ham Com interface.
What about using a modified GSM phone for reception?
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: comp.dcom.vpn,comp.security.firewalls
Subject: Re: High Speed (1GBit/s) 3DES Processor
Date: Fri, 10 Dec 1999 16:07:03 -0500
Helger Lipmaa wrote:
>
> Paul Koning wrote:
> ...
> > 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.
> ...
> Parallel implementations can be used in counter mode and CBC decryption,
> however - I personally don't feel that easy about interleaved CBC.
Why do you feel uneasy about interleaved CBC? If I take a packet and
split it up into four packets by taking bytes 0,4... for the first,
1,5...
for the second, and so on, then encrypt these four using standard CBC,
should I expect any problem? I can't see how given an underlying
assumption
that CBC mode of the cipher in question is secure against chosen
plaintext attack. But that encryption is exactly the same as you
get if you encrypt the original packet with 4-way interleaved CBC.
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
******************************
