Cryptography-Digest Digest #29, Volume #9 Wed, 3 Feb 99 15:13:05 EST
Contents:
Re: 65536-bit block cipher ("Trevor Jackson, III")
Re: Foiling 56-bit export limitations: example with 70-bit DES
([EMAIL PROTECTED])
Re: Metaphysics Of Randomness ("Trevor Jackson, III")
Re: Crypt Info ???? (Albert P. Belle Isle)
Re: Random numbers generator and Pentium III (R. Knauer)
Re: What is left to invent? (John Savard)
Re: The Folger Manuscript (Jim Gillogly)
Re: hardRandNumbGen (R. Knauer)
Re: [question/challenge/HELP ME! IEE!] Another unheard of punk who thinks hes come
up with something new... (Vektor)
Re: RNG Product Feature Poll (Dan S. Camper)
Re: The Folger Manuscript (Jim Gillogly)
Re: RNG Product Feature Poll (R. Knauer)
Re: Encoding for telephone over Internet (R. Knauer)
Re: The Folger Manuscript (John Savard)
----------------------------------------------------------------------------
Date: Wed, 03 Feb 1999 13:15:51 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: 65536-bit block cipher
Multiplication is considered a necessary prerequisite to cipher design.
Since the correct product of 256 bytes and 8 bits per byte is 4096, we have
to conclude that one of the following is true:
The cipher is a 4096-bit cipher.
The key table has more than 256 bytes
The bytes in your 256-slot key table have more than 8 bits.
You cannot multiply.
Would you please enlighten us as to which of the above statements correctly
describes reality?
[EMAIL PROTECTED] wrote:
> 65536-bit block cipher
>
> The size of the block is 65536 bits or 256 bytes.
> Inserted key is transformed to 256 bytes( effective key)
> using current encryption.
>
> There are two interpretations of the key. One of them
> is mentioned above in 16-bit chained encryption a sequence
> of automorphisms of a group. The second is the sequence
> of transpositions of bytes in block. Each byte of the key
> represents a simple transposition of bytes as follows:
> index of key byte is the index of the first byte in block and the
> context of the key byte is the index of the second byte in block.
> During encryption of the block the key is scanned from the
> beginning to the end and during decryption reverse.
>
> Encryption follows in two steps:
>
> 1. A block is encrypted using 16-bit Alex chained algorithm.
> This approach gives suitable dispersion of bytes in
> the block.
>
> 2. A transposition of all 256 bytes in block is made using
> 256 byte key.
>
> This algorithm is implemented and has performance apr.764 Kb/sec.
>
> The freeware executable, updated
> algorithm description are available for download at
>
> www.online.de/home/aernst
>
> Please follow the link for 'Alex16x65536.zip' in download area.
>
> Regards
> Alex
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Foiling 56-bit export limitations: example with 70-bit DES
Date: Wed, 03 Feb 1999 17:33:45 GMT
In article <797snm$td8$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <797igo$jo7$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > In article <794ruh$a7k$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> > > In article <78t64b$61o$[EMAIL PROTECTED]>,
> > > [EMAIL PROTECTED] wrote:
> > > > In article <78ss2c$s4b$[EMAIL PROTECTED]>,
> > > > [EMAIL PROTECTED] wrote:
> > > [snip]
> > > > > Have you considered doing both (i.e., Ci = rndblock_X XOR DES(Pi XOR
> > > > > rndblock_X), where rndblock_X is the block you chose out of 2^M
blocks)?
> > > > >
> > > >
> > > > Yes, but it is worse.
> > >
> > > Why?
> >
> > Because if the plaintext is encrypted with an unknown-key (the choice I am
> > considering) then the intended recipient will gain less in comparison to the
> > attacker.
>
> I don't understand. If you choose a different "whitener block"
BTW, it is not a "whitener block" as the ciphertext is already "white" --
that is why I did not use such name, it is misleading. I have named it
"unknown-key" and I see no reason for it to be changed in the discussion --
in fact, that describes it's unique characteristics in comparison to other
methods.
> for each
> message, then you could send the same message twice, with the same DES key,
> and your security would be better of you "whiten" the plaintext before
> DES-encryption, and then "whiten" the DES ciphertext before transmission.
>
> Your contention that this is not necessary because one can use a different
> DES key for each message is good, but I understand cryptography to be the art
> of ameliorating even very unlikely risks. If a simple change makes it secure
> even if you use the same DES key to send the same message, then you might as
> well make the change.
>
The reasons why adding a previous encryption to the plaintext are, mainly:
1. you are wasting controlled-bits if the previous encryption uses
secret-bits. Mind you, this is important not only for those that live under
such constraints but also to decrease secret-key sizes (smart-cards, etc).
2. if the encryption uses a second unknown-key then you are increasing the
recipient's burden to obtain that unknown-key in the same amount as the
attacker's, irrespective of DES,
3. you are working only in plaintext recognition, where the most effective
attackers (NSA, for example) excel.
That is mainly why I said that if the plaintext is encrypted with an
unknown-key (the choice I am considering) then the intended recipient will
gain less in comparison to the attacker. I hope it si clearer.
> [snip]
> > 1. That is not what WA says -- it is the amount of secret-key that is
> > controlled. And, M-DES only defines a secret-key that is 56-bit wide Please
> > read the WA.
>
> I think I was clear that I was describing US export law.
Still, ditto as I wrote. The M-DES method complies to the published US
regulations -- and shows how impossible it is to try to control
cipher-strength just by controlling bit-lengths. It further shows that you
can't really ban secure ciphers because you cannot control what the other
side ignores but may find much sooner than the attacker -- the unknown-key.
>If you really want
> your 56-bit algorithm to be strong,
It is really negatively surprising to see you mention "If you really want
your 56-bit algorithm to be strong, " when the algorith is 70-bit strong and
NOTHING that you or anyone else have said so far has decreased the proposal's
security! So, your phrase is empty. What is your objective, to pass through
with a previoulsy denied qualification? BZZT!
For a productive discussion, please first acknowledge what has been
established -- not invent what has even been denied. The presented M-DES
cipher is secure for 70-bits and so I have proven publicly -- you cannot name
one weakeness (of course, if you follow what is in the paper). And, the paper
discusses how it can be secure to 120-bits or even more. These are the points
in discussion.
And, mind you, with one 56-bit DES encryption per block. Not three.
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Wed, 03 Feb 1999 13:38:32 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Metaphysics Of Randomness
Patrick Juola wrote:
> In article <[EMAIL PROTECTED]>,
> R. Knauer <[EMAIL PROTECTED]> wrote:
> >On Sat, 30 Jan 1999 22:11:25 -0500, "Trevor Jackson, III"
> ><[EMAIL PROTECTED]> wrote:
> >
> >>Look, equiprobable means equal probabilities. I.e., a flat distribution. It has
> >>nothing to do with indeterminacy. The technical term you want is independence.
>The
> >>individual samples have to be independent. This process gives you the
>indeterminacy
> >>that you are looking for.
> >
> >>The equiprobable criteria is trivial to meet. The
> >>indeterminact/independence/unpredicability criteria is the hard part. So
>concentrate
> >>on it.
> >
> >I am.
> >
> >The terminology employed in the definition of the TRNG came from
> >experts in the field of crypto right here in sci.crypt. It is their
> >definition, not mine. And that definition has passed the test of time
> >here, where those crypto experts are present. Not one of them has
> >raised any sort of objection like you have.
>
> It's the same scoping error that you were making earlier.
>
> The N-bit LFSR will indeed output all N-bit strings equiprobably
> if suitably coerced. However, that's not sufficient. The whole
> point of the OTP definition proposed was *NOT* that for a single
> length, all N-bit strings would be equiprobable, but for *any*
> length, all strings of that length would be equiprobable.
>
> So the N-bit LFSR will *NOT* output all 2N-bit strings equiprobably,
> and in fact, will only output one possible 2^(N) bit string. Similarly,
> the string 01010101010101010101... will output all possible 1-bit strings
> equiprobably but not all 2-bit strings, and hence isn't allowed.
>
> So independence comes out "for free" when you apply the equiprobability
> criterion correctly.
While I agree with your premises and conclusion, the actual problem statement to which
I
was replying had a limit on the string length; "for a string of length N" or something
similar. In fact, a simple counter of width log(N) will do exactly the same thing,
ie.,
produce each number with probability one, and then, of course, repeat.
The central point is that the fundamental aspect of crypto randomness is
unpredictability
or independence of the bits in the key/number/pad. Given that fundamental one can
massage
the raw bitstream to produce any desired distribution shape, and a flat one is trivial.
Lacking that quality (entropy if you will) makes it impossible to massage the
bitstream to
induce it.
Thus characteriszing equiprobability as the fundamental property is misleading. This
can
be considered a terminology issue, but I believe it to be central to much of the
confusion
regarding the definition of "random" as used in cryptology.
------------------------------
From: [EMAIL PROTECTED] (Albert P. Belle Isle)
Subject: Re: Crypt Info ????
Date: Wed, 03 Feb 1999 18:05:45 GMT
Reply-To: [EMAIL PROTECTED]
A fairly comprehensive set of links to web-pages dealing with Crypto
AG and other NSA cryptosystem-spiking rumors is Laszlo Baranyi's page
at
http://www.qainfo.se/~lb/crypto_ag.htm
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE
with Forensic Software Countermeasures
http://www.cerberus-sys.com/~infosec/
================================================
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random numbers generator and Pentium III
Date: Wed, 03 Feb 1999 18:54:07 GMT
Reply-To: [EMAIL PROTECTED]
On 1 Feb 1999 09:11:42 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>>You would not eat the mushrooms if the cook could not give a valid
>>reason for why he claims that they are not poisonous.
>Actually, you probably would.
Not me, dude. I did something stupid like that when I was a very young
child, and I learned my lesson at an early age.
Every late spring when the Gulf waters heat up in the Houston area,
the locals get food poisoning from raw oysters. When enough have come
into the area hospitals to get their stomachs pumped, the state
authorities issue a warning and finally forbid selling raw oysters.
You will never see me eat raw oysters in a month that has no 'r' in it
- and I am a raw oyster addict.
>Hell, a lot of people take herbal
>extract pills based on information a lot less reliable than the
>judgement of an "expert" in some particular field.
I assumed you were more intelligent than that. Are you saying that
your intelligence is just median? :-)
>Yes, and part of the reason that he's an expert is because his guesses
>are usually correct.
"Usually" is not good enough with things that have known ill effects,
like hand picked mushrooms.
Bob Knauer
"Sometimes it is said that man cannot be trusted with the government
of himself. Can he, then, be trusted with the government of others?"
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: What is left to invent?
Date: Wed, 03 Feb 1999 17:46:47 GMT
[EMAIL PROTECTED] (R. Knauer) wrote, in part:
>On Tue, 2 Feb 1999 18:03:40 +0000, Toby Kelsey
><[EMAIL PROTECTED]> wrote:
>>If decryptions form plausible messages with probability greater than
>>2^-k, where k is the keylength,
>I do not recall that you ever mentioned that these decryptions are
>formed from compressed plaintext - as you disclosed below.
An encryption method can include "compression"-type steps anyways. For
example, the straddling checkerboard is a bit like a Huffman code.
>I do not find your assumption so simple in general, even now that I
>know that compression was involved.
His conclusion is true: that's what unicity distance is about.
>>Since the proportion of plausible messages in random strings is less
>>than this, this requires decryptions to be biased towards plausible
>>messages. None of the jargon about unicity distance precludes this.
>I do not accept that offhand. The total algorithm, compression plus
>encyption, could be treated as one encryption system, in which case
>there is only one intelligible plaintext if the plaintext length is
>greater than the unicity distance.
You're right that the original formulae concerning unicity distance
aren't falsified - they're accurate. But what he has said seems
correct as well, being in accordance with the unicity distance
formula.
Just what _is_ going on here?
Let the key size be k bits.
Let the length of the encrypted message be N bits.
Will decryptions of an N bit encrypted message form plausible messages
with probability greater than 1 chance in 2^k? If so, decryption is
ambiguous if the key is unknown, so N is less than the unicity
distance.
Well, the unicity distance *does* count.
Because the *probability that a decryption will form a plausible
message* depends on N. (Compression, if present, simply means the
plaintext language has a different kappa.)
So, if he was claiming that only the key size matters, he is wrong.
The longer the message, the slimmer the chance is that a decryption of
it with a wrong key will be plausible...
from beginning to end.
But the formula he is giving is correct in itself.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: The Folger Manuscript
Date: Wed, 03 Feb 1999 07:43:42 -0800
J.W. wrote:
> Does anybody know how the Folger Manuscript is decoded. I have a bonus
> Crypto project that has page 21. If there is anyone who can give me
> clues as to how to break it I would greatly appreciate it.
"The Folger Manuscript" is ambiguous -- The Folger has a great many
manuscripts, including one that the Oxfordians think supports their
case against Shakespeare. There's also an American Masonic document
in cipher, I think by somebody named Folger (no relation to the museum),
that was the subject of the eponymous book by S. Brent Morris. I haven't
seen that document or Morris's book.
Want to scan your "page 21" and put it on a web site somewhere? Not
that anybody here would help you with the homework! :)
--
Jim Gillogly
13 Solmath S.R. 1999, 15:38
12.19.5.16.8, 2 Lamat 1 Pax, Fourth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: hardRandNumbGen
Date: Wed, 03 Feb 1999 18:28:37 GMT
Reply-To: [EMAIL PROTECTED]
On 1 Feb 1999 08:55:04 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>>Then you accept bad generators and reject good ones.
>Absolutely. With a particular, known, measured probability.
I am not as concerned about rejecting good TRNGs as accepting bad
RNGs, although you aren't gonna do a lot of OTP encryption when your
tests keep rejecting good TRNGs all the time. And your tests will
eventually reject every TRNG you test long enough (I assume correctly
that will sumbit your RNG to tests periodically).
The specification for the OTP does not permit accepting bad RNGs with
any statistical measure that yields a probability other than zero.
>Statisticians call these Type I and Type II errors. The trick is
>to make the cost of those errors as small as possible while still
>keeping testing costs under control.
"Small as possible" is not small enough for the OTP. The probability
for accepting a bad RNG must be zero.
For example, earlier you criticized rejecting the sequence 000...0 for
use as a complete pad on the basis that it would permit the
cryptanalyst to rule out one possible decryption, and yet that string
would certainly be cause for rejecting all TRNGs that produced it,
based on statistical tests.
Bob Knauer
"Sometimes it is said that man cannot be trusted with the government
of himself. Can he, then, be trusted with the government of others?"
--Thomas Jefferson
------------------------------
From: Vektor <"vektor_"@hotmail.com(orsoyouthink!)>
Subject: Re: [question/challenge/HELP ME! IEE!] Another unheard of punk who thinks hes
come up with something new...
Date: Wed, 03 Feb 1999 14:15:31 -0500
Cuykens Anthony wrote:
>
> Vektor,
>
> I think that it was a good idea not to post the code because it would be
> not relevant in a first time. What I think could be of some use is the method
> explained in more details. Could you make a description of all the operations
> that are performed to convert plain text into cipher text?
>
> Thank,
>
> Vektor wrote:
>
...snipsnipsnip...
>
> --
> Anthony Cuykens
> Architecture & Cryptography,
> Research & Development,
> PROTON WORLD International
oh...ok :)
the RandomKey is split up, and the first 9 byte values are broken up
into 4 different seed values (unless there is less than 9 bytes, in
which case the seeds are assigned in a different manner, depending on
the len of the key).
the seeds are then checked, to make sure there are no duplicates (i
found that duplicate seeds generated some undesired results in later
steps) and then, in a loop, they are multiplied, XORed, and MODed
together, to generate 400 extremely large numbers in the range of 0 to
3685477.
These 400 numbers are put into an array, and first 256 unique numbers
are put into a RndTable. The RndTable is copied, the RndTable is sorted,
then the distance the numbers moved from being sorted, from thier
original position, yields 0-255 in a fairly random order.
The new MRND function uses a counter, and each time you call it, returns
the next pseuodo-random number from RndTable. MRandomize simply sets the
counter to NewSeed mod 256.
the encrypttable (which is a 1x256x256 array) is assigned, in a loop,
using MRnd, with MRandomize (randomkey(x mod len(randomkey)) being
called at each different 256 array, and Mrandomize Mrnd being called at
the 0 and 1 arrays (ie. different starting points for the 2 256x256
arrays)
the decrypttable is created by using the encrypttable, so that we can
decipher the random garbage that will be our message.
To actually encrypt, heres all it goes through :
previousbyte, and bytebeforelast are initialize to encryptkey(mrnd mod
len(encryptkey)). then, in a loop, the current bytetoencrypt is ran
through the table in
EncryptTable(ByteBeforeLast and 1,Previousbyte,CurrentByte), where
bytebeforelast, and previous byte, are the -encrypted- values of those
bytes. before being put in the result string, the character is XORed
with encryptkey(x mod len(encryptkey)).
there is some small pattern checking code, to make sure that repetetive
characters or patterns in the plaintext dont exhibit any noticable
patterns in the encrypted stream.
this process is reveresed, using DecryptTable, to decrypt the text.
a change in the random key results in the RndTable being changed, and
new Encrypt and Decrypt tables being generated.
a change in the encrypt key results in just new encrypt and decrypt
tables being generated.
from what i've experimented with...there is no pattern of any kind (that
i can see) in the resulting cipher. The encoded plaintext can only be
decrypted if you have both the RndTable it was generated with, and the
Encryptkey that was used to create the encryption tables.
I believe the only way to get the RndTable, is to generate it using the
RandomKey. to try and brute force it would be just silly. and without
the RndTable, the encoded message is nothing but a series of random
numbers.
...
well...there it is. comments are always welcomed :)
------------------------------
From: [EMAIL PROTECTED] (Dan S. Camper)
Subject: Re: RNG Product Feature Poll
Date: Wed, 03 Feb 1999 13:10:28 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
>>1) Don't add a hash. (This is the easy one!)
>
>The best idea. If we don't trust you, and imagine that these hardware
>random numbers are "really" generated by some tricky NSA stream cipher
>that will let them guess all our session keys, we can hash those
>random bits ourselves to be on the safe side.
>
>Obviously, if we don't trust your random bits, we won't trust your
>hash.
>
>And why would anyone be using encryption, if he wasn't already
>paranoid? :)
Would it then be detrimental to add a hash/CRC function as an _option_ in
the product's software, with a published API allowing you to substitute
your own function if you choose? You can enable, disable and/or
substitute your own algorithm as you wish, and it would leave the device's
output in a "raw" form.
Just seeking clarification.
DSC
____________________________________________________________________
Dan S. Camper [EMAIL PROTECTED]
Borrowed Time, Inc.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: The Folger Manuscript
Date: Wed, 03 Feb 1999 11:28:15 -0800
Reply-To: [EMAIL PROTECTED]
J.W. wrote:
> Here is the page 21 for you to look at.
>
> Jim Gillogly wrote:
> > Want to scan your "page 21" and put it on a web site somewhere? Not
> > that anybody here would help you with the homework! :)
> Name: folger.tif
> folger.tif Type: TIFF Image (image/tiff)
> Encoding: base64
800K file snipped.
Err, no, I suggested you put it on a web site somewhere. Posting large
binaries to text-based Usenet groups is strongly discouraged. Also, you
might consider changing to a GIF format -- the same picture with no loss
is about 1/3 the size as a GIF.
The text next to it says it's monoalphabetic substitution, so you might
want to read Poe's "The Gold Bug" to see how to start. Step one is
assigning each of the hieroglyphics to a more legible character, then
doing a frequency count to see which symbols are used most often.
Step 2 is looking for entries: the author of the page (S. Brent Morris)
gives you some cribs to look for, so you should see whether the patterns
of those cribs appear in the characters you've transcribed.
--
Jim Gillogly
13 Solmath S.R. 1999, 19:22
12.19.5.16.8, 2 Lamat 1 Pax, Fourth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: RNG Product Feature Poll
Date: Wed, 03 Feb 1999 19:48:19 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 3 Feb 1999 18:01:35 GMT, [EMAIL PROTECTED] (Peter Pearson)
wrote:
>In 1955, the Rand Corporation published a book entitled "A Million
>Random Digits with 100,000 Normal Deviates," described at
>http://www.rand.org/publications/classics/randomdigits/.
>Today's online version doesn't mention radioactive decay, but I
>believe I recall that that was the basis for their "random frequency
>pulse source."
>
>So, don't let overbroad patent claims scare you....
A radioactive decay rate of 100,000 counts per second sounds a bit
high for 1955. At that high count rate they could have been measuring
the quench process in their detector instead of the actual radioactive
decay events.
Bob Knauer
"Sometimes it is said that man cannot be trusted with the government
of himself. Can he, then, be trusted with the government of others?"
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Encoding for telephone over Internet
Date: Wed, 03 Feb 1999 18:58:11 GMT
Reply-To: [EMAIL PROTECTED]
On 1 Feb 1999 09:17:06 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>>why do you you think that a real time communication doesnt need
>>as much security ?
>Because, as I stated below, most real-time communications don't need
>to stay secret as long. The interesting lifespan of the sort of data
>communicated by telephone is typically measured in hours or day. There's
>a reason that people don't "sign" contracts over the phone.
I think Clinton and Lewinsky might have something to challenge that
assertion. It was the taped conversations between Lewinski and Tripp
that got the whole thing going months after the tapes were recorded.
I realize that encryption would not have prevented the resulting
problems for Clinton, but the point is that some telephone
conversations can have a life expectency of importance longer than a
few weeks.
Bob Knauer
"Sometimes it is said that man cannot be trusted with the government
of himself. Can he, then, be trusted with the government of others?"
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The Folger Manuscript
Date: Wed, 03 Feb 1999 18:59:56 GMT
Jim Gillogly <[EMAIL PROTECTED]> wrote, in part:
>"The Folger Manuscript" is ambiguous --
And I thought it would contain the secret formula for how they kept
all the flavor in those coffee beans (something like the Cadbury
Telegram)...
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
** 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
******************************
