Cryptography-Digest Digest #101, Volume #13 Sun, 5 Nov 00 08:13:01 EST
Contents:
Re: Crypto Export Restrictions (Anthony Stephen Szopa)
Re: Give it up? (Scott Craver)
Re: ---- As I study Rinjdael... (David Formosa (aka ? the Platypus))
Re: Generalized Playfair (Mok-Kong Shen)
Re: hardware RNG's (Mok-Kong Shen)
Re: Microsoft's script encoder (Ichinin)
Re: BENNY AND THE MTB? (Bryan Olson)
Re: BENNY AND THE MTB? (Bryan Olson)
On obtaining randomness (Mok-Kong Shen)
Re: BENNY AND THE MTB? (Tim Tyler)
Re: BENNY AND THE MTB? (Tim Tyler)
Re: BENNY AND THE MTB? (Tim Tyler)
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: Sat, 04 Nov 2000 23:15:10 -0800
Scott Craver wrote:
>
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> >Scott Craver wrote:
> >>
> >> It's kind of someone else to work to translate your
> >> descriptions into real pseudocode, but the onus really
> >> is upon you to do this.
> >
> >The onus is on you: That is if you have the intelligence and energy
> >and interest.
>
> Uh, no, the onus is upon _you_, because it is _your_ product.
> Nor is the onus upon consumers to perform their own automobile
> crash tests.
>
> Without letting experts scrutinize your algorithm, you can not
> back up the single claim that your product is not a piece of
> worthless snake-oil. Your angry attitude, towards those who
> would help you scrutnize the algorithm, only reinforces the
> perception of Original Absolute Whatever as insecure.
>
> >If not: forget about it.
>
> Sorry, no can do. As long as you have that web site up
> peddling what appears to be snake oil, people have the
> responsibility to follow-up to your posts, and otherwise warn
> consumers that they should be using ciphers and PRNGs that have
> been thoroughly tested.
>
> Not to mention the performance issue of a piece of software
> requiring the user to do part of its calculations, using
> counters or playing cards. Nutty!
>
> -S
Like I said, if you do not have the intelligence and the energy and
the interest to read the Help Files and have all your questions
answered then just forget about it.
Don't you think you have wasted enough of your time already?
Since you have demonstrated that you will not even devote the time
and energy to read the Help Files you clearly don't know what you
are talking about regarding OAP-L3.
I think that even you have the intelligence to understand the
software. Like the old saying goes: "You can lead a horse to water
but cannot make him drink."
OAP-L3 encryption software requires true random user input. Proven
methods of generating truly random data is demonstrated in several
common gambling games. Believe me, these are proven random games.
People bet their life's savings on them. Trillions of dollars every
year are wagered on them.
Yet you know better than all these people around the world.
You forgot numbered beans shaken in a bottle and drawn out one by
one.
Yep. Obtaining pure golden random numbers sure is "nutty."
Anyone who uses encryption software that does not generate pure
random numbers is nutty if you ask me.
OAP-L3 requires true random number user input then generates pure
random numbers for encryption purposes.
But you say this is nutty.
You seem like perfect material to be hired by Bill Richardson at
the Dept. of Energy. He couldn't do any worse putting you in charge
of the Country's nuclear secrets.
Get a good night's sleep and just forget about it.
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Subject: Re: Give it up?
Date: 5 Nov 2000 07:15:47 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>
>Anyone who claims that it's easy [or even that it's possible] to make
>compressed output always be the same size or smaller than the input,
>clearly does not understand the counting argument.
The simplest possible compression scheme, that of doing nothing,
has exactly this property. Thus it is both possible and
incredibly easy.
I hope you don't consider this a smart-assed reply. Rather,
it is important to be precise when invoking mathematics.
"The counting argument" only implies that it is impossible
to make |compress(x)| <= |x| for all x under a stricter
condition, namely the condition that |compress(x)| < |x|
for at least one x. For a lossless scheme. Thus, yes, any
_nontrivial_ lossless compression scheme does have the
property that |compress(x)| > |x| for some x.
On the other hand, there are perfectly practical ways to
avoid this. If a compression scheme consists of outputting
compress(x) if |compress(x)|<|x|, and just x otherwise,
then the output of the algorithm is always the same size or
smaller than the input. It is no longer deterministic, as
decompression consists of converting y to the pair {y,
decompress(y)} of which one answer is correct; however, it
strains the definition to call this lossy, as the original
is always retrieved.
I call this practical because people do it all the time,
namely, compress a file, find that it gets fatter, figure
"ah, what the Hell" and send the original.
>If one is compressing and encrypting in one program, one might choose to
>have headers, so the type of file can be identified, but not encrypt
>them.
Realistically, file type identification should be considered
separate from the file itself. On some OSs it is a separate
entity, or simply derived from the file's name. This is
usually a separate issue from, say, a WAV header. My OSs
will keep track of the fact that a file is a WAV even if
the WAV header is stripped away or compressed/encrypted.
Further, those kinds of headers contain way more information
than you need to identify the file type.
By the way, some file systems possess elaborate attribute
systems, so that not only a file's date, time, name etc are
stored as separate attributes from the file, but also other
bits of the file's data. In BeOS, for instance, the notepad-
type application stores all font and color information in
a text file's attributes, which allows you to cat the file
in Unix and get just the plain ASCII text. I _love_ that
feature. Unfortunately, if I'm dumb enough to encrypt a
file whose attributes contain real information....
-S
------------------------------
From: [EMAIL PROTECTED] (David Formosa (aka ? the Platypus))
Subject: Re: ---- As I study Rinjdael...
Reply-To: [EMAIL PROTECTED]
Date: Sun, 05 Nov 2000 08:19:01 GMT
On Sun, 22 Oct 2000 19:08:10 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
[...]
>I am not aware that the US government 'chooses' not to use
>Rijndael for any classified information. Why should it tell
>you what it uses to encrypt classified information? By
>definition, classified information doesn't concern you
>as normal citizen at all. (You are not supposed to care
>about it.)
What about census records and tax infomation that is my private data
held in trust bu the goverment. The privacy of such things concerns
me.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Generalized Playfair
Date: Sun, 05 Nov 2000 10:53:28 +0100
"r.e.s." wrote:
>
[snip]
>
> (4) Encipher one group at a time, treating it as a circular
> sequence of overlapping letter-pairs (e.g. for M=3, "abc"
> is seen as ab-bc-ca). Each letter of a group is enciphered
> as the first half of an ordinary Playfair digraph of which
> it is the first letter, while cycling through the M squares
> in succession.
Question: You are using multiple matrices, i.e. doing
sort of 'polyalphabetical substitution' (in contrast to
monoalphabetical substitution'). How does your method
compare to encrypt in the example above ab with the
first matrix as conventional Playfair to Ab' then b'c
with the second matrix again as conventional Playfair
to Bc', etc.?
[snip]
> Further generalizing the above method to d-dimensional arrays
> of an alphabet, with d=1,2,3,..., is straightforward.
I am afraid that you'll get into some awesome difficulty
when you advance to above d=3, since one is leaving
the three-dimentional space that one can easily think of.
The purpose of Playfair is to have a compact (special)
substitution scheme as compared to a general substitution
that demands too much storage space. Advancing to d>2 would
lead to increasingly more compact schemes. But I suppose
that for practical purposes d=2 is good enough.
[snip]
> Yet another variation of this generalized Playfair would be
> to *not* cycle back to the first letter of each group, but
> instead to treat the entire plaintext string as a sequence of
> overlapping letter-pairs, with the first letter regarded as
> following the last letter of the message. (And still cycling
> through the M squares in succession as before.)
I don't yet understand this. Previously you said to
process like ab bc ca. But this IS 'overlapping and with
the first letter regarded as following the last letter',
isn't it?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: Sun, 05 Nov 2000 10:53:33 +0100
Dido Sevilla wrote:
>
[snip]
> People say it's not that simple to make a hardware RNG. Maybe so if
> you're going to use it to generate numbers for a national lottery or
> some other application where mathematically provable randomness is your
> goal. But for cryptography, I think it should be enough for a hardware
> RNG to be reasonably unbiased and impervious to manipulation and
> monitoring by malicious entities. If an attacker can't actually bias
> the RNG in a useful way, or read the values it produces, then I guess
> that the RNG will not be a source of security problems. Of course, such
> raw random bits must be decorrelated and it would be far preferable to
> use the random bits only to seed a PRNG rather than be directly used.
A good way I suppose is to xor the hardware stream with
a stream from a statistically very good PRNG.
M. K. Shen
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Microsoft's script encoder
Date: Sat, 04 Nov 2000 16:54:49 +0100
Richard Heathfield wrote:
> You probably can't learn how it works, because reverse-engineering it
> probably contravenes the terms of your licence agreement.
Except where such license agreements are nullified by law...
/Ichinin
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
Date: Sun, 05 Nov 2000 09:59:54 GMT
Tim Tyler wrote:
> Bryan Olson <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote
> :> Bryan Olson <[EMAIL PROTECTED]> wrote:
> :> : Tim Tyler wrote
> :> :> [EMAIL PROTECTED] wrote:
>
> :> :> : The argument is fairly simple. If you chop all but 8-bits of
> :> :> : a Rijndael block, the decryption is one of 2^120
possibilities. []
> :> :>
> :> :> [...] your premise is wrong - Matt does *not* "chop all but 8
bits"
> :> :> from a Rijndael block.
> :>
> :> : Though in the case in Dave's story, that is what the program did.
> :>
> :> I don't /think/ so [...]
>
> : If the program outputs a one byte message, then it did in
> : fact take just the first byte of the Rijndael block.
>
> That's completely different from "chop[ing] all but 8-bits [from]
> a Rijndael block" such that "the decryption is one of 2^120
> possibilities".
>
> What you are now talking about has nothing to do with what
> Joseph Ashwood was talking about.
Not true. David faked the example to make the ciphertext
come out as one byte. (He chose the ciphertext, then came
up with the plaintext message. He states the story the
other way, as if the ciphertext was derived from the
plaintext as usual.) He also presents the one-byte
plaintext as if it were a typical case; there's no hint
of surprise at a 1/2^120 shot.
Joseph Ashwood correctly concluded that the story is
nonsense, since if the system typically produces one-byte
plaintexts, one would have no way of knowning which of
2^120 blocks to give to Rijndael. I had a somewhat
different take; I said it's nonsense because it depends
on hitting a 1 in 2^120 shot. Not knowing which of 2^120
possibilities to use is basically the same problem as
depending on a 1/2^120 chance.
> It's not even clear to me that your statement is true.
> There are *many* mapping between blocks and 8-bit granular
> files, which would not fit your description. Do you know
> which map is actually being employed?
Yes, and it is not a bijection between blocks and 8-bit
granular files. It is between finitely odd bit streams and
8-bit granular files. Nevertheless, if the ciphertext is one
byte, then that byte is the first byte of sole Rijndael block
XOR 0x55. (For some reason the program XOR's every byte with
0x55 which is irrelevant to the bijection.)
> :> It may be that David told about the decryptors /expecting/
> :> the program to behave in the way you mention - after
> :> hearing it used Rijndael.
>
> : He definitely stated the ciphertext was one byte. That's
> : a 1 in 2^120 shot to happen the way the story tells it.
> : If you don't beleive me [...]
>
> I believe you - but that wasn't my objection in the first place.
I guess I don't understand what your statement "It may be
that David told..." is getting at.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
Date: Sun, 05 Nov 2000 10:25:33 GMT
Tim Tyler wrote:
> Matt Timmermans wrote:
>
> : Because final mapping (tivial decoding) from FOstreams
> : to byte-granular files is bijective, the encryption can
> : perform any reversible operation on the FOstream without
> : changing the bijective nature of the entire process,
> : including operations that change the number of significant
> : bits.
>
> I think this is what I didn't grasp. It's obvious, really ;-)
But subtle. I had to sketch a proof to convince myself the
encryption is bijective on finitely odd streams. A key point
is that for streams of more than 128 (significant) bits, the
transformation preserves the (significant) bit length. For
streams of 128 or fewer significant bits, it's not length
preserving but will never map to a stream of more than 128
(significant) bits. Thus we can separately show it's
bijective on the set of <=128-bit FO streams, and bijective
on the set of >128-bit FO streams.
> One remaining issue seems to be that you can't be encrypting
> 0x00000000 -
> so one cyphertext will go missing (unless you are careful).
> Also what happens if you encrypt to 0x00000000 (not a FO file)?
The name "finitely odd" and the comments in the code may be
misleading. All zeros is a finitely odd bit stream.
"Finitely odd" means "not infinitely odd".
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: On obtaining randomness
Date: Sun, 05 Nov 2000 12:22:16 +0100
According to the British Museum model, given sufficient
time, monkeys at keyboard could eventually produce all
the works in the literature collection there. So
evidently there is enough entropy present in the numerous
volumes written by humans to be found in the libraries.
To obtain therefore randomness, one could use a
sufficiently long secret key to determine a (not trivially
small) set of books (the possibility is enormous),
compress them, interleave the resulting sequences by small
units (e.g. 32-bit groups), schuffle these (see Knuth,
vol. 2) and hash the result with an appropriate algorithm.
Wouldn't that give pseudo-random bit sequences that are
unpredicatable by the mightiest opponent of the world
before he manages to become an equal of God through
perhaps inventing a yet superior theory than the quantum
mechanics?
Note that the upcoming of e-books renders the task more
convenient. Digitalized music and paintings, which are
also within the realm of reproduction by the honourable
sirs of the British Museum, could analogously be
employed.
M. K. Shen
===============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 5 Nov 2000 12:19:34 GMT
Bryan Olson <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Bryan Olson <[EMAIL PROTECTED]> wrote:
:> : Tim Tyler wrote
:> :> Bryan Olson <[EMAIL PROTECTED]> wrote:
:> :> : Tim Tyler wrote
:> :> :> [EMAIL PROTECTED] wrote:
:> :> :> : The argument is fairly simple. If you chop all but 8-bits of
:> :> :> : a Rijndael block, the decryption is one of 2^120
:> :> :> : possibilities. []
:> :> :>
:> :> :> [...] your premise is wrong - Matt does *not* "chop all but 8
:> :> :> bits" from a Rijndael block.
:> :>
:> :> : Though in the case in Dave's story, that is what the program did.
:> :>
:> :> I don't /think/ so [...]
:>
:> : If the program outputs a one byte message, then it did in
:> : fact take just the first byte of the Rijndael block.
:>
:> That's completely different from "chop[ing] all but 8-bits [from]
:> a Rijndael block" such that "the decryption is one of 2^120
:> possibilities".
:>
:> What you are now talking about has nothing to do with what
:> Joseph Ashwood was talking about.
: Not true. [...]
I think it's true. How else can you eplain that he stated that the
decryption of the cyphertext is one of 2^120 blocks? Joseph was
discussing a system that no-one ever proposed - and which would not work.
: David faked the example to make the ciphertext come out as one byte.
I wouldn't dispute that - but that seems to have nothing to do with what
we're discussing.
: Joseph Ashwood correctly concluded that the story is
: nonsense, since if the system typically produces one-byte
: plaintexts, one would have no way of knowning which of
: 2^120 blocks to give to Rijndael.
Your numbers appear to be faulty. If the system produces one byte
cyphertexts (which it does), there's only 256 blocks to give Rijndael that
produce this result (under a given key) - and Joseph's statement was based
on a misunderstanding of how the system worked.
The 2^120 figure comes from a non-existent system, which is not the one
under discussion.
: I had a somewhat different take; I said it's nonsense because it depends
: on hitting a 1 in 2^120 shot.
Your statement has much truth in it. Joseph's was based on a
misunderstanding of the system (which I believe he has now come to grips
with).
You seemed to be agreeing with Joseph by writing "though in the case in
Dave's story, that is what the program did." - but Joseph's story was
based on a misunderstanding of what the program did - and does not make
sense in the light of its actual operation.
:> It's not even clear to me that your statement is true.
:> There are *many* mapping between blocks and 8-bit granular
:> files, which would not fit your description. Do you know
:> which map is actually being employed?
: Yes, and it is not a bijection between blocks and 8-bit
: granular files. It is between finitely odd bit streams and
: 8-bit granular files.
You are correct - my mis-statement.
: Nevertheless, if the ciphertext is one byte, then that byte is the
: first byte of sole Rijndael block XOR 0x55. [...]
Aha! ;-)
[snip rest]
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Niagra falls.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 5 Nov 2000 12:27:43 GMT
Bryan Olson <[EMAIL PROTECTED]> wrote something like:
: Tim Tyler wrote:
:> One remaining issue seems to be that you can't be encrypting
:> 0x00000000 - so one cyphertext will go missing (unless you are
:> careful). Also what happens if you encrypt to 0x00000000 (not a FO
:> file)?
: All zeros is a finitely odd bit stream.
Is it? Oh.
: The name "finitely odd" and the comments in the code may be misleading.
I think you're right - I will probably not be the last person to
get confused over how such an "even"-looking file can be "odd".
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Free gift.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 5 Nov 2000 12:31:26 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
:>One remaining issue seems to be that you can't be encrypting 0x00000000
:>- so one cyphertext will go missing (unless you are careful). Also what
:>happens if you encrypt to 0x00000000 (not a FO file)?
: Actaully he can be encrypting that. YOu are confusing normal
: 8-bit files with fintiely odd files. [...]
I wasn't doing that - but I didn't realise 0x00000000 counted as a FO file.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Surf against sewage.
------------------------------
** 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
******************************
