Cryptography-Digest Digest #353, Volume #12 Thu, 3 Aug 00 19:13:00 EDT
Contents:
Re: Software package locking (AllanW)
Re: New William Friedman Crypto Patent (filed in 1933) (wtshaw)
Re: New William Friedman Crypto Patent (filed in 1933) (JimD)
Re: Encrypting a String to another String containing only certain characters (Dara
Naraghi)
Re: New William Friedman Crypto Patent (filed in 1933) ("Douglas A. Gwyn")
Re: OTP using BBS generator? ("Joseph Ashwood")
Re: OTP using BBS generator? (Grant Anderson)
Re: Cracking RC4-40 in FPGA hardware ([EMAIL PROTECTED])
Re: DES implementation woes (Tony Lauck)
Re: What is the word on TC5? (Mark Wooding)
Re: What is the word on TC5? (tomstd)
Re: What is the word on TC5? (tomstd)
Any new ideas about SNAPPY? (tomstd)
Re: Cracking RC4-40 in FPGA hardware ("CMan")
Re: Encrypting a String to another String containing only certain characters
(SCOTT19U.ZIP_GUY)
Re: New William Friedman Crypto Patent (filed in 1933) (Bruce Schneier)
----------------------------------------------------------------------------
From: AllanW <[EMAIL PROTECTED]>
Subject: Re: Software package locking
Date: Thu, 03 Aug 2000 19:41:22 GMT
In article <8m8v6a$1grv$[EMAIL PROTECTED]>,
"Harris Georgiou" <[EMAIL PROTECTED]> wrote:
> Hello all,
> I have designed a security scheme to for locking non-public domain
software
> packages, like expensive commercial packages do with hasp devices,
but in
> software level. The basic idea is to use steganographic techniques
and bind
> a specific product & it's serial number to each client. The access
control
> (keys) are machine-dependant, time-variant and installation-specific.
In
> regular time intervals, the client should contact the publisher and
update
> it's key.
> However, I cannot find a good way to produce a satisfying key from
> machine-dependant attributes. I have tried CMOS, HD partition table,
etc,
> but usable keys seem to be very short in length, since most PCs share
common
> characteristics.
> Any thoughts?
Yes:
First, if the computer has an Ethernet card use it's ID.
Every Ethernet card ever manufactured has a unique ID
encoded in it. Microsoft's GUID concept uses the
Ethernet card's ID whenever possible. Many computers have
an Ethernet adapter -- even some computers not on a local
network have one, because they are pre-packaged deals that
happen to be used in the wrong environment. If I want to
get DSL at home, the phone company will connect to an
Ethernet adaptor.
Second, DON'T DO IT! What happens if my Ethernet adapter
goes bad? I go buy a new one, and sigh with relief that
I'm finally "up and running" again. But then your program
fails! Or, I buy a new fast computer, complete with
peripherals, and then I copy all data from my old hard
drive to the new system. I may have to re-install the OS,
but all the application programs are still working fine...
except for yours.
If you use anything else about the user's computer except
for the Ethernet address, you'll still have the same
problem when I upgrade computers. Just don't do it! The
extra money you spend making your program secure could
be spent on advertising to increase your sales and show
everyone what a good program you have. You'll make more
money and everyone will be happy.
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: Thu, 03 Aug 2000 12:59:14 -0600
In article <[EMAIL PROTECTED]>, "Trevor L. Jackson, III"
<[EMAIL PROTECTED]> wrote:
> Roger Schlafly wrote:
> > The NSA sat on this one for a long time. Can it be that there were
> > some WWII secrets that were encrypted with this that were still
> > secret in the 1990s?
> >
> > The patent is assigned to the USA.
>
> In re patent silliness, I recently learned that the patent office refused an
> application by the Wright brothers on HTA flight. That's gotta be
> embarrassing.
When the patent process is used to enable government control at the
expense of the inventor, this is contrary to reasonable action. NSA
should not expect to extend its control by virtue of beaucratic planned
inefficiency in addressing an inventor's generated works; their tentacles
are not to be enhansed at the cost of someone elses testacles.
--
Free Circus soon to appear in Philadelphia, complete with a
expectation of elephants, and noisy clowns in undignified
costumes performing slight of logic, and, lots of balloons.
------------------------------
From: [EMAIL PROTECTED] (JimD)
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Reply-To: JimD
Date: Thu, 03 Aug 2000 19:04:31 GMT
On Wed, 02 Aug 2000 22:44:12 -0400, "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
wrote:
>> The NSA sat on this one for a long time. Can it be that there were
>> some WWII secrets that were encrypted with this that were still
>> secret in the 1990s?
If it was a secure system, surely that wouldn't matter.
In any case, would the ciphertexts still be available?
--
__________________________
Jim Dunnett.
g4rga at thersgb.net
------------------------------
Subject: Re: Encrypting a String to another String containing only certain characters
From: Dara Naraghi <[EMAIL PROTECTED]>
Date: Thu, 03 Aug 2000 13:06:32 -0700
[EMAIL PROTECTED] (wtshaw) wrote:
>
>Be more specific as to numbers of input and output characters,
and I will
>check the data base of some possibles. This is more common a
problem than
>many realize. Fear not to give your desired best to worst
requirements.
Hmmm, funny you should mention that this is a common problem
since I'm looking for the same thing! Here's what I'm trying to
do:
Input: alphanumeric string, around 12-15 characters long
Desired Output: encrypted alphanumeric string which excludes
some characters than can be easily confused (e.g. exclude
letters S and I since they can be confused with numbers 5 and
1), preferable not much longer than the input string
Don't need an extremely strong encryption. Basically used to
encrypt a product code which is then entered by a user, and
decrypted back to the original product code.
Any help or pointers to resources would be appreciated.
Dara Naraghi
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: Thu, 3 Aug 2000 19:42:17 GMT
Tom Anderson wrote:
> could be. except that the NSA have been beaten to the post by Ted Nelson,
> who first used the term 'hypertext' in a publication in 1965, and whose
> Xanadu project inspired the web. ...
Indeed, I recall reading about it in Computer Lib/Dream Machines
(the original LARGE-format printing). The main difference between
the Xanadu notion of hyperlink and the HTTP notion is that the
former endeavored to maintain perfect accuracy of the distributed
data structure, while the latter allows broken links. That was a
compromise based on the anticipation that people could manually
work around broken links. It worked well enough to spawn the WWW
and get the general public jumping onto the bandwagon, although
it's still a hassle for automated use of HTTP.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Thu, 3 Aug 2000 14:12:01 -0700
I know I'm arriving rather late to the party but, while Mr Ritter and I have
been on differing sides of discussions before, I agree with him completely
in this case. What he has suggested is to verify the lack of a short cycle,
through a relatively cheap mechanism (certainly cheaper than the compromised
security that could result is that check would have been failed). I find
this to be solid reasoning, and something that should be done by anyone
making use of BBS in this fashion.
On a more personal note, I've noticed that this conversation has drifted
towards being personal insults, please try to remember that Mr Ritter has
been a long standing member of this group, and has build a quite solid,
respected position, all you are doing is harming your credibiltity, as can
be rather easily seen by looking at Mr Ritter's response, which was to the
best of my knowledge completely factual, and dealt more with the issue at
hand than his attacker.
Joe
------------------------------
From: Grant Anderson <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Fri, 04 Aug 2000 09:23:51 +1200
Tim Tyler wrote:
> Grant Anderson <[EMAIL PROTECTED]> wrote:
>
> : The key thing for me is finding out if there is a good reason why this
> : isn't secure? There are proofs for BBS that prove it is as difficult as
> : factoring whereas almost all other schemes (RSA etc) don't have a prove
>
> Being hard to predict is a different thing to being /impossible/
> to predict - which is what an ideal OTP ought to be.
>
> For example an attacker can guess a BBS seed. If they get it right,
> reams of plausible plaintext will spew out - while if they don't it is
> /extremely/ unlikely to. This attack is impossible with a real OTP.
>
> If you use PRNG output and call the resulting system an OTP, people will
> not think you're serious.
>
> Also, being "as hard as factoring" may not say very much in security terms.
>
> QC advocates seem to think factoring is about to turn out to be
> "not as hard as had previously been thought".
Yeah that was the basis of my question. There are a few good generators which
can be shown to exhibit the randomness of purely random sources (or pass all
the randomness tests at least). And a OTP needs a non-resuable PAD of random
bits.
Therefore, a CSPRNG which passes all the random tests and is indistinguishable
from a "real" random source should be suitable as long as:
1) You NEVER use the same pad twice
2) You follow the BBS implementation requirements as discussed
But many people don't consider a generator to be a random source. This is the
bit I don't understand...
Cheers,
Grant.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cracking RC4-40 in FPGA hardware
Date: Thu, 03 Aug 2000 21:29:14 GMT
In article <8mcbbp$[EMAIL PROTECTED]>,
"Paul Morris" <[EMAIL PROTECTED]> wrote:
>
> Fundamentally, Paul suggested that multiple (cheap) FPGAs, running
multiple
> threads each, could potentially brute-force break an RC4-40 in, say,
200
> hours or less. Paul coined the name 'Shallow Crack' in reference to
the EFF
> Deep Crack machine. Does anybody have any comments on the feasibility
of
> this?
Unless I've slipped a decimal point, this should be very easy.
The limiting factor in RC4 looks like the table initialization.
For each of 256 iterations, it reads one value from the table,
does some computation, then swaps two values. If we assume a 2 ported
ram, and logic is free compared to memory (true for FPGAs) then this
should take 3 cycles.
1) read the table entry, figure out which two to swap
2) read the two values.
3) write the two values.
so we have 3x256 or 768 cycles for each trial key.
Then we need to decypher some text, and either see if it's OK
(known plaintext) or at least plausible (unknown plaintext).
Each byte takes a few cycles, probably 40 bytes are plenty,
so another 120 cyles.
We need to report results, cycle to the next key, etc., but 1000 cycles
should be plenty to check one key.
Each cycle requires a memory read and a pair of 8 bit adds, so 10ns
looks like a good estimate. Then we have 10 usec/key, or 10^5 keys
per second. 2^40 is about 10^12, so even with one such piece of
hardware we have 10^7 seconds, or about 2800 hours to search all
keys. We expect success on the average in 1/2 this time, or 1400
hours.
But even the smallest and cheapest Xilinx FPGA (Spartan) has 4 of
these blocks, so we have 350 hours average. The bigger ones have
32 independent memory blocks, for an average time of 43 hours
per chip.
We can run as many chips as we want in parallel, of course, so if
we had 43 big chips we get an average solution time of 1 hour, and
a max of 2 hours. Of course it might be more cost effective to use
more of the cheaper chips - that's an engineering tradeoff.
So this seems pretty easy. I'd approach it like this:
0) Write a copy of your algorithm in Verilog or VHDL and
simulate it (with say 10 bit keys). See how many cycles it
takes per key.
1) Get a development board for a PC with a Xilinx on it (Any
Xilinx - whatever is most convenient)
2) Get a single copy of the algorithm working and solving a
bigger but still tractable problem (say 28 bits)
3) Cram as many copies as you can into a single FPGA and demo
that with 36 bit keys.
4) Build or buy a board with lots of FPGAs and program/use
that with full 40 bit keys.
Everything after step 2 is just engineering and not cryptography,
but makes a much more impressive demo.
Lou Scheffer
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tony Lauck <[EMAIL PROTECTED]>
Subject: Re: DES implementation woes
Date: Thu, 03 Aug 2000 17:57:22 -0400
Let's not start a holy war on what's natural or strange. At least not until
after a chance to (re)read Danny Cohen's entertaining classic paper. [1]
Tony Lauck
[1] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE, October
1981.
ftp://ftp.isi.edu/in-notes/ien/ien-137.txt.3
Mark Wooding wrote:
>
> John Savard <[EMAIL PROTECTED]> wrote:
>
> > Although what's funny about considering the most significant digit to
> > be the first digit? That's the way we write numbers.
>
> Yes, but it's not usually the way we label the digits. If we're writing
> in some base b, we tend to label the digits so that digit i represents
> some multiple of b^i. Hence, the least significant bit of a binary
> number is bit zero. I think that the expression of a number x with
> digits x_i in base b as
>
> ---
> > x_i b^i
> ---
>
> illustrates the `naturalness' of this particular labelling.
>
> The DES numbering is strange for two reasons.
>
> Firstly, it's the `wrong way round'.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: What is the word on TC5?
Date: 3 Aug 2000 21:53:58 GMT
tomstd <[EMAIL PROTECTED]> wrote:
> Find specific values of 'd' and I will deem your attack valid.
What? It works for any nonzero input difference d. Just pick one. See
the article I referred to (and the thread it came from) for the details.
-- [mdw]
------------------------------
Subject: Re: What is the word on TC5?
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 03 Aug 2000 15:10:13 -0700
[EMAIL PROTECTED] (Mark Wooding) wrote:
>tomstd <[EMAIL PROTECTED]> wrote:
>
>> How does the generic attack work?
>
>I described the impossible differentials in Feistel networks
with
>bijective F-functions in
<[EMAIL PROTECTED]>. The
>summary is that there are important structural differential
properties
>of Feistel networks with small numbers of rounds (3 for general
Feistel
>networks, 5 for networks with bijective F-functions).
>
>Since the outer Feistel has only four rounds and a bijective F-
function,
>it exhibits such impossible differentials.
>
>The impossible differential is (0, d) -/-> (?, d). Here's how
it
>evolves:
>
> 1. (0, d) ---> (d, 0)
You mean to say 'd' causes '0' but that is impossible.. Or am I
missing something...?
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: What is the word on TC5?
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 03 Aug 2000 15:09:13 -0700
[EMAIL PROTECTED] (Mark Wooding) wrote:
>tomstd <[EMAIL PROTECTED]> wrote:
>
>> Find specific values of 'd' and I will deem your attack valid.
>
>What? It works for any nonzero input difference d. Just pick
one. See
>the article I referred to (and the thread it came from) for the
details.
But in order to distinguish the cipher from random you have to
first pick d, d' and d'' values right?
I mean for any cipher I can say random differences cause random
differences...
I don't see how this hurts anything...
I will look up the other article...(if you could email it to
[EMAIL PROTECTED] I would appreciate it)
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Any new ideas about SNAPPY?
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 03 Aug 2000 15:20:41 -0700
Snappy is my 64-bit block cipher I sent to the contest. It uses
only the required memory for the key and block (plus little
stack) so is ideal for embeded platforms.
I am shocked that it has not been broken yet... I am not that
skilled (which should be obvious) but I thought Mark or David
would have killed it by now...
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: "CMan" <[EMAIL PROTECTED]>
Subject: Re: Cracking RC4-40 in FPGA hardware
Date: Thu, 3 Aug 2000 15:34:40 -0700
I don't think MD4/5 is easy to implement in hardware. (I could be wrong on
this point!!)
I don't think I have ever seen an application that did not hash the key
before running the RC4 key schedule. Just laying out the 40 bit key and
repeating it in the RC4 S-box and then running the key schedule
significantly reduces the computational load associated with a brute force
attack.
Unless the RC4 hardware and the MD4/5 hash computation run at approximately
the same speed, the process sort of falls apart. The hardware will just sit
there waiting for new hashes to load.
JK
--
CRAK Software
http://www.crak.com
Password Recovery Software
QuickBooks, Quicken, Access...More
Spam bait (credit E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
webmaster@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote in message news:8mco74$erk$[EMAIL PROTECTED]...
> In article <8mcbbp$[EMAIL PROTECTED]>,
> "Paul Morris" <[EMAIL PROTECTED]> wrote:
> >
> > Fundamentally, Paul suggested that multiple (cheap) FPGAs, running
> multiple
> > threads each, could potentially brute-force break an RC4-40 in, say,
> 200
> > hours or less. Paul coined the name 'Shallow Crack' in reference to
> the EFF
> > Deep Crack machine. Does anybody have any comments on the feasibility
> of
> > this?
>
> Unless I've slipped a decimal point, this should be very easy.
> The limiting factor in RC4 looks like the table initialization.
> For each of 256 iterations, it reads one value from the table,
> does some computation, then swaps two values. If we assume a 2 ported
> ram, and logic is free compared to memory (true for FPGAs) then this
> should take 3 cycles.
> 1) read the table entry, figure out which two to swap
> 2) read the two values.
> 3) write the two values.
> so we have 3x256 or 768 cycles for each trial key.
>
> Then we need to decypher some text, and either see if it's OK
> (known plaintext) or at least plausible (unknown plaintext).
> Each byte takes a few cycles, probably 40 bytes are plenty,
> so another 120 cyles.
>
> We need to report results, cycle to the next key, etc., but 1000 cycles
> should be plenty to check one key.
>
> Each cycle requires a memory read and a pair of 8 bit adds, so 10ns
> looks like a good estimate. Then we have 10 usec/key, or 10^5 keys
> per second. 2^40 is about 10^12, so even with one such piece of
> hardware we have 10^7 seconds, or about 2800 hours to search all
> keys. We expect success on the average in 1/2 this time, or 1400
> hours.
>
> But even the smallest and cheapest Xilinx FPGA (Spartan) has 4 of
> these blocks, so we have 350 hours average. The bigger ones have
> 32 independent memory blocks, for an average time of 43 hours
> per chip.
>
> We can run as many chips as we want in parallel, of course, so if
> we had 43 big chips we get an average solution time of 1 hour, and
> a max of 2 hours. Of course it might be more cost effective to use
> more of the cheaper chips - that's an engineering tradeoff.
>
> So this seems pretty easy. I'd approach it like this:
> 0) Write a copy of your algorithm in Verilog or VHDL and
> simulate it (with say 10 bit keys). See how many cycles it
> takes per key.
> 1) Get a development board for a PC with a Xilinx on it (Any
> Xilinx - whatever is most convenient)
> 2) Get a single copy of the algorithm working and solving a
> bigger but still tractable problem (say 28 bits)
> 3) Cram as many copies as you can into a single FPGA and demo
> that with 36 bit keys.
> 4) Build or buy a board with lots of FPGAs and program/use
> that with full 40 bit keys.
>
> Everything after step 2 is just engineering and not cryptography,
> but makes a much more impressive demo.
>
> Lou Scheffer
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Encrypting a String to another String containing only certain characters
Date: 3 Aug 2000 22:40:09 GMT
[EMAIL PROTECTED] (Dara Naraghi) wrote in
<[EMAIL PROTECTED]>:
>[EMAIL PROTECTED] (wtshaw) wrote:
>>
>>Be more specific as to numbers of input and output characters,
>and I will
>>check the data base of some possibles. This is more common a
>problem than
>>many realize. Fear not to give your desired best to worst
>requirements.
>
>Hmmm, funny you should mention that this is a common problem
>since I'm looking for the same thing! Here's what I'm trying to
>do:
>
>Input: alphanumeric string, around 12-15 characters long
>
>Desired Output: encrypted alphanumeric string which excludes
>some characters than can be easily confused (e.g. exclude
>letters S and I since they can be confused with numbers 5 and
>1), preferable not much longer than the input string
>
>Don't need an extremely strong encryption. Basically used to
>encrypt a product code which is then entered by a user, and
>decrypted back to the original product code.
>
>Any help or pointers to resources would be appreciated.
>
>Dara Naraghi
>
>
>-----------------------------------------------------------
>
Here is an example of converting a string from one
string subset to another "with out encryption".
cond1.txt file follows
0000 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 *ABCDEFGHIJKLMNOP*
0010 51 52 53 54 55 56 57 58 59 5A 5F 30 31 32 33 34 *QRSTUVWXYZ_01234*
0020 35 36 37 38 39 2E 3F . . . . . . . . . *56789.?*
number of bytes is 39
str1.txt file follows
0000 54 48 49 53 5F 49 53 5F 41 5F 54 45 53 54 5F 4F *THIS_IS_A_TEST_O*
0010 46 5F 54 48 45 5F 4D 45 54 48 4F 44 2E . . . *F_THE_METHOD.*
number of bytes is 29
at this point run "h2comaf.exe str1.txt fin.bin cond1.txt"
this does an adaptive huffman compression on the file
str1.txt places the results in the file fin.bin and the
characters in str1.txt are a subset of the condtion file cond1.txt
fin.bin file follows
0000 29 E0 89 03 19 A0 48 22 8D 55 90 09 20 02 47 99 *).....H".U.. .G.*
0010 10 20 E0 04 . . . . . . . . . . . . *. ..*
number of bytes is 20
The file fin.bin is a "finitely odd file" meaning at least
one bit in last byte has a one set. You can now run my code
to convert this file in a bijective way to either a regular
file of odd or even bytes or even blocks of 8 using code
in "fin2in.zip". If you convert and encrypt when done
convert it back to a "finitely odd file" and run
the h2uncsf.exe uncompressor.
For sake of argument no encryption being done so we just
uncompress using desired condtion file. cond2.txt
cond2.txt file follow.
0000 41 42 43 44 45 46 47 48 4A 4B 4C 4D 4E 4F 50 51 *ABCDEFGHJKLMNOPQ*
0010 52 54 55 56 57 58 59 5A 5A 5A 5A 5A 5A 31 32 33 *RTUVWXYZZZZZZ123*
0020 34 35 36 37 38 39 . . . . . . . . . . *456789*
number of bytes is 38
note I choose extra Z's just to show you can weight the
static huffman uncompress. These are in the file ah2af.zip
at this point run "h2uncsf.exe fin.bin str2.txt cond2.txt"
this does a static huffman uncompress of the finitely odd
file fin.bin using the tree made from condtion file cond2.txt
the file str2.txt will contain the uncompressed data and will
only consist of symbols in the cond2.txt file.
str2.txt file follows
0000 38 32 34 51 33 5A 5A 36 42 4F 37 37 5A 4B 5A 4C *824Q3ZZ6BO77ZKZL*
0010 58 55 34 56 33 34 4B 5A 5A 5A 39 5A 35 34 48 5A *XU4V34KZZZ9Z54HZ*
0020 33 48 . . . . . . . . . . . . . . *3H*
number of bytes is 34
Note even in this poor example using fewer symbols in
cond2.txt file compared to cond1.txt file some compression
took place.
I hope this example helps even though no encryption was done
if you run the opposite programs
h2comsf.exe str2.txt temp.bin cond2.txt
followed by
h2uncaf.exe temp.bin str3.txt cond1.txt
then str3,txt is same as str1.txt
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS **no JavaScript allowed**
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed ** JavaScript OK**
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction
of the truth."
------------------------------
From: Bruce Schneier <[EMAIL PROTECTED]>
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: Thu, 03 Aug 2000 17:47:11 -0500
On Thu, 03 Aug 2000 06:53:35 GMT, [EMAIL PROTECTED]
(John Savard) wrote:
>On Wed, 02 Aug 2000 16:42:24 -0500, Bruce Schneier
><[EMAIL PROTECTED]> wrote, in part:
>
>>William Friedman filed a patent application for an Enigma-like
>>encryption device in 1933. The Patent Office awarded the patent this
>>month:
>
>> http://www.patents.ibm.com/details?&pn=US06097812__&s_all=1
>
>Looking at the claims, this appears to be the patent on the original
>M-134 cipher machine, in which five rotors (used in Hebern fashion)
>were controlled by a paper tape.
Here is what Whit Diffie said about the M-134 in _Privacy on the
Line_:
"In the mid 1930s Friedman designed a rotor machine, designated
M-134a, whose five wheels moved under the control of a paper tape. In
retrospect this can be seen to be merely an overly complicated way of
achieving a one-time cryptosystem, but at the time the additional
complexity must have seemed an advantage. Unfortunately, the M-134a
had the same problem that goes with any one-time system: it needed
lots of keying material. A young cryptanalyst named Frank Rowlett was
given the task of producing matching pairs of key tapes --- a task
made tedious by the fact that any error in the tapes would produce not
only an error in the plain text but also a disastrous loss of
synchronization between the sending and receiving machines. Rowlett
conceived of using one rotor machine to manufacture the pattern of
rotor motions for the other, an idea that was to remain officially
secret for 60 years."
He calls it one of the worst crypto machines ever designed.
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
** 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
******************************
