Cryptography-Digest Digest #205, Volume #13 Wed, 22 Nov 00 07:13:01 EST
Contents:
Re: "unsecure data structures" ? (Paul Crowley)
Re: My new book "Exploring RANDOMNESS" ([EMAIL PROTECTED])
Archives ? ([EMAIL PROTECTED])
Re: SET Protocol -- Question (Stefek Zaba)
Re: Q: fast block ciphers (Paul Crowley)
Re: My new book "Exploring RANDOMNESS" (Paul Rubin)
Re: Pseudo random sequence generation for xor encryption (OTP) (Mok-Kong Shen)
Re: Entropy paradox (Mok-Kong Shen)
Re: Entropy paradox (Mok-Kong Shen)
Re: Entropy paradox (Mok-Kong Shen)
Re: Entropy paradox (Mok-Kong Shen)
Draft FIPS of AES ?? ("kihdip")
Re: Rijndael(AES) explanation ("kihdip")
Re: Draft FIPS of AES ?? (Mok-Kong Shen)
Re: Mode of operation to maintain input size with block ciphers? (Paul Crowley)
Re: XOR: A Very useful and important utility to have ("xx")
Re: XOR Software Utility (freeware) available from Ciphile Software ("Midnight's Own
Fire")
Re: Q: fast block ciphers (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: "unsecure data structures" ?
Date: Wed, 22 Nov 2000 09:48:27 GMT
Bob Silverman wrote:
> In article <[EMAIL PROTECTED]>,
> Paul Crowley <[EMAIL PROTECTED]> wrote:
> > There's no explicit mention of where the key material is coming from
> in
> > the article, but I guess you're making the reasonable assumption that
> > it's a passphrase (or some other low-entropy source).
>
> Yes. If the entropy in bits of the passphrase * number of different
> possible plaintexts is small then this is a lot easier than bruteforce.
I still don't get where you're coming from on that point. I see two
possible meanings.
One is that you'd like to make it information-theoretically difficult
for the attacker to verify a guess at the passphrase, on the grounds
that if there are few possible plaintexts then it's easy enough to
verify if you've got one. This is related to the idea of unicity
distance and the ability of the attacker to model the plaintext.
However, it's not hard to show that if your plaintext would be above the
unicity distance before you prepended the random string, it would be
after too: unicity is all about how much the probability "peaks" stick
out above the rest, and your random string lowers everything equally.
Asking application designers to keep the redundancy of their plaintext
low is an intolerably difficult burden; instead, we design our
cryptosystems to cope with redundancy in the plaintext.
The other is some sort of attack where you compile an index of
ciphertexts correspoinding to all possible (passphrase, plaintext)
pairs. However, if you use a random IV (as of course you should) then
many ciphertexts will correspond to a given plaintext, frustrating such
an attack. And if you can afford to mount that attack, you can often
afford to do a straightforward guess - decrypt - verify sequence on the
passphrase.
Is there another possibility I'm not seeing?
cheers,
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.math,sci.logic
Subject: Re: My new book "Exploring RANDOMNESS"
Date: Wed, 22 Nov 2000 09:24:46 GMT
> Pardon me for being dense, but why would one need to search terribly
> hard for them?
>
> If AC2 is available electronically, it would be either on the Wiley
site
> or on Counterpane. As for K&R, it would be on Prentice Hall's Web
site,
> or possibly Lysator.
Because these books have been OCRed from hard copies, converted to
electronic format, and sometimes customized (like the nice search engine
added to AC2). Editors never heard of it.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Archives ?
Date: Wed, 22 Nov 2000 09:22:54 GMT
Reply-To: [EMAIL PROTECTED]
Hi all....
I am doing a Crypto Uni course and would like access to ALL the archives
from this group, preferably as far back as possible.
Is this possible ?
I know Deja has archive, but only to 1999. And I would prefer text
archives that I can keep offline.
This is fairly URGENT, so I hope there is some kind soul out there !
As I am accessing this group via email, I would appreciate
a reply to my email address if possible.
I really hope you can help, and thanks for your time !
Cheers!
Mark Harrop
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Moderator of the following Programming Lists:
Send a empty message to:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Stefek Zaba)
Subject: Re: SET Protocol -- Question
Date: 22 Nov 2000 09:51:53 GMT
In sci.crypt, [EMAIL PROTECTED] wrote:
> I was reading through the SET Protocol specifications and I realized
> that all documentation point towards the use of RSA and DES.
> RSA makes sense (i.e., it has proven strength), but does anyone know if
> DES is still used for SET's symmetric algorithm?
> To me, DES would seem way to weak. I would hope they are at least using
> 3DES.
SET v1.0 uses single-DES as the bulk encryption algorithm for most of the
data transmitted. However, some data - including the super-sekrit cardnumber
and expiry date, kept utterly and totally confidential in normal usage being
shared only between the cardholder, the issuer, the acquirer, the temporary
employee at the merchant, the shoulder-surfer at the credit-card payphone,
and the dumpster divers (but I digress) - is encrypted directly in the RSA
key of the acquirer. (There's room for this since merchant key moduli are
1024 bits, so you can directly RSA-encrypt that much, instead of the paltry
56 bits of a single DES key or 168 for 3DES.)
This is the reason for the large variety of encryption and signing "primitives"
in the SET documentation - some data is encrypted directly in RSA, some
under a DES session key, and once it's been encrypted under one DES session
key the desire is not to encrypt it again, so there are more notational
conventions introduced to say "take this previously-encrypted blob and
whack it on the end of this other stuff which you're just encrypting"... all
of which makes for rather difficult reading. But if you want to understand
SET, there's really no substitute for wading through books 1, 2, and 3 of
the spec - all at www.setco.org.
As to why single-DES is the bulk cipher for SETv1.0 - well, you have to
remember that the protocol was being designed in 1995/96, when crypto export
rules in the US were *much* tighter than they now are. Single-DES was (indeed
is!) still widely used as the cipher of choice in much of the banking industry,
and getting export, import, and usage approvals with single-DES was expected
to be (and did prove to be) straightforward. Using 3DES or a newer
128-bit-keyed symmetric cipher would have been another issue to cope with
in worldwide adoption - the latter in particular requiring possible New Work
in getting ANSI/ISO/banking-sector-specific standards to bless some newfangled
thing. A future rev of SET might use AES as the bulk cipher, I suppose...
If you think 56-bit single-DES is understrength, look at the vast keyspace the
user gets to specify for a session key under which to receive messages from
the acquirer (such as "we've declined this transaction because you haven't
yet paid off the dinner-n-drinks-for-500-people-in-Las-Vegas"). That's a
stonking great 40 bits - to the spec writers' credit, they couldn't bring
themselves to describe a key that short as offering "encryption", but only
"data masking".
Stefek
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Wed, 22 Nov 2000 11:03:59 GMT
Tim Tyler wrote:
> If the non-existence of any other breaks is granted, a break of Blowfish
> requires approx 2^64 plaintext-cyphertext pairs, while a break of Rijndael
> requires approx 2^128 pt-st pairs (a larger figure).
I think you're using the word "break" in a different way to that in
which cryptanalysts use it. Basically, you haven't broken a cipher
unless you've demonstrated a deficiency that a "random" block cipher
wouldn't have (or, as the K-security definition puts it, that the
majority of block ciphers don't have).
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.logic
Subject: Re: My new book "Exploring RANDOMNESS"
Date: 22 Nov 2000 03:10:53 -0800
[EMAIL PROTECTED] writes:
> In article <[EMAIL PROTECTED]>,
> Richard Heathfield <[EMAIL PROTECTED]> wrote:
>
> > Counter-examples, all of which (IMHO) are relevant to sci.crypt: >
> > "The Art of Computer Programming" - Knuth
> > "The C Programming Language" - Kernighan and Ritchie
> > "Applied Cryptography" - Schneier
> >
> > If any of these /are/ available online, I'd be astonished (and I want
> > the URL!).
Applied Cryptography is available on cd-rom from Dr. Dobbs Journal
along with a bunch of other crypto books on the same CD.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Pseudo random sequence generation for xor encryption (OTP)
Date: Wed, 22 Nov 2000 12:16:04 +0100
Ivan Skytte J�rgensen wrote:
>
> What is the best way of producing a pseudo random sequence for use with
> xor encryption?
Standard texts on crypto have materials on PRNGs. I have
a scheme of building a compound PRNG consisting of an
arbitrary number of constituent PRNGs (of arbitrary type)
on my web page. PRNGs are deterministic and hence 'in
principle' always crackable, though I haven't yet seen
a feasible way of cracking my compound PRNG 'in practice'.
M. K. Shen
==================================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Wed, 22 Nov 2000 12:15:58 +0100
"Trevor L. Jackson, III" wrote:
>
> Mok-Kong Shen wrote:
>
> > This is a re-formulation of an issue that I questioned
> > previously. Suppose one has m perfectly random bits and
> > uses that in some appropriate way to get a BBS generator
> > to generate u bits, with u >> m. We know that (accepting
> > certain plausible assumptions) the u bits are provably
> > secure.
>
> This conclusion is invalid due to ambiguity in the phrase "provably
> secure". In fact there is a sense of provable insecurity in that the
> space of the output, u, can be searched in time proportional to 2^m
> rather than 2^u.
>
> > It seems thus that we have obtained more entropy
> > that way, i.e. having obtained an amount of additional
> > entropy from nothing.
>
> Hardly. There is not even an increase in unpredictability. The size of
> the initial state space is identical to the size of the final state
> space: 2^m.
>
> > How is this apparent paradox to be
> > properly explained? (Or does each bit of the generated
> > sequence have in average m/u bits of entropy?)
>
> Exactly.
So you conclude that BBS is fairly unsafe (against all
the commonly seen claims of unpredictability to the left
and the right)? Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Wed, 22 Nov 2000 12:15:53 +0100
Tom St Denis wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> > This is a re-formulation of an issue that I questioned
> > previously. Suppose one has m perfectly random bits and
> > uses that in some appropriate way to get a BBS generator
> > to generate u bits, with u >> m. We know that (accepting
> > certain plausible assumptions) the u bits are provably
> > secure. It seems thus that we have obtained more entropy
> > that way, i.e. having obtained an amount of additional
> > entropy from nothing. How is this apparent paradox to be
> > properly explained? (Or does each bit of the generated
> > sequence have in average m/u bits of entropy?) Thanks in
> > advance.
>
> Hmm there can't be any more entropy then that contained in the factors
> of the BBS modulus. The outputted bits may appear random but are no
> more random then the size of the modulus. Look at RC4 for example. It
> may be able to output 2^30 bits, but in reality there are only 2^k bits
> required to distinguish the output from random (k << 2^30).
So if BBS generates u bits and I take m bits out of it,
how much entropy is in there? Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Wed, 22 Nov 2000 12:15:42 +0100
David Schwartz wrote:
>
> Mok-Kong Shen wrote:
>
> > This is a re-formulation of an issue that I questioned
> > previously. Suppose one has m perfectly random bits and
> > uses that in some appropriate way to get a BBS generator
> > to generate u bits, with u >> m. We know that (accepting
> > certain plausible assumptions) the u bits are provably
> > secure. It seems thus that we have obtained more entropy
> > that way, i.e. having obtained an amount of additional
> > entropy from nothing. How is this apparent paradox to be
> > properly explained? (Or does each bit of the generated
> > sequence have in average m/u bits of entropy?) Thanks in
> > advance.
>
> The paradox is resolved by using a consistent definition of entropy.
I should appreciate an elaboration of your claim. Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Wed, 22 Nov 2000 12:15:48 +0100
Bill Unruh wrote:
>
> ]Mok-Kong Shen wrote:
> ]
> ]> This is a re-formulation of an issue that I questioned
> ]> previously. Suppose one has m perfectly random bits and
> ]> uses that in some appropriate way to get a BBS generator
> ]> to generate u bits, with u >> m. We know that (accepting
> ]> certain plausible assumptions) the u bits are provably
> ]> secure. It seems thus that we have obtained more entropy
> ]> that way, i.e. having obtained an amount of additional
> ]> entropy from nothing. How is this apparent paradox to be
> ]> properly explained? (Or does each bit of the generated
> ]> sequence have in average m/u bits of entropy?) Thanks in
> ]> advance.
> There is no paradox, just bad assumptions. Assume I have an engine into
> which I can put 1 liter of gasoline, and the engine when it burns the
> gasoline puts out 1000 times as much energy as were in that liter of
> gasoline. How do you explain the paradox? By pointing out that the
> assumption is bad.
>
> You claim "We know that the u bits are provably secure" How do you know
> that (I sure do not so am not included in the "we")?
> Since you have not told us what the BBS generator is or what your
> "proof" is noone can be more exact as to where you went wrong.
I suppose that BBS and its assumptions and proof are known.
I assume that you do the best so that all the entropy in
the given m bits are incorporated into the generator. In
other words, BBS is viewed as a black box with m bits as
input and u bits as output. Is this concept clear? Or do
you contend the correctness of the assumptions and/or
the proof of BBS? Thanks.
M. K. Shen
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Draft FIPS of AES ??
Date: Wed, 22 Nov 2000 12:16:44 +0100
I read in a recent article, that acordingly to the AES 'roadmap', there
should be a draft FIPS availible for public comments in november.
Has this draft been published yet ??
Kim
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Re: Rijndael(AES) explanation
Date: Wed, 22 Nov 2000 12:18:59 +0100
Try at the 'official' NIST site:
http://csrc.nist.gov/encryption/aes/rijndael/
The specification document is quite understandable:
http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf
Kim
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Draft FIPS of AES ??
Date: Wed, 22 Nov 2000 12:36:38 +0100
kihdip wrote:
>
> I read in a recent article, that acordingly to the AES 'roadmap', there
> should be a draft FIPS availible for public comments in november.
>
> Has this draft been published yet ??
The best is to monitor NIST's web page, I suppose.
M. K. Shen
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Mode of operation to maintain input size with block ciphers?
Date: Wed, 22 Nov 2000 11:42:52 GMT
Tim Tyler wrote:
>
> [EMAIL PROTECTED] wrote:
>
> : Generally, using CBC with a fixed IV is not a good idea (although not
> : as bad an idea as using CFB with fixed IV).
> The same IV is a given - you probably mean "the same key".
No, I think they mean "the same IV".
> One simple solution is to apply some unkeyed diffusion to the message
> before encrypting. This makes sure that any entropy later in the message
> finds its way into the first block.
It's hard to prove anything good about this. Better to use one of the
proposals referenced in Mercy, like LIONESS or VSBC, which I gave the
link for earlier.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: "xx" <xxx@xxx>
Crossposted-To: talk.politics.crypto,alt.hacker,alt.computer
Subject: Re: XOR: A Very useful and important utility to have
Date: Wed, 22 Nov 2000 13:37:39 +0200
Hi havnt looked at the program... but heres the thing...
As soon as you mention XOR... cryptographic experts know that thats only
good for one time pads, which are fairly useless for all but a few things...
for example the only way to make an XOR thing secure is to have a key as
long as the plain text... on a 20 Mb file... thats useless.
Having said all that for small plain text... and a XOR key as LONG as the
text... thats what they call a one time pad... and that is the strongest
known cryptographic technique.... just not very practical for lots of stuff.
If you need an amazing tool or want to learn more.... have a look at this
program for windows.
http://www.kewlstuff.co.za/software/index.htm
http://www4.50megs.com/johnnyco/index.htm
Its called Lock Nuts and uses some serious crypto techniques... you'll learn
alot
Guy Macon <[EMAIL PROTECTED]> wrote in message
news:8v9odh$[EMAIL PROTECTED]...
>
> Guy Macon wrote:
> >
> >Anthony Stephen Szopa wrote:
> >
> >>XOR: A Very useful and important utility to have
> >>
> >>A few people in this news group said any XOR program is less than
> >>useless.
> >
> >Balderdash. What people have said is that *YOUR*
> >XOR program is less than useless. Which it is.
> >
> >Why?
> >
> >[1] It's 156KB zipped. Bloatware Alert! Bloatware Alert!
> >
> >[2] You haven't published the source code. Security Risk! Security
Risk!
> >
> >[3] You have a random number generator and an encryption system that
> > you don't advertise, yet you push this little utitity. **A lot**...
> >
> >A reasonable person would suspect that you have something hidden in
> >the code that you don't want users to know about. Which makes it
> >less than useless.
>
> Our good buddy Proton has published "A small stream XOR utility" at
> http://www.energymech.net/users/proton/
>
> It's less than 8K. IIRC, it's less than 8K.
>
> He publishes the source.
>
> It's under the Gnu Public Licence, so you can download it,
> give it away, etc. for free.
>
> ...and that makes "Szopa on a Rropa"'s version less than useless.
>
>
>
------------------------------
From: "Midnight's Own Fire" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Wed, 22 Nov 2000 11:52:37 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
<snipped because I dont even know why I bother...>
> I mean, do you actually think that the software is going to let all
> the test files process normally but when the fate of the world is at
> stake the software will recognize this and the virus or bug or
> trojan or whatever will activate and allow the world to be destroyed?
>
> That's an extraordinary suggestion.
heh. interesting yet childish argument.
I think your missing the point.
here it is.
YOUR PROGRAM IS TOO LARGE FOR WHAT IT DOES!
so provide source or no one will even try it out.
does that help?
I hope so.
I figured I'd yell... just case your deaf... not stupid.
~`MoF
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Wed, 22 Nov 2000 12:52:39 +0100
Tim Tyler wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>
> : I would be interested in hearing how one would change a stream cipher
> : into a block cipher.
>
> You could encrypt each block using the stream cypher (as though it was a
> separate message). It would probably be best to encrypt "in both
> directions" - or the resulting block cypher may be of rather poor quality.
One could moreover repeat this process, thus paralleling
the many rounds used in block ciphers. In fact the whole
message is here a (very large) block. BTW, answering
a quesion raised in another follow-up, one can operate
the stream encryption starting from the end of the message
proceding to its beginning, instead of starting from the
beginning of the message in the common way. (One can do
block encryption with block chaining also in the reverse
way.)
M. K. Shen
------------------------------
** 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
******************************
