Cryptography-Digest Digest #986, Volume #8 Thu, 28 Jan 99 06:13:04 EST
Contents:
Re: Unicity, DES Unicity and Open-Keys (wtshaw)
Spread Spectrum ([EMAIL PROTECTED])
SCC cypher...the most secure encryption method (JPeschel)
Believe it not, two more dumb ciphers (wtshaw)
Re: Comments on Pentium-III (Nogami)
Re: Pentium III... (handWave)
Re: Comments on Pentium-III (Terje Mathisen)
Re: My comments on Intel's Processor ID Number (Vernon Schryver)
Re: Pentium III... (Daniel James)
Re: Strong Encryption for 8086 (16 bit) (Hideo Shimizu)
Re: Metaphysics Of Randomness (R. Knauer)
Re: Random numbers from a sound card? (Mok-Kong Shen)
Re: Some more technical info on Pentium III serial number (Tommy the Terrorist)
Re: Who will win in AES contest ?? ("Brian Gladman")
Re: Who will win in AES contest ?? ("Sam Simpson")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Unicity, DES Unicity and Open-Keys
Date: Wed, 27 Jan 1999 23:45:29 -0600
In article <78n51d$l76$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Patrick Juola) wrote:
> >>
> >Speaking of numbers, surely a few impressive ciphers are nice to have, but
> >overwhelming with multitudes of choices is as good a cipher technique as
> >it is a battle tactic.
>
> Not if most or all of the choices suck. As true in battle as it is
> in cryptography.
I throughly agree, an algorithm may be innately weak in itself, but rather
a useful step in something chained with it. In nearly all of these I'm
messing with currently, I include scaled options that can make a big
difference, but, I'm not doing anything to filter out bad keys either.
>
> >Besides that, there are subtile things to be learned about ciphers and
> >functionality through experience with as many different ones as possible.
> >If for any other reason, having fodder for budding attackers somewhere
> >between trivial and megalithic seems like a good idea.
>
> This I agree with. *But*, once we've found that the WizBang16 doesn't
> work and can be cracked in a few minutes/seconds, is it still a viable
> choice?
>
If you have many, but different, questionable strength algorithms, then if
there is any amount of nominal strength in most of them, you still have
quite a filtering problem, and knowing how to make lots of the same start,
means that with the array of nuts and bolts available, you are able to
make some not on anyones list.
Back to the unicity idea, if there is any means of guessing at what it is
for a given cipher, you need never reach that level in any message.
Surely, for some choices, you know that you are picking a vunerable one.
Then, there is the spread spectrum approach, using several weak ciphers,
to handle fractionated parts of the message. An attacker would not only
be looking for the keys to each cipher, but the combination of the ciphers
used.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED]
Subject: Spread Spectrum
Date: Thu, 28 Jan 1999 07:13:03 GMT
Greetings,
Would appreciate hearing from anyone who understands Spread Spectrum
technology. The following is needed for a book that goes to the
publisher in a few weeks.
What I am trying to determine is how (if?) it is possible to intercept
and convert an audio (not data) SS signal back to its original form.
I realize this will depend on a number of factors, starting with the
ability of the receiver to even intercept the signal in the first
place, and then on the rate of frequency change, or in Direct
Sequence, the chipping rate. This also assumes that the receiving
equipment is *not* the same as is used for transmission; that the
personnel making the interception don't necessarily have stats on the
transmitter. One of the variables that have to be considered in
surveillance countermeasures.
It was my understanding in the past that DS could be 'decoded' in real
time with a fast PC such as a Pentium II using Fast Fourier software,
and with Frequency Hopping (such as Qualcom's cellular CDMA)
something on the order of a Sparcs workstation and a great deal of
work. That this is not possible in real time, but closer to, perhaps,
the CPSR's key derivation of the DES; hundreds of hours.
This publication is a mostly non-technical work on RF surveillance
technology applications and countermeasures. It is written for the
'average' person who has little if any understanding of either
surveillance or electronics. Title is The Bug Book and publisher is
Paladin Press in Boulder Colorado.
Thanks in advance for any response.
M L Shannon
Lysias Press
San Francisco
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: SCC cypher...the most secure encryption method
Date: 28 Jan 1999 07:19:14 GMT
Has anyone heard of the SCC cipher?
It is being used in Encode-It, a replacement
for Turbo Encrypto that Randall Williams,
Casimir, and I (playing only a small part)
broke some time ago.
Turbo Encrypto is still at:
http://pweb.netcom.com/~skylark/index.html
Encode-It is at:
http://www.skylarkutilities.com/
The break of the former is at the address
below.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Believe it not, two more dumb ciphers
Date: Thu, 28 Jan 1999 00:42:48 -0600
Having fought a few days with numbers that did not work in the range I
needed, I took the least attractive step most of us want to take, pull out
the books....and I discovered, as I had forgotten, that I can up the
horsepower of the math functions by simply increasing them to almost any
level in the Preferences. I hope this means that I will be able to go
back and do the ones I glossed over, but I will reserve being too happy
about it until I see it all work.
The base 100Pt series thus far: Bangkok is for Base 14Ct, Ping for 16Ct,
Balsas for 18Ct, Rimfire for 22Ct, and Winters for Base 32.
Input Plaintext in base 100, rearrange the digits, and come out in a
substituted base, much the same for Sappa, which does base 40 Ct. Sappa
is a river near the border of Kansas and Nebraska, 100 W 40N. The
transpositon sizes are 8/16/24, and the substitution key is again the size
of the set, 40 characters.
Here are the default keys for Sappa 24:
Subs(Sa): abcdefghij klmnopqrst uvwxyz/123 456789.,?=
Trans(Sa): abcdefgh ijklmnop qrstuvwx
If you take something of an appropriate length, like this sentence, you
can get a set of keys like:
Subs(Sa): oi?x,7are6 ytf8mpukzj bvc124/35q d9gshwl.n=
Trans(Sa): mjldtikr senufobg xwqvcaph
A maximum of 64 characters is used in the generaton process, but a cheap
set can be made from a shorter string.
It is easy to think of these ciphers as just some more using simple
substitution and simple transposition, but that is in error since changing
bases is involved, mixing three crypto building blocks. It would be easy
to use a handful of bases, doing substitution and transpostion in each
one, making something rather complicated to attack, with most non-trivial
key space involved.
Base 40 does not mix in base 100 too well; some algorithms exhibit a
rather strong changing of values throughout a single group with the
changing of one letter anywhere. Still, I like base 40 because it is
rather easy for pencil and paper methods, without the substitution key,
just using simple transposition, it was also the first one I reasoned out,
which was just by chance, not hinting at the mess involved with some of
the others.
It becomes more obvious that making each ciphertext set a subsets of
larger ciphertext sets is desirable. And, the set used in ciphertext may
vary from the one when plaintext is handled in that base in other ciphers.
Tuttle is some town in North Dakota near 100W 47N. So, it means that the
cipher Tuttle 10/20 works with bases 100 and 47. Tuttle 20 default keys,
for comparison's sake, follow:
Subs(Tu): abcdefghijklmnopqrstuvwxyz/123456789.,?:;()'-=|
Trans(Tu): abcdefghijklmnopqrst
And, using the preceeding paragraph as keystring and plaintext, you get
this sort of nonsense:
5gvts qq:|v )ac(j qx:.m ;h2)o yyc49 9tly: 9(9r. xz7id /zo36 qbo66 mmk3c
c)gx: zxbzo |o=ye 87n9? q:5=: 2l'pj 75wcr a5gvt y6|rp 5c8oy ,'g5x :dvbc
(2a8m knauo p73o' 87p-n s66ja 5gzwa .6x/x 5,ezq umz8) h7qv4 6l't8 17/t7
(gl8z vx:x= 6'7,k lb/e1 )v34' p.//s cp,(f ,
Subs(Tu): 6:78ofk34wpg9x;rlsty1.jeanz,buhc2)('-v=5/|m?qid
Trans(Tu): jmneaopfcbhkgdlqtrsi
And...so it goes....
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED] (Nogami)
Subject: Re: Comments on Pentium-III
Date: Thu, 28 Jan 1999 07:32:48 GMT
On 27 Jan 1999 21:56:15 GMT, [EMAIL PROTECTED] (Bob Manson) wrote:
>It has the additional "benefit" if the user upgrades their
>CPU/motherboard, at the very least they need to reregister the
>software, and perhaps even buy a new license. It's easy to imagine
>certain greedy software companies licensing the software to a
>particular CPU. ("You must submit proof that the original CPU was
>destroyed within 30 days...") Sheesh. "Please, sir, I beg your kindest
>permission to use this software that I paid for?"
It's worth noting that Microsoft has already decided to go this route
for Office 2000 (and possibly Windows 2000?). The software installer
creates a pre-install code when you want to start the software setup,
based on the general configuration of your PC.
You then phone up MS (and wait on hold the required 2 hours), or
connect to their machines over the internet to "register" with your
special code, at which point they generate the required counter-code
that allows an install of the software on your machine to proceed.
The whole purpose being of course, to stop "Joe" from lending his
install CD to his buddy "Fred". Of course, I can't imagine that it'll
take the pirate folk more than a day or so to create a their own
key-generator for this sort of thing, so in the end, it'll just
inconvenience the regular consumer.
The same thing would of course, be eminently possible with Intel's
Serialized CPUs, and would probably take about the same amount of
effort for pirates to break.
N.
------------------------------
From: handWave <[EMAIL PROTECTED]>
Subject: Re: Pentium III...
Date: Thu, 28 Jan 1999 00:43:44 -1000
fungus wrote:
>
> handWave wrote:
> >
> > In 1986 I drew the
> > "single poly EPROM cell" on the CAD system, had it processed on a test
> > wafer, tested it, and it worked. I told the marketing department about
> > it. I wrote it up in my patent notebook. I told them to use it as a
> > serial number for the 80386, for key storage and for fabrication lot
> > tracking for process analysis.
> >
>
> ...so you're personally to blame for all this!
>
> --
> <\___/>
> / O O \
> \_____/ FTB.
It's lonely at the top.
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: Comments on Pentium-III
Date: Thu, 28 Jan 1999 10:48:08 +0100
Paul Rubin wrote:
>
> In article <x6Kr2.170$[EMAIL PROTECTED]>,
> Scott A. Berg <[EMAIL PROTECTED]> wrote:
> >First, the processor serial number and the random number generator are two
> >separate and independent features. I have read several garbled press
> >reports about how the serial number itself is a random number. Of what use
> >would randomness be here?
>
> From some other news post, the serial number is a 96-bit number that
> is generated randomly when it is programmed into the chip. The consequence
> is that the chips aren't consecutively numbered or anything like that.
> If someone buys 100 chips and you get the serial numbers of some of
> them, you won't be able to guess the serial numbers of the others even
> if you know the chips all came from the same batch.
I'm almost certain that the 96-bit number would be a (more or less)
secure hash of an actual serial number, or maybe a concatenation of a
serial number and it's Intel autentication info.
Anyway, to actually read this number, the only reasonable mechanism
would be to use the CPUID opcode, since this opcode takes an input
parameter in EAX.
Doing a CPUID(0) will return a 12-byte string ("GenuineIntel") in
EBX:EDX:ECX, and a number in EAX. The EAX value is the highest legal
input to the CPUID opcode.
The very first engineering samples of the Pentium would return 0 in EAX,
but all production chips returns 1.
Doing a CPUID(1) will return a cpu feature mask in EDX, with a bit for
each processor-specific capability, i.e. stuff like having a Time Stamp
Counter.
On the PPro/PII CPUID(2) is legal, it returns info on the cache/TLB
hierarchy.
My guess is that the PIII will allow CPUID(3), and that this opcode will
return the 96-bit (12-byte) (pseudo-)random serial number in
EBX:EDX:ECX, just like the signature string.
To fake out this mechanism, you would have to locate & patch inline code
like this:
mov eax,3
cpuid
or a subroutine call like this
mov eax,3
call _cpuid
...
_cpuid proc public
cpuid
ret
_cpuid endp
The first is 5+2 = 7 bytes, the call is the same, while the function is
just 3 bytes.
The last is short enough that it is hard to patch it into a jump/call to
some added routine to fake out the reply, so a would-be cracker would
have to locate all the places this code is called from.
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: My comments on Intel's Processor ID Number
Date: 27 Jan 1999 10:57:07 -0700
In article <[EMAIL PROTECTED]>,
Bruce Schneier <[EMAIL PROTECTED]> wrote:
>I wrote a column on Intel's Processor ID number for ZDNet. You can
>read it at:
>
>http://www.zdnet.com/zdnn/stories/comment/0,5859,2194863,00.html
What did you mean about "patches that randomize the ID number will be
available on hacker Web"? Could you or someone please explain a new serial
number in the chip and/or the BIOS is going to get on the wire? Exactly
what software would need patching to randomize the ID number? There is
no current, commonly used network protocol in which a host transmists its
serial number, other than things like ARP, which already broadcasts the
Ethernet MAC address. I don't know of anything in PPP that is relevant.
I guess DHCP or BOOTP might be used to send a serial number, but none of
those would tell the number to any host more distant than the typical PC
user's Internet Service Provider, and often not even the ISP. What are
the congressmen and boycotters worried about? Are Intel, Microsoft, the
U.S. Dept.of Justice about to announce a new protocol to the IETF and
require it be used on the public Internet?
It would have been nice if you had pointed out that a large fraction of
computers manufactured in the last 15 years, including those with Intel
main CPU's, have had guaranteed globally unique serial numbers and that
those serial numbers have long been put on the network, namely, the primary
Ethernet MAC address, so a new serial number can't do a lot in networks.
Every system with built-in Ethernet, FDDI, or 802.5 support has a
practically unchangable serial number. (Yes, modulo protocols like DECNET
that used locally assigned MAC addresses and your point about dishonest
software.) Then there is also the IP address. Note that lying about your
Ethernet MAC or IP address is also possible, but often causes far more
hassle than lying about a hardware serial number, which is one of the
reasons why so much node-locked software uses the MAC or IP address.
--
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Pentium III...
Date: Thu, 28 Jan 1999 10:28:54 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Darren New wrote:
> Anyway, who would be checking for whether the CPUs are stolen?
>
The point is that every CPU made will have a unique identifier that
cannot be file off, painted over or otherwise rendered illegible
without destroying the CPU. This will be useful, for example, when the
police find a A.Felon Esq. in posession of a shedful of used CPUs; it
will be possible to verify that they were stolen and from whom.
Cheers,
Daniel James
Daniel at sonadata.demon.co.uk
------------------------------
From: Hideo Shimizu <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.asm.x86
Subject: Re: Strong Encryption for 8086 (16 bit)
Date: 26 Jan 1999 01:09:06 GMT
I recommend you algorithm RC2, because all operation using RC2 is
only 16bit and RC2 assume little endian. And RC2 can use 8 - 1024bit
key length.
Hideo Shimizu
Andrew Lord wrote:
>
> [cross posted - see headers]
>
> I'm looking for a *strong* encryption algorithm the has been implemented
> in 8086 assembler to use on the Psion PDA. ( Eg TwoFish, SkipJack. )
>
> I've got "intermediate" 8086 experience, lots of C and ZERO cryptoanalysis, so
> I could struggle at porting some C code, but it would be ever so nice if
> someone has implemented and tested this for 8086 already. Or can recommend an
> algorithm that is the easiest to implement on a 16bit processor.
>
> rgds,
>
> Andy L.
>
> --
> Andy Lord
> http://w3.to/lordcentre
> mailto:[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Metaphysics Of Randomness
Date: Wed, 27 Jan 1999 14:05:23 GMT
Reply-To: [EMAIL PROTECTED]
It just occured to me after finishing Chaitin's new book, "The
Unknowable", that perhaps one reason people insist on using
statistical tests to characterize numbers as random - which we know is
incorrect for purposes of crypto - is that one can presumably
characterize certain numbers by such means, but only if they are
infinite in length.
One might be tempted to say that if a very large number is
characterized as random by statistical methods, then it is "almost"
perfectly random. But as I understand it, that is a error in
judgement. If the numbers you are using are finite, then the only way
you can decide if they are random for purposes of cryto is to
characterize the generator that produced them.
The generator tells you how an infinite number could be produced by
it, and from that you can infer that finite numbers produced by it are
crypto-grade random numbers, assuming it is a TRNG. IOW, although you
cannot actually characterize an infinite number produced by a
generator, but you can characterize finite numbers produced by it from
inspection of the generation procedure itself.
That is, you can extrapolate your knowledge of the generation
procedure to infinite number generation, and from that infer the
randomness of finite numbers produced by that procedure. But you
cannot take a large number and use it to extrapolate to infinite
number generation. The reason for that is simple.
If the finite number you are trying to characterize by statistical
tests is presumably random, then its generation is indeterminate, and
therefore there is no procedure to extrapolate its characteristics to
infinite number generation. It could very well be random but there is
no way you can decide that from statistical tests on the number
itself. If the number is indeed random, it will not yield any
information about how it was genrerated, and therefore extrapolation
to infinite number generation - where statistical tests DO apply - is
not possible.
Here is the reductio ad absurdum: If you claim that a statistical test
can extrapolate alleged random characteristics from a finite number to
infinite number generation, then there must be a procedure to do that,
in which case the extrapolation is deterministic - and therefore the
infinite number generation procedure you just used is not random, and
you cannot use it to characterize the original number as random.
A number is random because it tells you nothing about itself,
including the fact that it is random. If a number can tell you that it
is random, then it is not random. It's like the Epimenides Paradox:
"All (finite) random numbers are liars." :-)
Bob Knauer
"An honest man can feel no pleasure in the exercise of power over
his fellow citizens."
--Thomas Jefferson
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random numbers from a sound card?
Date: Wed, 27 Jan 1999 15:11:17 +0100
[EMAIL PROTECTED] wrote:
>
> Note that even using a highly structured signal (e.g., digitized
> video program including your local receiver noise) you could generate
> good bits, but you'd have to distill bushels of them.
I find your experience interesting. (In another thread I suggested
obtaining good bit sequences from such materials as natural
language texts.)
M. K. Shen
------------------------------
From: Tommy the Terrorist <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,comp.sys.intel
Subject: Re: Some more technical info on Pentium III serial number
Date: 28 Jan 1999 07:52:42 GMT
Give me a break. Isn't this a smokescreen?
The only crucial admission in here is this:
"Very early on, when Intel described it, they were very, very careful to
address certain concerns," Abbott said. The final scheme was defined
after
deep scrutiny by Intel and Rainbow, addressing problems such as
traceability on the Web, he said."
In other words, no matter how they talk about how the numbers aren't
the same on every Web server, the point is still to violate the user's
privacy ... otherwise they wouldn't need a number at all.
"Under Intel's scheme, every Web server has a unique, randomized ID
number that's transmitted along with a request to verify a PC's ID
number. At this point, a trusted agent intercepts the request and
submits it to the microprocessor."
Great! TWO for the price of ONE! Not only do they plan to issue
"unique identifiers" for computers, but also for Web pages! Gee,
doesn't that make me feel that privacy is paramount?
"But because every Web server has a different ID, the hashed number
uploaded from the PC will differ from one site to the next. No site will
know the Pentium's actual ID number, nor will any two servers use the
same hashed number to represent a particular Pentium."
No *SITE*. Exactly... but everybody in "law enforcement", such as
Jiang Zemin's political police, will have access to whatever secret
decryption key or algorithm or backdoor or whateverinhell you want
to call it that allows them to duplicate the computer's effects.
If this is not a free country, then we must boycott this product for
our own sakes, to preserve ourselves from spies and harm. And if
this IS a free country, then we have a sacred responsibility to
boycott this product so that it fails in the marketplace before it
is inflicted upon those who have no right to criticize their
governments on the Internet. And few could really argue that
our position is not intermediate, which means that both arguments
apply in full.
"The setup also prevents "spoofing" of the serial number, another
fear among privacy advocates. The agent that intercepts the ID
request is an example of "tamper-resistant software," which is
difficult to replicate or alter and manages to tap the processor ID
number without divulging the number to the outside."
Translation: this isn't key escrow, because you don't get to SEE
the key. Only the NSA has it, and the government enforcement
machine you call a "PC", hidden out of your view! This does not
protect privacy, but only serves to protect those who infringe
it from the possibility that someone might evade them.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Who will win in AES contest ??
Date: Thu, 28 Jan 1999 09:08:42 -0000
Bruce Schneier wrote in message <[EMAIL PROTECTED]>...
[snip]
>>Brian Gladman made in his presentation also the interesting
>>suggestion that the AES contest should select not a single
>>but three winners. These winners should be diverse in their
>>technology, such that a cryptoanalytic breakthrough could
>>not kill all three of them simultaneously. For instance,
>>we could have one simple easy to validate high-performance
>>winner (RC6?), one ultra-conservative winner (Serpent?), and
>>one winner that performs nicely on 8-bit embedded controllers
>>with only a few bytes of RAM and a few hundred bytes of ROM.
>
>I think that would be a disaster.
It would be useful to know whether you are saying that having three winners
would be a disaster or whether you are saying that having three winners
using these criteria would be a disaster
Brian Gladman
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Who will win in AES contest ??
Date: Thu, 28 Jan 1999 09:18:11 -0000
Rob,
Found your message entertaining (and much agrees with my thoughts about the
current stage of AES...). One small comment;
Robert Harley wrote in message ...
>None are perfect. But one comes with proof. The others don't.
There is a "proof" of DFC's security?
Cheers,
Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption & Delphi
Crypto Components. PGP Keys available at the same site.
------------------------------
** 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
******************************
