Cryptography-Digest Digest #710, Volume #13 Sun, 18 Feb 01 14:13:01 EST
Contents:
Re: Key expansion. (Ichinin)
Re: Key expansion. ("Vinchenzo")
Metallurgy and Cryptography ("Tad Johnson")
Re: Ciphile Software: Why .EXE files so large (Sundial Services)
Re: Reverse encoding question (David Hopwood)
Re: My encryption system..... (Paul Crowley)
A remark on polyalphabetical substitutions (Mok-Kong Shen)
Re: [release] OutGuess 0.2 - steganographic tool (Mok-Kong Shen)
Re: "Shuffled ARC4" revisited ("Scott Fluhrer")
Re: Most secure code for US Citizen. ("Trevor L. Jackson, III")
Re: "Shuffled ARC4" revisited ("Douglas A. Gwyn")
Re: is "randomness" an information source? ("Trevor L. Jackson, III")
Re: "Shuffled ARC4" revisited ("Trevor L. Jackson, III")
Re: National Security Nightmare? ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Key expansion.
Date: Thu, 15 Feb 2001 17:21:38 +0100
Cristiano wrote:
>
> I have a password constituted from few characters and I want to expand it
> (to at least 128 bits) for use it like session (secret) key for an algorithm
> to symmetrical key (e.g. rijndael).
> How could I do?
>
> Cristiano
Why expand it? Run it through a one way hash algorithm.
/ichinin
------------------------------
From: "Vinchenzo" <[EMAIL PROTECTED]>
Subject: Re: Key expansion.
Date: Sun, 18 Feb 2001 09:41:16 -0500
Use hashing algorithm like MD5 (128bits) or SHA-1 (160bits). These algos
will convert a variable length text to a fixed digest (of sizes mentionned
above). This digest has 2 characteristics: you can't recover the original
password with it and it is relatively unique to the hashed string (if you
change only one character, the whole 128 bits will change). Normally, for
symmetrical key encryption, it is recommended to use a random x-bits key to
encrypt the message and append to the cipher encryption of your random key
with the hash of your password.
Vincent
"Cristiano" <[EMAIL PROTECTED]> a écrit dans le message news:
96obi3$86m$[EMAIL PROTECTED]
> I have a password constituted from few characters and I want to expand it
> (to at least 128 bits) for use it like session (secret) key for an
algorithm
> to symmetrical key (e.g. rijndael).
> How could I do?
>
> Cristiano
>
>
------------------------------
From: "Tad Johnson" <[EMAIL PROTECTED]>
Subject: Metallurgy and Cryptography
Date: Sun, 18 Feb 2001 10:09:38 -0500
Hello All ---
I just realized something:
Don COPPERsmith...
Bob SILVERman...
Benjamin GOLDberg...
What the heck is going on here?
------------------------------
Date: Sun, 18 Feb 2001 08:44:51 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Ciphile Software: Why .EXE files so large
VB is simply an excruciatingly bad interpreter.
Usually, crypto primitives ARE written with optimizing compilers, with
some assembly for the heavy-duty bit-twiddling. But a DECENT
interpreter could certainly manage the job, at least for low-volume
encryption.
>Paul Crowley wrote:
>
> "Michael Brown" <[EMAIL PROTECTED]> writes:
> > Isn't it effectively interpreted? I've never used Python, but after seeing
> > the shocking performance of VB when you try to do anything fast I have a
> > great suspicion of interpreted languages.
>
> Yes. From a performance point of view, Python would be a bad language
> to implement, say, Rijndael in.
>
--
==================================================================
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED] (PGP public key available.)
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R): "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/products/chimneysweep
------------------------------
Date: Sun, 18 Feb 2001 16:24:50 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Reverse encoding question
=====BEGIN PGP SIGNED MESSAGE=====
"Michael J. Fromberger" wrote:
> In general, if E is a symmetric cipher with decryption rule D, if you
> have C = Ek(X), and you know C and k, you can easily compute:
>
> Y = Dk(X)
>
> Encrypting Y with key k will result in X, i.e., Ek(Y) = X. This
> should work for any symmetric cipher.
More precisely, it works for any deterministic symmetric cipher.
In the case of a chaining mode with an IV (like CBC, which was what
the original poster asked), it works provided the IV can be chosen.
For a completely general symmetric cipher, though, it is not necessarily
possible to determine the coins (random input) for the encryption
function that, together with the plaintext, will produce a given
ciphertext. For example, suppose a scheme used CBC mode but with the
IV generated as a one-way hash of a random value R; it would not be
possible to find a valid R given just the key and ciphertext.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOo8piDkCAxeYt5gVAQHasQf+P8vo+0iZ+/snPSgMvuMc+DRgjdAiT32v
EQSFnuRc6dsHC3m6Bb1ylLeSKAzVoKgND3HNrrQhFu48LLhIetSsbUgg0yzQfo6J
SkcA+WvIWA9uKERBWz1xQF4kGr8jC0yoYkZgJMaVGIfvnNl35PStM6ldxEd4aBOg
LcZNlPypcE6K9Mq+VsEJJapNwD5jSojeIr6S6ATuedtch1BwrV7EgIGqkYfxc+ew
zHf01g+p6YvsoavnYGTC+6+dFe8NpVFQ07ZVuUbLgIMyTPHbhatbvELt8DrLUxZ7
J26VOV/DTWFHlQZnuk17oMupiO7i9edRJWjkZzrmlbKpz+ogPNZdgQ==
=2YFO
=====END PGP SIGNATURE=====
------------------------------
Subject: Re: My encryption system.....
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Sun, 18 Feb 2001 17:40:48 GMT
Keill_Randor <[EMAIL PROTECTED]> writes:
> It seems that you are all ignoring my challenge.. Oh well...
Read Bruce Schneier's "Memo to the Amateur Cryptographer".
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: A remark on polyalphabetical substitutions
Date: Sun, 18 Feb 2001 19:14:36 +0100
[ The following tiny remark is trivial in theory but seems
nevertheless to be of a little bit practical utility. ]
A polyalphabetical substitution commonly employs a table,
i.e. a n*m matrix, where each column (s-box) is a (in general
arbitrary) permutation of the alphabet of n symbols. It
is generally favourable to have a large value of m and one
can use a PRNG to generate a keystream to select the
columns to do the substitutions. However, for e.g. n=256,
which corresponds to 8-bit bytes, having very large m would
readily lead to huge storage requirements which can be
undesirable or even infeasible.
Given a n*m substitution table, can one turn it into
a n*m' table, with m' much larger than m, without changing
the storage space? This bizzare sounding question turns
out to be able to be answered affirmatively in a certain
practically useful sense. (Evidently, this can't be in
an 'exact absolute' sense, which is not always necessary
in practice.) As some little reflections will show,
there are namely two simple ways to realize from a (real)
n*m table a larger 'effective' virtual n*m' table, both
incurring certain trade-off in efficiency, understandably.
The one is to use a pair of columns to substitute twice.
For this concatenation of two substitutions leads in
general to a substitution that is different from any that
is represented by a column in the (real) n*m table. (We
assume that the columns in the n*m table are 'independent
alphabets', i.e. arbitrary permutations of n elements of
the input alphabet). To do that, one needs two (instead
of one) key-symbols to select the two columns concerned
from the (real) n*m table. The other is to use each column
as the first column of a virtual n*n Vigenere table, with
the remaining n-1 virtual (not physically existing) columns
being the circularly shifted versions of the said first
column. Here one needs one key-symbol to select a column
from the (real) n*m table as usual (which serves as the
first column of the virtual Vigenere table) and one
numerical value in 0..(n-1) to be employed as the offset
for computation, or equivalently for selecting the column
of the virtual Vigenere table for performing the
substitution. Note that in both cases the volume (or the
number) of keystream utilized is enhanced and that the
two methods may be combined.
M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: [release] OutGuess 0.2 - steganographic tool
Date: Sun, 18 Feb 2001 19:14:29 +0100
Niels Provos wrote:
>
> OutGuess is a universal steganographic tool that allows the insertion
> of hidden information into the redundant bits of data sources. It
> is undetectable by known statistical tests and provides for plausible
> deniability.
[snip]
> OutGuess modifies the least-significant bits of the quantized DCT
> coefficients in case of the JPEG format. While some people view this
> as simple and primitive, it allows OutGuess to preserve statistics
> based on frequency counts. As a result, no known statistical test is
> able to detect the presence of steganographic content. Before
> embedding data into an image, OutGuess can determine the maximum
> message size that can be hidden while still being able to maintain
> statistics based on frequency counts.
The principle of modification of Fourier coeffients is known.
But could you tell something about the novel ideas in your
scheme concerning statistics? Thanks in advance.
M. K. Shen
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: "Shuffled ARC4" revisited
Date: Sun, 18 Feb 2001 10:18:41 -0800
r.e.s. <[EMAIL PROTECTED]> wrote in message
news:96o5eo$kku$[EMAIL PROTECTED]...
> "Scott Fluhrer" <[EMAIL PROTECTED]> wrote ...
> | r.e.s. <[EMAIL PROTECTED]> wrote ...
> | > In a previous posting I asked about the possibility of
> | > strengthening ARC4 by simply applying a pseudorandom
> | > shuffle to its output in, say, blocks of N bytes.
> | What attack are you proposing the strengthen ARC4 against? I know
> of no
> | published key recovery attack that is an improvement over brute
> force. And,
> | periodically shuffling the array will not strengthen ARC4 against
> the best
> | known distinguishing attack.
>
> For any stream cipher, it seems to be a potential weakness
> that each encrypted byte can be matched to the corresponding
> byte of known plaintext. My pedestrian thinking is that an
> opponent might discover some exploitable properties of the
> stream cipher -- properties of ARC4'S state evolution, say --
> and since plaintext and ciphertext bytes are readily matched,
> there is then nothing to deter that exploitation. It seems
> reasonable to consider hardening against even such abstractly
> conceived threats.
I see. You are postulating a hypothetical weakness, and making a random
change in hopes that the revised cipher will be stronger, rather than
weaker, against that hypothetical weakness.
Since the weakness is hypothetical, it appears rather difficult to evaluate
if this random change makes the cipher stronger against that specific
weakness, and especially difficult to evaluate if it strengthens the cipher
enough to make up for the additional execution time the revised cipher would
take.
Why do I harp on execution time? Because it is trivial to come up with
changes that appear to make the cipher more secure at the cost of time.
Then, the question becomes, given that you have decided to make this cipher
more secure, then is this change a reasonably efficient way to do it?
>
> | > I had suggested using the ARC4 PRNG itself to produce
> | > Durstenfeld shuffling within each block, but there was
> | > an apparent consensus that ARC4's state space, though
> | > huge, is not adequate for this purpose.
> | >
> | > However, instead of Durstenfeld shuffles, suppose we
> | > use ARC4's state vector *directly* to shuffle the output
> | > within 256-byte blocks. E.g., let S be the ARC4 state
> | > vector after key-setup, let X be a 256-byte vector of
> | > ARC4-encrypted output, & let Y be the shuffled result.
> | >
> | > Then my question is whether the following simple byte-
> | > shuffling, performed on successive blocks, will indeed
> | > strengthen the cipher:
> | >
> | > for i = 0 to 255
> | > Y(i) = X( S(i) )
> | Your notation is a bit hard to follow, however, if the result of the
> shuffle
> | is not a permutation (which the above appears not to be), then ARC4
> gets
> | *much* weaker. ARC4 output bytes which are elements of the array,
> and so if
> | a byte does not appear in the array, it will never be output.
>
> The pseudocode above defines Y as a permutation of the
> elements of X, according to the permutation vector S.
> (S is the ARC4 state vector S(0)..S(255), which is some
> permutation of the 256 possible bytes). X is the vector
> X(0)..X(255) of 256 bytes of most-recently encrypted
> plaintext. Therefore Y(i) = X( S(i) ) (i=0..255) defines
> Y as the permutation of X specified by S.
>
> Here's an illustration: Suppose the alphabet were decimal,
> so that both S and X would have 10 elements, and write the
> vectors as strings. We might have S=4195326087
> (which is a permutation of 0123456789)
> and X=8803901729.
> Then Y=9890301827,
> which is the permutation of X specified by S.
--
poncho
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Reply-To: don't
Crossposted-To: talk.politics.crypto
Subject: Re: Most secure code for US Citizen.
Date: Sun, 18 Feb 2001 18:39:41 GMT
Sundial Services wrote:
> { Congress should be required to attend a class on law-making ... Pity
> the Founding Fathers never thought of that. }
What do you think elections are?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: "Shuffled ARC4" revisited
Date: Sun, 18 Feb 2001 18:53:03 GMT
"r.e.s." wrote:
> For any stream cipher, it seems to be a potential weakness
> that each encrypted byte can be matched to the corresponding
> byte of known plaintext.
That's not a general property of stream ciphers.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Reply-To: don't
Subject: Re: is "randomness" an information source?
Date: Sun, 18 Feb 2001 18:54:39 GMT
Daniel Ortmann wrote:
> I was told by someone that "randomness" in an information source, but that
> doesn't sound correct.
It's accurate. In that context "randomness" expresses the uncertainty of an
observer inspecting the output of the source. To the extent the output is
unpredictable it is random.
>
>
> Since he was talking about a "program" which he wrote which *used*
> randomness, it seems to me that he *himself* was the information source for
> the program. After all, he didn't write the program by throwing dice. And
> even if he did, the instant he would start "picking and choosing" which rolls
> to accept, HE would again become the information source.
>
> Can someone clear this up?
The program does not contain randomness, it manages/handles/massages/transforms
it. In the context of typical software the behavior of the program is completely
predictable (deterministic), but the data it handles may be completely
unpredictable (random). This code/data dualism implies a lack of familiarity
with computer science. Look there to eliminate any residual confusion.
>
>
> Also, one other question: How do I best explain the difference between the
> high information content of a message, each bit of which is described as
> "random", and the content of a message which was generated by a meaningless
> random roll of the dice?
This is another semantic issue. The concepts of information and meaning are
orthogonal. The information "the sky is blue" means "It's a nice day".
The information "The dice are 4 and 3" means "You won that roll at craps"
(because it was your first roll) _or_ it means "You crapped out" (making your
point).
In detailed terms the information content of of a message has an effect on the
observer's knowledge. The first "The sky is blue" tells you a lot. The
subsequent identical messages at one second intervals tell you little (because
they are predictable (except in New England)). Only recently have weather
predictions contained any information. For most of the previous century the best
prediction of tomorrow's weather was today's weather. The _meaning_ of those
predictions depends on the person who is reading those predictions: a lady
planning a picnic, a sailor planning a regatta, or a combat team planning a HALO
insertion.
See Claude Shannon's work for a comprehensive review of the foundations of
Information Theory.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Reply-To: don't
Subject: Re: "Shuffled ARC4" revisited
Date: Sun, 18 Feb 2001 19:01:10 GMT
"r.e.s." wrote:
> For any stream cipher, it seems to be a potential weakness
> that each encrypted byte can be matched to the corresponding
> byte of known plaintext. My pedestrian thinking is that an
> opponent might discover some exploitable properties of the
> stream cipher -- properties of ARC4'S state evolution, say --
> and since plaintext and ciphertext bytes are readily matched,
> there is then nothing to deter that exploitation. It seems
> reasonable to consider hardening against even such abstractly
> conceived threats.
Since the result of adding a permutation to a stream cipher is another
stream cipher we can conclude that the weakness you presume, that of
mapping the keystream to the plaintext, is endemic to stream ciphers and
cannot be addressed by producing a variant stream.
Whatever alignment weakness you find in the original cipher will still be
present in the variant cipher because it, too, has a 1:1 alignment of keys
and text.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: National Security Nightmare?
Date: Sun, 18 Feb 2001 18:57:43 GMT
Mok-Kong Shen wrote:
> As to technological knowledgeable peoples, are you sure
> that you have every and absolute good grounds to blame
> those that deviate from an ethical line in countries
> where teaching staffs in universities could barely
> support a moderate sized family with their salaries?
I don't know where you're getting your ideas, but I
certainly never said nor implied that. My opinion is
that the War on Drugs is worse than hopeless because
the real problem is the demand for the product, not
the production of the drugs.
> ... All this serves to support my prediction
> that the surveillance apparatus of communications would
> have their efficacy reduced to almost negligibility in
> the (hypothetical but possible) case where all common
> people make use of encryption, thus creating a situation
> of an order of magnitude more difficult to deal with
> than what alreay is today.
No, as I said that is not where the real problem lies.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
