Cryptography-Digest Digest #207, Volume #13 Wed, 22 Nov 00 11:13:01 EST
Contents:
Re: "unsecure data structures" ? (Bob Silverman)
Re: Q: fast block ciphers (Stefan Lucks)
Re: Entropy paradox (John Savard)
Re: Rijndael(AES) explanation (John Savard)
Re: Entropy paradox (John Savard)
Re: Entropy paradox (John Savard)
Re: New Dynamic Algo + Contest + Doc (Sylvain Martinez)
Re: vote buying... ("Frog2000")
Re: help on user authentication protocol (Philip MacKenzie)
Re: SET; was Re: Why trust root CAs ? (Anne & Lynn Wheeler)
Re: Entropy paradox (James Felling)
Re: New Dynamic Algo + Contest + Doc (David A Molnar)
Re: Pseudo random sequence generation for xor encryption (*NOT* OTP) (Guy Macon)
Re: Cryptogram Newsletter is off the wall? (Anne & Lynn Wheeler)
----------------------------------------------------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: "unsecure data structures" ?
Date: Wed, 22 Nov 2000 14:08:48 GMT
In article <[EMAIL PROTECTED]>,
Paul Crowley <[EMAIL PROTECTED]> wrote:
> Bob Silverman wrote:
> 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.
I was in fact thinking of this attack; There are cases where one
uses a hash or MAC without a random IV; e.g. an HMAC with a low
entropy passphrase as the key; I was thinking that the relatively
small plaintext space should make the problem easier. Given
ciphertext or a hash representing the encrypted data structure, the
total work for such an attack would be (#possible keys * #possible
different instantiations of the data structure) and this is quite
possibly much smaller than the total keyspace. But if we assume a
small entropy key anyway, then your last comment applies.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Stefan Lucks <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Wed, 22 Nov 2000 15:39:25 +0100
On Wed, 22 Nov 2000, Benjamin Goldberg wrote:
> Also, my other point, how to turn a stream cipher (eg Arc4, Panama) into
> a block cipher, was not answered.
>
> I would really love to see an example.
There is a generic (though not too efficient) technique to do this:
Step 1: Use the stream cipher to construct "pseudorandom functions" [GGM].
Step 2: Use the pseudorandom functions to construct a block cipher [LR].
This is provably secure if the stream cipher is secure -- see the
references for details.
References:
[GGM] O. Goldreich, S. Goldwasser, S. Micali: "How to construct random
functions", J. of the ACM, vol 33, pp. 792--807, 1986.
[LR] M. Luby, C. Rackoff: "How to construct pseudorandom permutations from
pseudorandom functions", SIAM J. Computing, Vol. 17, No. 2,
pp. 373--386, 1988.
--
Stefan Lucks Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany
e-mail: [EMAIL PROTECTED]
home: http://th.informatik.uni-mannheim.de/people/lucks/
====== I love the smell of Cryptanalysis in the morning! ======
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Entropy paradox
Date: Wed, 22 Nov 2000 04:17:02 GMT
On 21 Nov 2000 22:30:26 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote,
in part:
>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.
Ah, yes.
Fuel your engine with a pail of water, and a little green pill.
The little green pill happens to be solid acetone (nail polish
remover).
The engine runs on a miracle source of energy that will make oil wells
obsolete?
No - it ran on rather expensive fuel - it obtained energy by burning
the metal out of which the engine was made.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Rijndael(AES) explanation
Date: Wed, 22 Nov 2000 14:18:03 GMT
On Wed, 22 Nov 2000 10:21:45 +0100, Lieven Iliano
<[EMAIL PROTECTED]> wrote, in part:
>We are students from the university of Ghent (Belgium) and we have to
>make a presentation about the Rijndael algoritme. We're looking for a
>simple explanation which is understandable for a regular math student.
>And most of all we're looking for a simple applet to show the working of
>the Rijndael algoritme.
I don't have an applet, but maybe my site makes Rijndael a bit easier
to understand.
http://home.ecn.ab.ca/~jsavard/crypto/co040801.htm
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Entropy paradox
Date: Wed, 22 Nov 2000 04:15:09 GMT
On Tue, 21 Nov 2000 21:42:07 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>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?
There is no paradox whatever.
The u bits are provably secure, because the computation that produced
them cannot, subject to the assumptions, be cryptanalyzed.
But that in *no* way prevents a brute force search over the 2^m
possibilities for the truly random bits, so nothing is obtained from
nothing.
Only if m is large enough that that brute force search is impossible
are the u bits genuinely secure, and their cryptosecurity is the
result of the work factor required to cryptanalyze them - not a single
bit of extra entropy.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Entropy paradox
Date: Wed, 22 Nov 2000 14:16:39 GMT
On Wed, 22 Nov 2000 12:15:58 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>So you conclude that BBS is fairly unsafe (against all
>the commonly seen claims of unpredictability to the left
>and the right)? Thanks.
It is still vulnerable against trying all 2^m combinations of the true
random bits that were started with, since no entropy has been gained.
But if m is big enough so that this is not a concern, the part about
BBS being 'provably secure' means that with more than m of the u bits
produced by the BBS generator, using cryptanalysis to work out what
the m true random bits were, to predict others of those u bits, in
less than 2^m steps, is not possible.
Cryptosecure does not equal truly random.
If it did, we could never use any other system of encryption but the
one-time-pad.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Sylvain Martinez <[EMAIL PROTECTED]>
Subject: Re: New Dynamic Algo + Contest + Doc
Date: Wed, 22 Nov 2000 14:47:24 GMT
In article <[EMAIL PROTECTED]>,
Paul Crowley <[EMAIL PROTECTED]> wrote:
> Sylvain Martinez wrote:
> > BUGS is a relatively new private key algorithm. It does not claim to
be
> > the best algorithm in the world, because as any "home-made"
cryptography
> > algorithm it can't be. It is just the result of a strong interests
I've
> > got in cryptography.
>
> Please read Bruce Schneier's Memo to the Amateur Cipher Designer:
>
> http://www.counterpane.com/crypto-gram-9810.html#cipherdesign
>
I did. I do agree with it
but I am not looking for "well-known cryptographers to look at my work"
not yet anyway.
I assumed that there were not only good cryptographers reading this
forum and some of them would maybe be interested into looking 'first' at
something created by someone who's not a cryptography expert and is not
using all the terminology standard. This can maybe be easier for them
to get started.
My view on this is:
take someone who is new to cryptography, tell him: "go and crack RSA"
then is going to spend a lot of times trying to first understand
how it works then even more times to read mathematical books trying
to crack it.
This is good. But it can discourage many people.
I am looking for those people who are willing to spend some time
understanding a (pseudo)cryptography algorithm.
And before you say it, not because I am on a mission into recruting
new (bad)cryptographer ;o)
but because I know I am not going to attract attention from well-known
cryptographer, they got other more interesting things to do !
Well I was maybe wrong and only experts are on this forum ;o)
> Your claims to security are laughable when there is *no* discussion of
> security in the algorithm documentation! Not even a cursory mention
> of linear or differential cryptanalysis! At least give reasons why
> you believe that your algorithm is resistant to these attacks yourself
> before asking anyone else to look at it. Look at weak key and related
> key attacks too.
There isn't a cryptanalysis in the documentation because:
a) I've done it while creating the algorithm, and again I am not a
"cryptographer"
so it was not "state-of-the-art"
b) I haven't got time to do that as well. And I'm not asking people to
do that for me, just maybe have a quick overview and tell me what they
think. If many people tells me: "yes it looks good, but really without
a strong cryptanalysis we can't go further" then I'll work on it !
c) I know it is USELESS to publish a new algorithm if you don't do a
cryptanalysis
first. Well, it is when you want this algorithm to become a new
standard,etc
And I know by not following the rules I'm going to pissoff people like
you,that the algorithm won't get a good reputation until such a
cryptanalysis
is done. Ok...
STOP...
Thanks for your advises, you are rigth.
But don't look at this algorithm as if a company was claiming:
"this is the best, buy it"
see that as:
"If you're bored, have got time, something has been done, it's free
and there is a documentation. You are also free to do what ever you want
with it,
ie: ignore it, play around with it, use it."
Even if there isn't a crytanalysis of the algorithm by reading at the
documentation
if you know cryptography you could straigth away spot any "BIG"
problems.
Then it's true that you would need to look into the source code to
check the way it has been implemented.
And looking at the logs some people must find it interesting, maybe all
these people who download it are dumb, but then this algorithm is the
algorithm of "dumb people" and someone had to do it ;o)
Sorry if my answer does not sound that serious but I don't really want
to argue, I know where my mistakes are, but I am not trying to say this
algorithm is
perfect.
> Your web pages describe this algorithm as "reasonably secure", and you
> offer a program for download in binary which uses it. In this you do
> the world of security a great disservice.
I'm not sure I understand what you mean...
The source code IS included !
Only in the unix version I admit, but the windows version is using the
same library as the unix version (ie. you take the unix source code
and compile it without any modification with BC++).
But you're right, the source code of the Windows GUI is not available.
The reason behind that was to prevent people to just change few things
in the GUI
and then publish another version claiming the work done for them...
And it is not common practise on Windows to have source code as it is on
Unix...
Because the main part is the library, you could really quickly write
your
own GUI !
The second reason is that the Windows GUI source code is uglly, really
uggly.
I don't like windows, and I even dislike more programming on Windows, so
this Windows GUI is just there to demonstrate the library works fine on
this OS.
But you're rigth, I should update the site tonigth and publish the GUI
source code.
As anyway I can already hear you saying: "who the hell would like to
attribute
your "crappy" work" ;o)
But if the fact that the source code of the Windows GUI not being
available is
the only concern, then it's fine by me. I am only interested into the
cryptography
algorithm.
Cheers,
Sylvain.
--
---
Unix security administrator
BUGS crypto project: http://www.bcrypt.com
http://www.encryptsolutions.com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Frog2000" <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Date: Wed, 22 Nov 2000 10:25:53 -0500
"Shawn Willden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Paul Pires wrote:
>
> > Your main point is the "Same risk as absentee ballots" the part
> > that scares me most is the "in every state part". As in centralized
> > control.
> >
> > In the US, that would also involve removing a key part of the
> > separation of power between the Feds & States.
> > This centralized control and coordination
> > removes the impact, effect and management of the individual
> > states, bad and good alike.
>
> I don't think that "in every state" equates to centralized control.
>
> Although the Electoral College system gets a lot of bad press, its purpose
is to
> ensure that it is the states, not the people (!), who select the
president. Since
> currently all states use popular elections to decide how to cast their
electoral
> ballots this fact isn't as obvious as it once was, but the EC is still
doing the
> job of keeping that portion of the power in the states' hands. And the EC
will
> continue doing that job even with electronic or mail-in balloting. If we
abolish
> the EC, however, we face the risk of centralizing the election
infrastructure.
I understand, according to CNN, that half the states Electoral Votes are
bound to the popular vote. I'd assume this is the case in Florida, or one
wouldn't put so much stock there. One good argument for the EC is this
election. If we went strictly by the popular vote, it could take months to
hand-count the whole country. Of course, in this case, Gore clearly has the
popular vote of ALL the states, but we are giving FL undue weight by making
it count for so much.
>
> Shawn.
>
------------------------------
From: Philip MacKenzie <[EMAIL PROTECTED]>
Subject: Re: help on user authentication protocol
Date: Wed, 22 Nov 2000 10:38:00 -0500
[EMAIL PROTECTED] wrote:
>
> In article <8v48cd$7uv$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Can you comment on Tomas Wu's SRP? I like this protocol but would
> want
> > to know how strong SRP is with comparison to other protocols like PAK,
> > SNAPI, SPEKE, AMP, etc. Thanks.
>
> Wow, I managed to get this reply in before Tom got here. Basically SRP
> is approximately equally strong compared to a large number of others,
> of which you gave a small list. I appreciate the simplicity of the
> protocol, very much so in fact, and would like to see it propogate
> further.
> Joe
>
For simplicity, I would think it's hard to beat PAK, given
that it is just Diffie-Hellman key exchange with one
of the values multiplied by a hash of the password.
In terms of strength, in practice I agree that
they all seem approximately equally strong. However,
being someone who believes in proofs, it bothers me
that I can't figure out a simple cryptographic assumption
under which SRP can be proven secure (even in the
random oracle model). But hey, maybe that's just me.
Of course, if you need something that's freely available
for both commercial and non-commercial use, SRP seems to
be a reasonable choice for the variety of factors
that Tom mentioned in his post.
-Phil
http://www.bell-labs.com/user/philmac/pak.html
------------------------------
Subject: Re: SET; was Re: Why trust root CAs ?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Wed, 22 Nov 2000 16:00:04 GMT
"David Thompson" <[EMAIL PROTECTED]> writes:
> as SET does prevent disclosing payment (card) information.
> (The X9.59 approach has the same limitation, as I read it.)
>
the x9.59 standard requirement was to specify the data elements that
need signing "to preserve the integrity of the financial
infrastructure" for all electronic retail account-based transactions.
one of the data elements is the hash of the order details ... but not
the actual order details.
the x9.59 standard doesn't actually specify messages ... but there has
been work on mapping the x9.59 signed data elements within existing
financial standards messages and protocols (supporting deployment of
x9.59 in both currently non-existant financial infrastructures as well
as existing financial infrastructures).
x9.59 shopping can be done via SSL web ... then sending off a purchase
request message and getting a reply. x9.59 shopping can be also done
from offline cdrom and an x9.59 purchase request email and getting an
x9.59 purchase request reply email (i.e. one requirement on the x9.59
standard definition was that it could be done in a single round-trip).
Or x9.59 shopping could be done at point-of-sale ... i.e. the x9.59
standard was not defined to be an Internet-specific standard ... but
the requirement on the work group was a standard for all electronic
account-based retail transactions preserving the integrity of the
financial infrastructure (it is rather difficult to enforce ssl-based
shopping experience when physically present in a merchant's store).
x9.59 does specify that the account number is used in "authenticated"
transactioons, i.e. non-x9.59 transactions with the x9.59
account-number are not to be approved. many/most issuers support
mapping multiple account-numbers to the same account i.e. various
implementations might include x9.59 only accounts, accounts with
mixture of x9.59 account-numbers and non-x9.59 account-numbers, family
member account-numbers, etc. Rather than having to keep the x9.59
account-number secret in order to prevent fraudulent transactions
... fraudulent x9.59 transactions are prevented by requiring that they
all be end-to-end strong integrity and authenticated.
work as also been done on authenticated X9.59-like transactions using
AVS for hardgood drop shipment ... signed transaction goes to shipper
authorizing address and gets a transaction code supplied to the
merchant. merchant applies the transaction barcode to the
package. the shipper reads the bar-code and looksup the routing code.
Eventually shipper applies real address label for final drop. The
hardgood shipping authorization can be piggybacked in the same
transaction/email with the payment instruction (which the merchant has
to forward to the shipping service for fulfillment). Again this could
be a web-based experience, something like a cdrom/email based
experience, and/or physically in the store and wanting the goods
shipped back home.
Also, x9.59 & x9.59-like definitions are privacy neutral ... not
divulging any privacy information ... while still providing end-to-end
strong integrity.
work is also going on to advance it to ISO international standard as
well as define support within existing ISO 8583 (i.e. international
payment card protocol standard). ABA (american bankers association)
servers as the secretaiat of both X9 (US) and TC68 (iso/internation)
financial standards organization.
there is also the trade-off between BBB/consumer-report certification
using certificates vis-a-vis something like an online BBB web-site.
Trust tends to come in many forms; brand, advertisement,
word-of-mouth, prior experience, certification, etc. when influencing
directing the shopping experience. One of the trust issues is that in
terms of number of transactions ... the vast majority of transactions
(possibly approaching 90+% are brand, advertisement, word-of-mouth,
and/or prior experience based-trust). For the remaining that involve
people actually performing some sort of certification checking
... various certification entities have expressed interest in on-line
web-based certification service ... since that creates a tighter
binding between them and their relying parties (the old saw about the
thing called certificates being an offline paradigm ... targeted for
operations that need to work in an offline environment).
misc. refs:
http://www.x9.org/ US financial standards body
http://www.tc68.org/ ISO financial standards body
http://www.garlic.com/~lynn/ ... some information on x9.59
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Wed, 22 Nov 2000 10:02:20 -0600
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.
>
> M. K. Shen
> ------------------------------
> http://home.t-online.de/home/mok-kong.shen
Simply put your paradox is faulty.
I have m bits of keying information.
I use this to key the PRNG of my choice ( in this case BBS)
This PRNG has m bits of state information, and can at best produce an
output containing m bits of entropy.
We then generate u bits using said prng. In the case of BBS guessing the
composition of those u bits is proven to be equivalent to recovering
the key for the generator.
The u bits are not provably secure. The difficulty of predicting them is
provably equivalent to key recovery for the generator -- thus those u
bits still contain only m bits of entropy.
The apparent paradox is due to the difference between possible meanings
of provably secure. In your 'paradox' you use provably secure to mean
immune to all attack. In the actual case it means equivalent to the
factoring of n. Which is a task that has a difficulty of recovering m
bits.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: New Dynamic Algo + Contest + Doc
Date: 22 Nov 2000 15:41:57 GMT
Sylvain Martinez <[EMAIL PROTECTED]> wrote:
> take someone who is new to cryptography, tell him: "go and crack RSA"
> then is going to spend a lot of times trying to first understand
> how it works then even more times to read mathematical books trying
> to crack it.
> This is good. But it can discourage many people.
I don't think I've ever seen anyone on sci.crypt advise new persons
to "go crack RSA." Most times the advice is "go crack Vignere" or
"go crack Caesar."
If a new person gets anything about RSA, it's "go implement RSA."
-David
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Pseudo random sequence generation for xor encryption (*NOT* OTP)
Date: 22 Nov 2000 16:05:28 GMT
Tim Tyler wrote:
>
>Simon Johnson <[EMAIL PROTECTED]> wrote:
>
>: A self shrinking LFSR is about as good a random number generator as one
>: can get. Okay, its not lightning in software, but with a dense
>: polynomial the sucker is secure.
>
>This doesn't seem to be correct. A self-shrinking LFSR has a period,
>is deterministic and allows backtracking. As such it will be inferior
>to real RNGs for many purposes - and is also unsuitable for use as a PRNG
>in some applications.
>
All software-only PRNGs are determistic and have a period.
It's not hard to make the period far longer than the age
of the universe, but in the end, no software PRNG can have
a period that exceeds 2^<number of bits of data storage
in the computer>.
And of course, if it uses a PRNG, it's not an OTP.
------------------------------
Subject: Re: Cryptogram Newsletter is off the wall?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Wed, 22 Nov 2000 16:06:50 GMT
[EMAIL PROTECTED] (Mark Currie) writes:
> Smart cards can help and a remote secure signing server may also, but the thing
> that worries me is that the basic principle is the same. You are letting a
> machine act as a proxy for signing. There is no biological binding such as in a
> hand-written signature. Smart cards are starting to become complex machines in
> their own right. They now have operating systems and they can download and
> execute third party code.
note that smart cards don't have to become more complex ... they could
become much simpler ... and not allow download & execution of third
party code.
to some extent the existing prevalent smartcard paradigm is left over
from the mid-80s defining portable computing capability using the
technology trade-offs that existing at that point in time. to large
extent the mid-80s trade-offs that resulting in smartcard paradigm
were replaced in the early 90s with PDAs and cellphones
... i.e. mid-80s had relatively inexpensive complex computing chips
that could be packaged in portable form-factors ... but cost-effective
portable input/output capability didn't really exist.
The PDAs and cellphone technologies have largely obsoleted the
technology trade-off decisions from the mid-80s that gave rise to much
of the existing smartcard paradigm.
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
** 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
******************************
