Cryptography-Digest Digest #638, Volume #10 Sat, 27 Nov 99 12:13:01 EST
Contents:
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Noise Encryption (Guy Macon)
Re: brute force versus scalable repeated hashing (SCOTT19U.ZIP_GUY)
Re: A Truly Weird Double-DES Mode (SCOTT19U.ZIP_GUY)
Re: cryptography control? (SCOTT19U.ZIP_GUY)
replay.com? where's this great crypto archive gone? (Markus S.)
Re: cryptography control? (SCOTT19U.ZIP_GUY)
Re: Nazi Dockyard Cipher System? (John Savard)
none (Anonymous)
Re: Enigma Plug Board (John Savard)
Re: Noise Encryption (SCOTT19U.ZIP_GUY)
Re: How ScramDisk will recover >> logistics problems in Scramdisk (Lincoln Yeoh)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: 27 Nov 1999 07:13:30 PST
In article <81ogtv$upa$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tom St Denis) wrote:
>
>In article <[EMAIL PROTECTED]>,
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>> Tom St Denis wrote:
>> > Universially random should mean something which is random, and by NO
>> > MEANS at all predictable. However this cannot exist in nature.
>>
>> Who made you God?
>
>Ok, explain to me something that is truly random.
>
The time it takes for an individual atom of potassium-40
to decay to Argon-40.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Noise Encryption
Date: 27 Nov 1999 07:18:18 PST
I think that we are all familiar with the case of the
clueless newbie who thinks that he has discovered what
all of the experts have missed. I see this a lot in my
field of expertise (developing real-time hardware and
software). The clueless newbie is almost always wrong,
and the new idea is almost always old.
<sarcasm=ON> Given the above, I am sure that you will
all be just thrilled to learn that I, a clueless newbie
with no training in math or crypto, and without reading
any books on the subject, have invented a 100% perfect
non crackable method of sending messages over the
Internet! And if you point out an obvious flaw I will
just patch it a bit and present it again, all the while
putting the burden of proof on you to prove it wrong,
and claiming victory if you ignore me!!!<sarcasm=OFF>
Seriously, though, I just want to learn a bit more and
realize that my "new" ideas are probably just old ideas
that I have rediscovered. That being said, here is my
idea for sending messages:
[Step 1]
On my computer, I dedicate a 1 gigabyte hard drive to
the task of holding random (?) data that I generated
myself (more on the method later).
[step 2]
Every so often (no more often than once per month), I
burn a pair of recordable CDs, test them to make sure
that they are identical, and hand deliver one to a
person who I wish to have future communications with.
I them wipe the hard disk and start over. I use a
different CD for each person I wish to talk to.
[step 4]
when either of us wishes to encode, we use the contents
of the CD as a one time pad by performing a bitwise
exclusive-or of a section of the CD with our message and
overwrite that section of the CR-R by burning all of the
bits in that section. We then email the encoded message.
[step 5]
when either of us wishes to decode, we use the contents
of the CD as a one time pad by performing a bitwise
exclusive-or of a section of the CD with the received
message then overburning that section of the CR-R.
Assuming true random data, is the above scheme secure
against interception and decoding? I assume that the
attacker has full knowledge of everything except the
random data or the unencoded message, and I realize
that the usual "bribe my friend/break into my safe and
copy my CDs/etc" attacks are not addressed by this.
****************************************************
RANDOM DATA??
"Assuming true random data"... That's a BIG assumption.
I know quite a lot about computers and electronics, and
this knowledge leads me to be suspicious of such claims
of randomness. This is not a trivial problem. Here is
my best shot at achieving a gigabyte of random bits:
Start with a hard disk that is all zeros.
Make a Zener noise random bit generator. Exclusive-or
the output with what is on the disk. let it run 24
hours a day, looping through the pool again and again.
Do the same with the digitized output of a local talk
radio station, a microphone that picks up traffic noise,
FM interstation noise, and anything else that you can
think of.
Every time you get an email, download a file, read
the content of a newsgroups post, look at a webpage,
etc, Exclusive-or it with what is on the disk.
Keep a fast running counter that measures how many
microseconds it takes between your keystokes, mouse
movements, and the time between incoming TCP/IP packets,
Exclusive-or the counts with what is on the disk.
Run all of these processes 24 hours a day, constantly
mixing up the pool.
Somewhere around the middle of the month, run every
pseudorandom number generator that you can find.
Your 1000 megabyte random data disk holds more data
than needed to fill a 650 megabyte CD, so use the
extra 350 megabytes for pseudorandom number generator
seeds, clearing the data as it is used. Exclusive-or
the pseudorandom data with what is on the disk.
let at least a couple of weeks of mixing go by after
doing this.
Will this method give me a gigabyte of data that
is suitable for the above method of communicating?
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.security.misc
Subject: Re: brute force versus scalable repeated hashing
Date: Sat, 27 Nov 1999 16:22:16 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Johnny Bravo)
wrote:
>On Sat, 27 Nov 1999 05:51:41 GMT, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote:
>
>>> And any system protected by a short key is only as strong as that
>>>key. The point of the paper which you admit you didn't read, yet
>>>still felt you knew enough about to attack, is that if your keyspace
>>>is 2^32 you have 32 bits of security. If you force your attacker to
>>>perform 10 million hashes of your key in order to test it, your
>
>> However one has to be sure this so called 10 million hashing
>>does not lead to some limit cycle that would give the actual attacker
>>a better handle so that far less than 2^32 patterns need to be tested.
>
> This is covered in the paper, which you admit you didn't read. Why
>do you persist in making stupid irrelevant comments that have no
>bearing on the paper under discussion.
>
>> Who said its meant to be a OTP pad. Its just meant to be orders better
>>than what the NSA will trick fools like you into using.
>
> How can it be orders of magnitude better than current ciphers, you
>stated that an 8 bit byte has 7 possible states. You haven't got a
>clue, how are we supposed to trust your cipher?
look asshole the comment referred to someone saying that a byte
was rotated. And that there are 7 additional states than the starting
state for a byte. I cleared that up several times. Your just being a
fucking asshole if you can't see what I meant by rotate. I did not
realize until after letter send the auther on that topic meant by
rotate to add mod 256. So fuck you.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
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
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: A Truly Weird Double-DES Mode
Date: Sat, 27 Nov 1999 16:16:18 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(John Savard) wrote:
>I recently noted that because CBC mode works like this:
>
>ciphertext = DES( plaintext XOR previous ciphertext)
>
>and CFB mode works like this:
>
>ciphertext = plaintext XOR DES( previous ciphertext )
>
>the two modes are very closely related -
>
>CBC mode can be thought of as
>
>ciphertext = DES( plaintext XOR DES( previous plaintext XOR ... ) )
>
>and CFB mode can be thought of as
>
>ciphertext = plaintext XOR DES( previous plaintext XOR ... )
>
>the two are really the same mode, but with the ciphertext taken off at
>different points in the process.
>
>Since the two streams of ciphertext differ in that the CFB output is
>the plaintext XORed with the CBC output, if one were to use *both*
>methods with the same key and message, one would reveal the plaintext.
>
>Now, then: what if did the following:
>
>use DES( key2, ciphertext(N-2) )
>
>to select the bits of ciphertext(N) as being either from
>
>DES( key1, ciphertext(N-1) xor plaintext(N) )
>
>or from
>
>plaintext(N) xor DES( key1, ciphertext(N-1) )
>
>That ciphertext wouldn't give away the plaintext message...but
>unfortunately, even with the key, it couldn't be decrypted either.
>
>Oh, well, just let the REAL ciphertext be produced by the formula
>
>real ciphertext(N+1) = plaintext(N+1) xor ciphertext(N)
>
>and it will work.
>
>Now, this mode doesn't make very efficient use of the DES with key2,
>for the same reason as an attack on the Geffe generator is possible;
>bits of the output have a 75% probability of matching either of the
>two possible sources.
>
>But are there any attacks on this mode? Is the principle useful
>elsewhere?
Becareful John you might stumble into a useful mode that has many
features the NSA types don't want to see in a 3 letter chaining mode.
Another weakness in the 3 letter chaining modes is that they are
designed not only to not diffuse information but in reality one can
undo the chain in both directions. That is you chain forward through
the file when you write the cipher text and you chain forward when
you convert the cipher text back. However you could have read the
file in reverse and started with last block and work you way towards
the top. It is never done this way since it is hard. With something like
"Wrapped-PCBC" you chain forward to write the cipher text. But there
is not enough information when decrypting to un chain the cipher text
in the forward direction it can ONLY be unchained in the reverse
direction. This is far different that any of the other common block
chaining modes. While normal PCBC is such that it can't be unchained
in the reverse direction. Don't confuse the old PCBC with mine. The old
one can only be unchained in the forward direction while mine can only
be undone in the reverse direction. This fact that the chaining can only
be undone in the reverse direction is so different that most NSA types
would be to lazy to even analyze a file from this point of view.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
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
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: talk.politics.crypto
Subject: Re: cryptography control?
Date: Sat, 27 Nov 1999 16:30:19 GMT
In article <81o24q$l05$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>I came across an artical that brings up some interesting points
>concerning government control of cryptography in the future. The link
>is:
>
>http://home.att.net/~dontbefooled/CESA99.htm
>
>I hope this not too far off topic as it does not go into specifics of
>cryptography. The jist is that there have been some recent political
>moves in the USA to increase the regulation/control of cryptography.
>Its kinda like "If unbreakable cryptography is outlawed then only
>outlaws will use it."
>BDS
Yes I am sure most in here are aware of it. The conservatives in
congress are to dumb to understand crypto so they really don't want
to ease restrictions. While the liberals like to think they are far more
intelligent than the mass of people so they pretend to give more freedom
and at the same time put in more controls. The liberals under Clinton
have perfected the fine art of lying. They say one thing while at the same
time they do the opposite. Our best hope is to educate the conservatives
since if there IQ would go up a notch they may understand what crypto
is and why it is important to freedom. The liberals already know this but
they are the enemies of freedom.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
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
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (Markus S.)
Subject: replay.com? where's this great crypto archive gone?
Date: Sat, 27 Nov 1999 15:40:26 GMT
hello,
i just noticed that www.replay.com now redirects to www.replaytv.com.
does anyone know what happend to the crypto archive on ftp.replay.com?
where's all of that gone?
thanks, Markus
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: talk.politics.crypto,alt.security
Subject: Re: cryptography control?
Date: Sat, 27 Nov 1999 16:42:56 GMT
In article <81o24q$l05$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>I came across an artical that brings up some interesting points
>concerning government control of cryptography in the future. The link
>is:
>
>http://home.att.net/~dontbefooled/CESA99.htm
This is one of the BEST articles I have come across in a long time.
The kind that I am curious why Mr BS. can't write. Maybe he could if
truely wanted to help crypto.
>
>I hope this not too far off topic as it does not go into specifics of
>cryptography. The jist is that there have been some recent political
>moves in the USA to increase the regulation/control of cryptography.
>Its kinda like "If unbreakable cryptography is outlawed then only
>outlaws will use it."
>BDS
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
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
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Nazi Dockyard Cipher System?
Date: Sat, 27 Nov 1999 15:58:00 GMT
On 27 Nov 1999 09:10:42 GMT, [EMAIL PROTECTED] (UBCHI2) wrote:
>Anyone have details on the German Dockyard cipher system? How did it work?
Yes; it's described in the book "Codebreakers", edited by Hinsley and
Stripp, from Oxford.
The message to be enciphered was divided into pairs of five-letter
groups. A set of bigram tables was used to encipher corresponding
letters from the two groups.
The bigram tables were reciprocal: if AA became JQ, then JQ became AA.
This convenience feature could be used by the cryptanalyst; at the
least, it eliminated possibilities.
Also, no enciphered bigram ever contained any letter found in a
plaintext bigram. This was a mistake.
Enciphering letter pairs that weren't adjacent had a plus side and a
minus side. By removing plain-language bigram frequencies from the
choice of bigrams to use, a wider variety of bigrams were used, making
for a flatter frequency count. However, this also meant that the
cipher could be treated as a monalphabetic substitution with
homophones in two different ways.
------------------------------
Date: Sat, 27 Nov 1999 17:02:00 +0100 (CET)
From: Anonymous <[EMAIL PROTECTED]>
Subject: none
This is just a test message.
-
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Enigma Plug Board
Date: Sat, 27 Nov 1999 16:07:07 GMT
On 27 Nov 1999 03:06:29 GMT, [EMAIL PROTECTED] (UBCHI2) wrote:
>I read Singh's account of how Turing broke the security of the enigma plug
>board but don't quite get it. It sounded like he passed the encryptions
>through two mechanisms which together reversed the effect of the plugboard.
>Can anyone briefly fill in the details?
The Turing bombe did have two sets of Enigma rotors that the
electrical signal went through. But this didn't have anything to do
with the plugboard; because the signal in the Enigma went through the
same rotors twice, sorting out the output signal from the original
letter that went in was complicated enough in an Enigma, and would
have been too complicated for a bombe.
The plugboard was negated in another way: the bombe was used with
cribs, probable text that was aligned with part of an enciphered
message. This was possible because the Enigma never enciphered a
letter to itself, so if a crib was long enough, it could be well
aligned.
But instead of looking for places where A became X, if that happened
in the crib, because of the plugboard A became X just meant some
letter became some other letter.
What was sought was _cycles_. If A became N in the third letter of the
crib, and N became T in the twelfth letter of the crib, and T became A
in the twenty-third letter of the crib,
then even if A, N, and T were all taken to other letters by the
Enigma's plugboard, this cycle in the crib still served to distinguish
some rotor positions from others. So one had three simulated Enigmas,
one nine positions ahead and one twenty positions ahead of the first.
And then one looked for places where one letter became another letter
on the first one, that other letter became yet another letter on the
second one, and that letter went back to the first letter on the third
one.
This is how the plugboard was ignored. Every letter going into the
first one was connected to every letter going out of the third one.
Electricity was fed into one letter of the first one.
If no such cycle happened in a position, that electricity went into
all the other letters. If the cycle did happen, one light (or the
other 25 lights, if the right letter was where the electricity went
in) would not light up. (Actually, relays would be used, to stop the
machine whenever that happened.)
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Noise Encryption
Date: Sat, 27 Nov 1999 17:41:24 GMT
In article <81osnq$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Guy Macon)
wrote:
>I think that we are all familiar with the case of the
>clueless newbie who thinks that he has discovered what
>all of the experts have missed. I see this a lot in my
>field of expertise (developing real-time hardware and
>software). The clueless newbie is almost always wrong,
>and the new idea is almost always old.
This is a common problem. But unfortunately it is
often the clueless newbie that makes the next big
discovery. Discovery is slowed when the experts
take control. The two examples I would give are.
One the closed air rebeathing systems the seals
use. The guy who invented it was treated like
shit by the US government becuase they spent a
fortune on expert contractors that could not do the
project. In frastration he started making the stuff available
to the public. The other lovely example is in chemsirty.
The noble gas compounds. The experts even made a
film full of standford Phd's attempting to make such
compounds and then failing and saying they knew they
could not do it becasue it was impossible. Then some
one started doing it. Can anyone say Xeon trioxide
a very cool explosive that leaves no traces.
>
><sarcasm=ON> Given the above, I am sure that you will
>all be just thrilled to learn that I, a clueless newbie
>with no training in math or crypto, and without reading
>any books on the subject, have invented a 100% perfect
>non crackable method of sending messages over the
>Internet! And if you point out an obvious flaw I will
>just patch it a bit and present it again, all the while
>putting the burden of proof on you to prove it wrong,
>and claiming victory if you ignore me!!!<sarcasm=OFF>
>
>Seriously, though, I just want to learn a bit more and
>realize that my "new" ideas are probably just old ideas
>that I have rediscovered. That being said, here is my
>idea for sending messages:
For some reason in crypto the most common "new idea"
is a from of block encryption that reduces to XOR a key
over repeating blocks of data. I see this over and over.
Also the next most common is trying to do a clever
substituion and the 8 bit block sizee. It is well know
that 8 bits is to small and any one using a random S
table for the 8 bit lookup is going to have big trouble
since any 8 bit block method where you have output
this is limited only by key and input is reducable to
an S-table model and all are breakable.
The next is the secret code type of method where
the newbie assumes that enemy does not have
access to your program. While this last one may be
ok with a group of friends it is not the kind of general
use methods people in this group want to see.
With the above 95% of the ametur crypto can
be eliminated. However the crypto gods do not
want to look at the rest or have them see the light
of day. And will convinietly say no ametuer can
design good crypto. To do that I say
Bull Shit.
>
>[Step 1]
>On my computer, I dedicate a 1 gigabyte hard drive to
>the task of holding random (?) data that I generated
>myself (more on the method later).
>
>[step 2]
>Every so often (no more often than once per month), I
>burn a pair of recordable CDs, test them to make sure
>that they are identical, and hand deliver one to a
>person who I wish to have future communications with.
>I them wipe the hard disk and start over. I use a
>different CD for each person I wish to talk to.
Whoops I forgot to include the OTP. It is old
and it is NONSECURE. but the trick is generating
the random disks and getting them to your friends.
>
>[step 4]
>when either of us wishes to encode, we use the contents
>of the CD as a one time pad by performing a bitwise
>exclusive-or of a section of the CD with our message and
>overwrite that section of the CR-R by burning all of the
>bits in that section. We then email the encoded message.
>
>[step 5]
>when either of us wishes to decode, we use the contents
>of the CD as a one time pad by performing a bitwise
>exclusive-or of a section of the CD with the received
>message then overburning that section of the CR-R.
>
>Assuming true random data, is the above scheme secure
>against interception and decoding? I assume that the
>attacker has full knowledge of everything except the
>random data or the unencoded message, and I realize
>that the usual "bribe my friend/break into my safe and
>copy my CDs/etc" attacks are not addressed by this.
>
>****************************************************
>
>RANDOM DATA??
Yes that is the question and it gets a lot of coverage
on this use group.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
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
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,comp.security.pgp.tech
Subject: Re: How ScramDisk will recover >> logistics problems in Scramdisk
Date: Sat, 27 Nov 1999 17:00:47 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 25 Nov 1999 10:02:17 -0500, [EMAIL PROTECTED] wrote:
>Alter 1 byte without increasing container file size.
>After altering, I could not mount container [ provided pass / correct pass / has
>not been accepted ].
Dunno, I tried it out, changed a single byte (81 to FF) and I could mount
it. I'm using 2.02c and blowfish.
I had stored a file inside, and only 9 bytes were changed. Hmm 72 bits
changed for 6 bits.
What program are you using to change the byte?
As long as you don't alter the first bunch of stuff you should be able to
mount it.
If you alter the part that happens to be the FAT or directory you may have
to run scandisk as well to fix things. But I'd recommend you make a backup
of the container first before you do scandisk, just in case scandisk does
something wrong.
I notice that a range of bytes from 0x2700-0x27FF changes. Not sure why..
Maybe it's the date.
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
** 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
******************************
