Cryptography-Digest Digest #703, Volume #13 Sun, 18 Feb 01 05:13:01 EST
Contents:
Re: Most secure code for US Citizen. ("Douglas A. Gwyn")
is "randomness" an information source? (Daniel Ortmann)
Re: Super strong crypto (Steve Portly)
Re: á÷ôïûéîù îå äïòïçï éú ñðïîéé ("Augusto Jun Devegili")
Re: My encryption system..... (Boris Kazak)
Re:
=?koi8-r?Q?=E1=F7=F4=EF=FB=E9=EE=F9=20=EE=E5=20=E4=EF=F2=EF=E7=EF=20=E9=FA=20=F1=F0=EF=EE=E9=E9?=
(Boris Kazak)
Re: á÷ôïûéîù îå äïòïçï éú ñðïîéé (Nuno Souto)
Re: is "randomness" an information source? ("Douglas A. Gwyn")
Re: Super strong crypto ("Douglas A. Gwyn")
"Shuffled ARC4" revisited ("r.e.s.")
Re: á÷ôïûéîù îå äïòïçï éú ñðïîéé (Rolf Kleinknecht)
Re: "Shuffled ARC4" revisited ("Scott Fluhrer")
Authentication before Key Exchange (George)
Re: Ciphile Software: Why .EXE files so large (Paul Crowley)
Re: Authentication before Key Exchange (Thomas Wu)
PGP 658 with Netscape Mail ("Benjamin Scherrey")
Re: Super strong crypto (wtshaw)
Re: Most secure code for US Citizen. (wtshaw)
Re: Authentication before Key Exchange (Hard)
Re: "Shuffled ARC4" revisited ("r.e.s.")
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Most secure code for US Citizen.
Date: Sun, 18 Feb 2001 01:09:03 GMT
Sundial Services wrote:
> To use another analogy: it has always been a crime to defeat a lock on
> someone's door. But the crime has never been "the act of breaking the
> lock!" Rather, the crime has been "the act that you had to break the
> lock in order to achieve
Not quite accurate, but the idea is right. Objectively defined
crime would include trespassing and burglary even in the absence
of a lock.
------------------------------
From: Daniel Ortmann <[EMAIL PROTECTED]>
Subject: is "randomness" an information source?
Date: 17 Feb 2001 19:24:56 -0600
I was told by someone that "randomness" in an information source, but that
doesn't sound correct.
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?
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?
Thanks!
--
Daniel Ortmann, IBM Circuit Technology, Rochester, MN 55901-7829
[EMAIL PROTECTED] / internal 8.553.6795 / external 507.253.6795
[EMAIL PROTECTED] home 507.288.7732
"The answers are so simple, and we all know where to look,
but it's easier just to avoid the question." -- Kansas
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Sat, 17 Feb 2001 20:34:27 -0500
"Douglas A. Gwyn" wrote:
> Steve Portly wrote:
> > The implementations that pop into mind would be temptingly easy to
> > modify into much stronger configurations. Unless there is some new
> > breakthrough that will balance the equation, I don't see an
> > organization like NIST approving such a cipher scheme?
>
> Sorry, I didn't understand any of that. It seems that you are
> saying that super strong crypto is easy to attain and that there
> would be some kind of suppression of such technology, but maybe
> you meant something else? I wouldn't quickly agree to either of
> those points..
Your proposal sounded as though it would be very effective in keeping the
strength of the key intact. Searching the internet for ciphers offering
*all* of the features you mentioned turned up nothing. Most of the
crypto implementations I have seen use very standardized components and
assigned key spaces. I am sitting here trying to think of a way to
implement this cipher in a way that would deter hacked non standard
copies from being distributed.
------------------------------
From: "Augusto Jun Devegili" <[EMAIL PROTECTED]>
Subject: Re: á÷ôïûéîù îå äïòïçï éú ñðïîéé
Date: Sat, 17 Feb 2001 22:58:05 -0300
ciphertext. ;-)
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: My encryption system.....
Date: Sun, 18 Feb 2001 02:27:55 GMT
Keill_Randor wrote:
(snip*****)
> have to understand exactly what data encryption is about in the first place.
> This seems to be the number one problem with everyone at the minute:
> No-one understands the problem, so no wonder nobody, (apart from myself),
> has actually solved it.
>
(snip*****)
>
> The by-product of this, is being able to turn ANY peice of information into ANY
> peice of information, which again, makes it uncrackable. (And completely screws
> up a lot of laws I know about).
(snip*****)
> (P.S. If no-one else has what I have, does that make me King Cryppie???).
>
> Darren Tomlyn
> [EMAIL PROTECTED]
================================
Time to set an appointment with a psychiatrist...
Take it easy, you will be in good company.
BNK
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re:
=?koi8-r?Q?=E1=F7=F4=EF=FB=E9=EE=F9=20=EE=E5=20=E4=EF=F2=EF=E7=EF=20=E9=FA=20=F1=F0=EF=EE=E9=E9?=
Date: Sun, 18 Feb 2001 02:31:14 GMT
> e-m@il:[EMAIL PROTECTED]
This guy is advertising truck tires from Japan
for Russian customers. Obviously a glitch in his
mass-mail-spam program.
BNK
------------------------------
From: [EMAIL PROTECTED] (Nuno Souto)
Subject: Re: á÷ôïûéîù îå äïòïçï éú ñðïîéé
Date: Sun, 18 Feb 2001 03:05:36 GMT
On Sat, 17 Feb 2001 16:01:38 -0500, "Ryan M. McConahy"
<[EMAIL PROTECTED]> wrote:
>What the heck is this???
>
>
Worst case of sniffles I've ever seen... :-)
Seriously, it's russian in cirylic(sp?).
Crops up from time to time in a few NGs.
Cheers
Nuno Souto
[EMAIL PROTECTED]
http://www.users.bigpond.net.au/the_Den/index.html
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: is "randomness" an information source?
Date: Sun, 18 Feb 2001 03:19:54 GMT
Daniel Ortmann wrote:
> I was told by someone that "randomness" [is] an information source,
> but that doesn't sound correct.
> 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?
> 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?
You should read Claude Shannon's seminal paper on information theory:
http://cm.bell-labs.com/cm/ms/what/shannonday/paper.html
He identifies a measure of information as the amount of "surprise"
in a message; if you already know pretty much what to expect, the
message gives you relatively little information. (Like essentially
everything involving knowledge, it is contextual.) The most
informative data is purely random data, since you have no advance
idea what to expect. So you have it backward when you think that
random data has low information content.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Sun, 18 Feb 2001 03:22:51 GMT
Steve Portly wrote:
> ... I am sitting here trying to think of a way to implement this
> cipher in a way that would deter hacked non standard copies from
> being distributed.
If you mean, copies of the implementation, that's hopeless, as any
independent implementation of more or less the same thing could be
identical to a "hacked, nonstandard" version of your implementation.
The secrecy of the system resides entirely in its (initial) key.
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: "Shuffled ARC4" revisited
Date: Sat, 17 Feb 2001 19:33:03 -0800
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.
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) )
The idea is that as the state vector pseudo-randomly
steps through its permutation states, we "sample" it
once every 256 steps of its evolution, and apply that
permutation directly to X.
Does this expose the state in a way fatal to security,
or, are there reasons, similar to those Terry Ritter
cited in connection with his DT cipher, making the
exposure practically inconsequential?
--r.e.s.
------------------------------
From: Rolf Kleinknecht <[EMAIL PROTECTED]>
Subject: Re: á÷ôïûéîù îå äïòïçï éú ñðïîéé
Date: Sun, 18 Feb 2001 05:01:30 +0100
Reply-To: [EMAIL PROTECTED]
It seems to be a business E-Mail gone havoc. I just recognize some words
meaning "contract", "car", "Japan".
--
rk
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: "Shuffled ARC4" revisited
Date: Sat, 17 Feb 2001 21:10:42 -0800
r.e.s. <[EMAIL PROTECTED]> wrote in message
news:96nfoi$qk2$[EMAIL PROTECTED]...
> 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.
> 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.
--
poncho
------------------------------
From: George <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Authentication before Key Exchange
Date: Sun, 18 Feb 2001 00:04:53 -0600
Several days ago I made a post inquiring about the security of Diffei
Helman for key exchange. One of the users here brought to my attention
it's very secure, but a good authentication algorithm must be chosen to
ensure Alice is communicating with Bob. This past week I researched
many different authentication protocols that use only Alice and Bob and
NO trusted third party. In all of the protocols to pick from, each one
seemed to have a weakness for an MITM attack. Could someone please
dirrect my attention to a place where I can find more information about
secure authentication protocols that use only Alice and Bob and no
trusted third party? What is the best authentication algorithm/protocol
to use to meet these requirements? Thank you for your time.
-George
[EMAIL PROTECTED]
------------------------------
Crossposted-To: talk.politics.crypto
Subject: Re: Ciphile Software: Why .EXE files so large
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Sun, 18 Feb 2001 06:32:33 GMT
"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.
On the other hand, it has built-in bignum support, so you could
implement some public-key systems in it with reasonable efficiency.
You'd have to add quite a few features to their bignum implementation
to produce a real speed king implementation (eg Montgomery reduction)
but a naive version wouldn't be too slow to be worth bothering with
under some circumstances. It could make handy crypto glue, too; for
example, there's an implementation of SPKI in Python called Pisces.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Authentication before Key Exchange
Date: 17 Feb 2001 22:44:40 -0800
George <[EMAIL PROTECTED]> writes:
> Several days ago I made a post inquiring about the security of Diffei
> Helman for key exchange. One of the users here brought to my attention
> it's very secure, but a good authentication algorithm must be chosen to
> ensure Alice is communicating with Bob. This past week I researched
> many different authentication protocols that use only Alice and Bob and
> NO trusted third party. In all of the protocols to pick from, each one
> seemed to have a weakness for an MITM attack. Could someone please
> dirrect my attention to a place where I can find more information about
> secure authentication protocols that use only Alice and Bob and no
> trusted third party? What is the best authentication algorithm/protocol
> to use to meet these requirements? Thank you for your time.
There are indeed protocols that protect against MITM attacks if Alice
and Bob have a shared secret, and many of these protocols also prevent
brute-force attacks against short passwords. Nearly all of them operate
without requiring a trusted third party. Which one is "best" depends
on your requirements. The most popular ones at the present are:
SRP (http://srp.stanford.edu/) - Used mostly for mutual authentication/
key exchange in client/server applications. The server stores only
a password "verifier", which helps limit damage if the password database
is compromised. Incorporated into Internet protocols like Telnet
and FTP (see RFC2944). Version 1.7.2 of the SRP Open Source distribution
was recently released, which features a full set of libraries, tools, and
reference applications for SRP; the distribution is available from the
SRP Website. Also see http://www.ietf.org/ for more information about
SRP-related standards documents.
SPEKE (http://www.integritysciences.com/) - Used mostly for credentials
download applications, like Entrust TruePass. David Jablon is the
inventor of SPEKE, and he has developed the FreeSPEKE SDK, which
implements the SPEKE protocol and is downloadable from his Website.
EKE, PAK, OKE, SNAPI, PDM, etc. - There are a variety of other protocols
that address the problem of strong authentication, each with its own
advantages and disadvantages. A quick Web search will turn up plenty
of information.
Good luck finding the information you need.
Tom
> -George
> [EMAIL PROTECTED]
>
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: "Benjamin Scherrey" <[EMAIL PROTECTED]>
Subject: PGP 658 with Netscape Mail
Date: Sun, 18 Feb 2001 01:13:00 -0500
Is there a plugin that will allow me to en/de-crypt and sign messages in
Netscape 4.76 or better under Linux x86? I've just gotten PGP built and
running (thanx to Ian Goldberg on this group) and find that its not much
use inside Netscape as is.
thanx & later,
Ben Scherrey
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Super strong crypto
Date: Sun, 18 Feb 2001 01:23:11 -0600
In article <[EMAIL PROTECTED]>, Steve Portly
<[EMAIL PROTECTED]> wrote:
>
> The implementations that pop into mind would be temptingly easy to modify
> into much stronger configurations. Unless there is some new breakthrough
> that will balance the equation, I don't see an organization like NIST
> approving such a cipher scheme?
Do you always do what you are told?
--
Better to pardon hundreds of guilty people than execute one
that is innocent.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto
Subject: Re: Most secure code for US Citizen.
Date: Sun, 18 Feb 2001 01:34:56 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> Sundial Services wrote:
> > To use another analogy: it has always been a crime to defeat a lock on
> > someone's door. But the crime has never been "the act of breaking the
> > lock!" Rather, the crime has been "the act that you had to break the
> > lock in order to achieve
>
> Not quite accurate, but the idea is right. Objectively defined
> crime would include trespassing and burglary even in the absence
> of a lock.
There is considerable difference in hacking into someone elses server and
taking apart something that you had purchased so as to reuse the parts,
even sell them as used. Either you have control or you don't. A criminal
act would be letting someone else control my own property on my own
property.
--
Better to pardon hundreds of guilty people than execute one
that is innocent.
------------------------------
From: [EMAIL PROTECTED] (Hard)
Subject: Re: Authentication before Key Exchange
Date: Sun, 18 Feb 2001 09:31:38 GMT
If Alice and Bob are unable to exchange any secret or PK prior to
communicating, which eliminates taking advantage of PK to authenticate
without a third party PKI, or, barring the previous, are unable to
communicate in pure full-duplex at a very high speed (which is likely
that they won't be able to do that), then "technically" they are going
to be subject to MITM no matter which algorithm they choose.
Hard
On Sun, 18 Feb 2001 00:04:53 -0600, George <[EMAIL PROTECTED]>
wrote:
>Several days ago I made a post inquiring about the security of Diffei
>Helman for key exchange. One of the users here brought to my attention
>it's very secure, but a good authentication algorithm must be chosen to
>ensure Alice is communicating with Bob. This past week I researched
>many different authentication protocols that use only Alice and Bob and
>NO trusted third party. In all of the protocols to pick from, each one
>seemed to have a weakness for an MITM attack. Could someone please
>dirrect my attention to a place where I can find more information about
>secure authentication protocols that use only Alice and Bob and no
>trusted third party? What is the best authentication algorithm/protocol
>to use to meet these requirements? Thank you for your time.
>
>-George
>[EMAIL PROTECTED]
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: "Shuffled ARC4" revisited
Date: Sun, 18 Feb 2001 01:43:52 -0800
"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 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.
--r.e.s.
------------------------------
** 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
******************************
