Cryptography-Digest Digest #994, Volume #8 Fri, 29 Jan 99 03:13:03 EST
Contents:
Re: Some more technical info on Pentium III serial number
Re: Spread Spectrum ([EMAIL PROTECTED])
what do u think about this algorithm of mine? (Klaus Rohde)
Re: Sanity check on authentication protocol ("lyal collins")
Re: Spread Spectrum (wtshaw)
Re: Press release - The Crypto Controversy: no problem (test)
Re: Foiling 56-bit export limitations: example with 70-bit DES (wtshaw)
Re: hardRandNumbGen (Kurt Wismer)
Re: Random numbers generator and Pentium III (Kurt Wismer)
Re: Some more technical info on Pentium III serial number (John Nagle)
Re: Some more technical info on Pentium III serial number (John Nagle)
Re: Who will win in AES contest ?? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Some more technical info on Pentium III serial number
Date: 29 Jan 99 03:12:32 GMT
Gareth Williams ([EMAIL PROTECTED]) wrote:
: 5) The actual Pentium ID is not very safe, and it must be possible to
: run the agent in
: an emulator (as someone else pointed out) and spoof it.
Um, that would be true in general. But since this agent software was
written by the *chip manufacturer*, it could make use of _undocumented_
instructions. (Which would also help to make it harder to disassemble -
the _real_ threat, "black art" notwithstanding.)
John Savard
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Spread Spectrum
Date: Fri, 29 Jan 1999 04:54:11 GMT
On Fri, 29 Jan 1999 03:00:39 GMT, [EMAIL PROTECTED] wrote:
Uh, let me rephrase the question as I was a tad vague.
Is there any way to put numbers on the following:
If it is possible to convert a DS SS audio signal back to its original
form where a chipping rate of 64 is used, then what kind of machine
might this take and in what time period, and with what software?
Real time using a Commodore 64 and Fast Fourier Analysis?
A thousand centuries using a Cray YMP-C?
CDMA is not an issue here- I was mistaken in believing someone who
said cellular CDMA is FH when it is DS. And, this is not about
cellular at all, it is about intercepting SS surveillance
transmitters.
Again, thanks for any response.
------------------------------
From: [EMAIL PROTECTED] (Klaus Rohde)
Subject: what do u think about this algorithm of mine?
Date: Fri, 29 Jan 1999 16:11:37 +1100
i don't know anything about encryption, but one day i was thinking about
it and had an idea for an algorithm which, as far as i can see, is
unbreakable.
you take byte n of a text stream and XOR it with byte n of the key to
produce byte n of the cipher text.
to me this seem's unbreakable, because by applying the right key any
cipher text can be decoded into literally anything of the same length,
meaning that unless someone has the key, they can't gain anything out of
the cipher text.
any thoughts or ideas (or proof that what im saying is nonsense) would be cool.
:-) peter
------------------------------
From: "lyal collins" <[EMAIL PROTECTED]>
Subject: Re: Sanity check on authentication protocol
Date: Fri, 29 Jan 1999 17:11:00 +1100
Replay is easy to detect.
Sahred ecret key is hashed with a counter to form a message key. Encrypted
message and counter value are sent to the recipient.
Recipient tracks received counter values for replay.
Following the same hashing processs as the sender allows the message to be
decoded.
Several patents cover this basic principle, to my knowledge.
Lyal
>Edward Keyes wrote:
>>
>> I'm trying to do a nice secure mutual authentication and session key
>> exchange using only symmetric ciphers (since public key algorithms are
>> too computationally intensive for the platform). Could someone please
>> tell me if I'm missing anything obvious in the following protocol?
>> It is assumed that Alice and Bob share a secret key prior to this.
>
>Since Alice and Bob share a secret, don't you get authentication
>for free? That is, Alice encrypts a message with the secret and
>sends it to Bob. Bob now knows that the message came from Alice
>since she's the only one who could have encrypted it (this
>assumes that Bob can recognize a "valid message").
>
>> As far as I can tell, this is secure against packet sniffers,
>> man-in-the-middle attacks, and replay attacks.
>
>S'pose you need to do something about replay attacks, though.
>
>--
>Eric Norman
>
> "Congress shall make no law restricting the size of integers
> that may be multiplied together, or the number of times that
> an integer may be multiplied by itself, or the modulus by
> which an integer may be reduced".
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Spread Spectrum
Date: Thu, 28 Jan 1999 23:33:52 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> On Thu, 28 Jan 1999 15:31:24 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
>
> >In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> >
> >> Title is The Bug Book and publisher is
> >> Paladin Press in Boulder Colorado.
> >>
> >That sounds like an old title, in fact I believe that I have volumes 1, 2,
> >and 3, and it is about some early integrated circuits, not exactly what
> >you have in mind. It might be a good idea to check title archives or you
> >may be adding to someone's confusion.
>
> New edition of old book, but there never was more than one 'volume'.
> Just the original title.
Maybe I'm confusing it with something else, but this seems too familiar.
> >
> >About Spread Spectrum, it's a big subject...good luck.
>
> Yeah, and it appears that no one is able to provide the answers to the
> question about intercepting and converting DS back into speech...
Someone did give a URL. It all depends if you want the original speech
characteristics or will settle for something like good synthesized
speech. Taking digital to analog takes some smoothing integrator circuits
to knock the corners of of the stepped waves, so to speak. The oldest and
simplest way is with a series of parallel filters with darlington stages
to allow good recovery from the LC circuits.
> >--
> >A much too common philosophy:
> >It's no fun to have power....unless you can abuse it.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED] (test)
Crossposted-To: alt.security.pgp,mics.legal.computing,talk.politics.crypto
Subject: Re: Press release - The Crypto Controversy: no problem
Date: 29 Jan 1999 06:52:53 GMT
I guess that the only consolation for the authorities is that traffic analysis
can still be used. I would imagine that under certain circumstances, traffic
analysis can yield pretty useful information.
Mark Currie
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>The Crypto Controversy: no problem
>---------------------------
>
>Tilburg, the Netherlands, 26 January 1999
>
>The Dutch government should do nothing about the problem that
>cryptography poses to law enforcement. All available options have more
>negative than positive consequences. This is the conclusion of
>Bert-Jaap Koops in his recently published Ph.D. thesis "The Crypto
>Controversy". Although encoding programs potentially leave
>law-enforcement powerless to wiretap communications and to conduct
>computer searches, there is not a real solution to retrieve the keys
>to decipher encoded data.
>
>Koops, author of the Crypto Law Survey website, conducted a four-year
>research at Tilburg University and Eindhoven University of
>Technology. He analyzed the conflict of interests that cryptography
>poses to society. On the one hand, encryption is crucial for
>information security and for protecting privacy, but on the other
>hand, it enables criminals to escape the scrutiny of law enforcement.
>Governments are trying hard to address this conflict of interests,
>but their proposals for regulation have been controversial. The
>policy debate is polarized, with privacy activists and
>law-enforcement agencies fiercely opposing each other's point of
>view.
>
>To address this crypto controversy, Koops discusses four possible
>solutions: building-in Law-Enforcement Access to Keys (LEAK systems),
>demanding suspects to decrypt, using alternative investigation
>measures, and doing nothing. The first option is flawed, because
>secure LEAK systems are not yet available, and criminals will anyway
>not use crypto which they know to contain a backdoor for the police.
>The second option, demanding suspects to decrypt, yields only very
>limited opportunities, because of the privilege against
>self-incrimination. Alternative investigation measures, such as using
>directional microphones and intercepting radiation from computer
>screens, can provide some leeway for the police if wiretaps lose
>their efficacy, but they are serious infringements of people's
>privacy.
>
>Koops concludes that, for the time being, the "zero option"
>is preferable: governments should decide upon a policy to do nothing
>about the crypto problem. To meet developments in crime and
>cryptography, this policy should be reviewed periodically. "Perhaps
>the government will slowly have to adapt to the idea that wiretapping
>is not a panacea for the information need of the police."
>
>As Koops suggests: "if there is no solution, there is no problem
>either." Rather than continue to worry over the crypto controversy,
>the government should concentrate its energy and resources on other
>pressing social issues which it can address.
>
>--------------------------
>Publication details
>--------------------------
>Bert-Jaap Koops, The Crypto Controversy. A Key Conflict in the
>Information Society. The Hague / London / Boston, Kluwer Law
>International, 1999, 301 pages, ISBN 90 411 1143 3.
>
>A summary and ordering information are available at
>http://cwis.kub.nl/~frw/people/koops/thesis/thesis.htm
>
>-------------------------
>Curriculum vitae
>-------------------------
>
>Bert-Jaap Koops (1967) studied mathematics and
>literature at Groningen University. After working for Amnesty
>International for two years, he started a Ph.D. research at Tilburg
>University and Eindhoven University of Technology at the faculties of
>law, mathematics and technology management. Since October 1998, he is
>a senior research fellow at the Centre for Law, Public Administration
>and Informatization of Tilburg University.
>
>Koops is editor of the Dutch reference book Recht &
>informatietechnologie. Hij co-edited a book on Emerging Electronic
>Highways and has published widely on crypto regulation, computer
>crime, and Trusted Third Parties. He maintains an extensive worldwide
>survey of crypto laws on the Internet.
>-----------------------------
>
>Bert-Jaap Koops <[EMAIL PROTECTED]>
>Tilburg University
>13 January 1999
>
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Foiling 56-bit export limitations: example with 70-bit DES
Date: Thu, 28 Jan 1999 23:39:25 -0600
In article <78qr6s$4mj$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (wtshaw) wrote:
> > In article <78mv0l$oih$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> wrote:
> >
>
> > > It is a mistake in the literature to consider DES unicity to be 20
bytes (3
> > > blocks of DES) for compressed English. The formula is simply not valid in
> > > that range as proved in the paper.
> > >
> > You need not be hamstrung with simple ASCII as the source for your bits,
> > as you could generate them from something else than base 128, which is
> > about the poorest one to encrypt text directly from that there is.
> > -
>
> But, for DES, unicity can never be larger than 8 bytes -- one DES block --
> unless you use absolutely random bits, which would then be absolutely useless
> to send anything different than noise ...
>
You are still thinking in one linear dimension. It is the
multidimensional technique that I suggest that produces single blocks that
are closer to noise than to text, and this is what could force unicity to
be higher, that brute force will not result in a recognizable block with
one key alone.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED] (Kurt Wismer)
Subject: Re: hardRandNumbGen
Date: Fri, 29 Jan 1999 05:48:38 GMT
R. Knauer ([EMAIL PROTECTED]) wrote:
: Learn what crypto-grade randomness is. The concept is deceptively
: simple once you understand it. But first you have to give up all other
: definitions of randomness from other fields like statistics.
: The key to understanding is that randomness depends on the generation
: process, not the numbers themselves. The number 000...0 fails all
: sorts of statistical tests, but can be a random number if it is
: generated by a TRNG. Until you analyze the method of generation, you
: cannot know.
this is the definition i've used for years... strangely, nothing i ever
learned in statistics ever suggested i was wrong...
--
"some speak the sounds but speak in silent voices
like radio is silent though it fills the air with noises
its transmissions bring submission as ya mold to the unreal
mad boy grips the microphone wit' a fistful of steel"
------------------------------
From: [EMAIL PROTECTED] (Kurt Wismer)
Subject: Re: Random numbers generator and Pentium III
Date: Fri, 29 Jan 1999 05:57:53 GMT
R. Knauer ([EMAIL PROTECTED]) wrote:
: >Yes, there are many methods. Check out Marsaglia's DIEHARD and pLab's
: >Diaphony for the most advanced stuff. Simple autocorrelation and
: >ballance of 1's and 0's will also give you a few clues. If it can
: >pass all those tests, it's mathematically random.
: I give up. If people want to believe that crypto-grade randomness can
: be characterized by statistical tests, let them.
statistical tests can identify bias and temporal (or other) correlations,
which can be used to describe crypto-grade (as you call it) randomness
(ie. 0 bias, 0 temporal correlation, 0 [whatever else] correlation, etc)
before you discount the utility of statistical tests you should find out
about what people are mistaking for defining characteristics...
statistical tests quantify properties of random numbers, they don't test
definitions... that's the bump in the road people seem to be getting
caught on...
--
"some speak the sounds but speak in silent voices
like radio is silent though it fills the air with noises
its transmissions bring submission as ya mold to the unreal
mad boy grips the microphone wit' a fistful of steel"
------------------------------
Crossposted-To: talk.politics.crypto,comp.sys.intel
From: [EMAIL PROTECTED] (John Nagle)
Subject: Re: Some more technical info on Pentium III serial number
Date: Fri, 29 Jan 1999 07:56:28 GMT
[EMAIL PROTECTED] (John Savard) writes:
>What guarantee is there that browser makers will abide by this scheme,
>and not also give out unfiltered Pentium III IDs - or, for that
>matter, any other information, such as the ID numbers of plug-and-play
>PCI cards, someone having claimed they have serial numbers (yes, there
>are ID numbers that identify the make and model, but I fail to see the
>relevance of a _serial_ number to plug-and-play...)?
Re ISA plug and play: all the slots on the ISA bus are simply
wired in parallel, so the CPU can't distinguish cards by what
slot they're in. And there might be two cards of the same type,
so card type isn't enough. The solution chosen was to have each
ISA PnP card have a unique ID, compose of a manufacturer ID and
a serial number. Cards are discovered at boot time by sending
out a message to all cards that asks "anybody with an ID between
A and B?". Any card with an ID between A and B raises a signal on the
bus. The CPU can then tell if there's at least one.
A sequence of binary searches finds each unique number.
This was an afterthought; ISA was never designed for this.
Ethernet boards have a similar arrangement, for much the
same reason; you need some way to distinguish all the nodes on
the cable, which is a broadcast medium.
PCI, though, has a select line for each card, as I recall, so
it doesn't need ID numbers for discovery.
John Nagle
------------------------------
Crossposted-To: talk.politics.crypto,comp.sys.intel
From: [EMAIL PROTECTED] (John Nagle)
Subject: Re: Some more technical info on Pentium III serial number
Date: Fri, 29 Jan 1999 08:03:27 GMT
[EMAIL PROTECTED] (Brad Templeton) writes:
>I don't get it. How does a web server "request" the ID of a client?
>A web server can't make any requests of a client. The client makes
>requests of the server. The server can send back things like Redirects
>and Authentication responses that make the client do more, but there
>is nothing in any web browser or the HTTP protocol to send these
>serial numbers or play the games described.
>Has Intel been proposing extensions to HTTP or other protocols?
>Where are those extensions documented?
>Has any browser vendor or the W3C given even the slightest indication
>they would support such extensions?
Now that's the right question. How were remote sites supposed
to get this info? Or is Intel assuming that browsers will be
designed to be "advertiser-friendly"? If browsers are going to
spy on their users, there's far more interesting stuff they can
access than the CPU serial number.
John Nagle
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Who will win in AES contest ??
Date: Fri, 29 Jan 1999 07:25:53 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Hamilton) wrote:
> (snip)
>
Earlier in this thread, you said:
> Don't use David A. Scott's software. There is evidence that it is almost
> certainly weaker than, eg, PGP. See message-ID:
> <[EMAIL PROTECTED]> in the thread 'Re: Encryption Basics'
> posted in sci.crypt on 19th December for details.
>
> David Hamilton. Only I give the right to read what I write and PGP allows me
>
I should know better than to anwser your posts since you are a sick
man. But since you claimed to have proof I tried to look up using
Deja News the article you quoted. At least when I click on the blue
part it goes to an error message. Oh well so much for your so called
proof.
Actually if one uses PGP where one uses the PGP to encypt a message
in its normal mode. It first encrypts a random (so called random)
session key and then uses that key to do standard encryption of the
plain text file which is usually first compressed. But what is not
highly advertised is this is a "zero entropy" encryption method
meaning that if one tries to break it by what ever means. If you
have a test session key then you know exactly if you can decode
the message. Security relies only on the hopes that the reverse
solution of the attacker is slow. If one uses a "high entrop"
"all or nothing encryption" like scott19u the seeds of the solution
are not there. In other words even if you have a quantam or quark
computer and reach a solution. The odds are that it is a wrong
solution. These concepts are to hard for Mr Hamilton let him
stick to the "zero entropy" methods the fool has no understanding
of this basic concept.
David A. Scott
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** 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
******************************
