Cryptography-Digest Digest #190, Volume #13 Sun, 19 Nov 00 22:13:00 EST
Contents:
Re: AES/Rijndael performance on Pentium 4? (Cornelius Sybrandy)
Re: Mode of operation to maintain input size with block ciphers? ("Benny Nissen")
Re: XOR: A Very useful and important utility to have (Simon Johnson)
Re: Cryptogram Newsletter is off the wall? (Simon Johnson)
Re: XOR: A Very useful and important utility to have (Guy Macon)
Re: Cryptogram Newsletter is off the wall? (Mathew Hendry)
Re: Mode of operation to maintain input size with block ciphers? (John Savard)
Re: Mode of operation to maintain input size with block ciphers? (Tim Tyler)
Re: hardware RNG's (Tim Tyler)
Re: hardware RNG's (Tim Tyler)
Re: Mode of operation to maintain input size with block ciphers? (John Savard)
Re: hardware RNG's (Tim Tyler)
Re: hardware RNG's (David Schwartz)
Re: hardware RNG's (David Schwartz)
Re: Randomness from key presses and other user interaction (Tim Tyler)
simple proof of summation ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Cornelius Sybrandy <[EMAIL PROTECTED]>
Subject: Re: AES/Rijndael performance on Pentium 4?
Date: Sun, 19 Nov 2000 16:34:50 -0500
Tom St Denis wrote:
> In article <[EMAIL PROTECTED]>,
> David Crick <[EMAIL PROTECTED]> wrote:
> > I seem to remember talk of (some of) the AES candidates being
> > *slower* on the Pentium 4 platform, due to the different (longer)
> > times needed to execute certain instructions, etc.
> >
> > Any idea if Rijndael gets slower or faster on the Pentium 4 platform
> > over Pentium II/III?
>
> Who cares? As long as it can handle the megabit/sec range does it
> really matter? I think alot of speed arguments (17 cycles per byte vs
> 23 cycles per byte, etc...) are just plain stupid. On a personal
> computer as long as encrypting a 1mbps stream can be done with relative
> low loss in performance (i.e you can do other things) I don't think it
> matters.
>
Still, it would serve as a nice benchmark when comparing different
processors. Preliminary reports are already saying that the instructions /
cycle of the P4 is less than that of the Athlon, but it will run at higher
Mhz. Well, hopefully we'll see this week how it fares.
csybrandy
P.S. If you want some nice CPU reviews, goto http://www.tomshardware.com.
He gives some nice cost vs performance comparisons.
<snip>
------------------------------
From: "Benny Nissen" <[EMAIL PROTECTED]>
Subject: Re: Mode of operation to maintain input size with block ciphers?
Date: Sun, 19 Nov 2000 22:59:43 +0100
Thanks for the info - very informative!
A simple question more:
Is it possible to work with input size smaller then the cipher block size
and keep the output size as the input size?
(NB: no dynamic IV needed)
I can not find a solution in the URL's you specified (may need to look a bit
more - just a quick look)
Benny
"John Savard" <[EMAIL PROTECTED]> skrev i en meddelelse
news:[EMAIL PROTECTED]...
> On Sun, 19 Nov 2000 11:33:41 +0100, "Benny Nissen"
> <[EMAIL PROTECTED]> wrote, in part:
>
> >Is there a mode of operation where I can maintain the size in all cases
> >(input/output). I know that CFB mode can be used, but with this mode a
new
> >IV need to be generated each time to maintain security. I am looking for
a
> >way to maintain the size at all times and without the need to make a new
IV
> >(a fixed one is OK).
>
> http://home.ecn.ab.ca/~jsavard/crypto/mi060706.htm
>
> discusses one such mode. Although I think that a patent covers it,
> I've been told that it was used before in the program Secure File
> System (like Scramdisk, but works under DOS). But I tried checking
> that, and I couldn't find what was referred to in the documentation.
>
> >I have heard about a method called byte stealing, but I do not know what
it
> >is all about!
>
> Ciphertext stealing is described in "Terminating Block Cipher Use" on
> this page:
>
> http://home.ecn.ab.ca/~jsavard/crypto/mi060303.htm
>
> Thus, these two references on my web page may help answer some of your
> questions.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,alt.computer
Subject: Re: XOR: A Very useful and important utility to have
Date: Sun, 19 Nov 2000 22:37:32 GMT
In article <8v916g$j75$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <8v8si0$g2j$[EMAIL PROTECTED]>,
> Simon Johnson <[EMAIL PROTECTED]> wrote:
> > Moral of the story: USE AN AES IMPLEMENTATION FOR SECURITY.
>
> This means anything that uses AES is secure?
>
> Moral of the story: Get security right!
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
This is correct, quoting AES as a slogon is a sin. What i meant was
that a flawless implementation of AES is far more useful than an XOR
program.
while i'm here, why do people still implement these things without a
passphrases? Hashed Passphrases are much more secure because the users
of the program would (hopefully) use a much larger fraction of the
keyspace. Using programs where the key is read from a text box, for
example, reduces the keyspace significantly.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Cryptogram Newsletter is off the wall?
Date: Sun, 19 Nov 2000 22:57:06 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Bruce Schneier wrote:
> >
> [snip]
> > Digital signatures prove, mathematically, that a secret value known
as
> > the private key was present in a computer at the time Alice's
> > signature was calculated. It is a small step from that to assume
that
> > Alice entered that key into the computer at the time of signing.
But
> > it is a much larger step to assume that Alice intended a particular
> > document to be signed. And without a tamperproof computer trusted
by
> > Alice, you can expect "digital signature experts" to show up in
court
> > contesting a lot of digital signatures.
>
> Isn't it that there is the additional general problem of
> identifying a public key with the (physical) person?
> Trust centres presumably should solve that problem. But
> there is a problem of trusting the persons at the trust
> centres as well as trusting the mechanisms it employs,
> isn't it? Thanks.
>
> M. K. Shen
>
The problem is, that the trust of this centre is a mathematical
abstraction. That kind of implicit trust cannot exist in reality. Who
on earth could you trust to store information of that value. The
government? No thank you.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: talk.politics.crypto,alt.hacker,alt.computer
Subject: Re: XOR: A Very useful and important utility to have
Date: 19 Nov 2000 23:40:33 GMT
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: Mathew Hendry <[EMAIL PROTECTED]>
Subject: Re: Cryptogram Newsletter is off the wall?
Date: Sun, 19 Nov 2000 23:52:05 +0000
On Sun, 19 Nov 2000 22:57:06 GMT, Simon Johnson <[EMAIL PROTECTED]>
wrote:
>The problem is, that the trust of this centre is a mathematical
>abstraction. That kind of implicit trust cannot exist in reality. Who
>on earth could you trust to store information of that value.
Your immediate friends and family? In law, require each citizen to nominate at
least N people as signatories to his key. Increase N to increase the cost of an
attack.
Of course this idea has its problems. :) But as far as trust is concerned I
think it's an upper bound: can you do better than trusting the people who you
trust the most?
-- Mat.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Mode of operation to maintain input size with block ciphers?
Date: Mon, 20 Nov 2000 00:00:42 GMT
On Sun, 19 Nov 2000 22:59:43 +0100, "Benny Nissen"
<[EMAIL PROTECTED]> wrote, in part:
>Is it possible to work with input size smaller then the cipher block size
>and keep the output size as the input size?
>(NB: no dynamic IV needed)
That would be pretty difficult.
You can't invert a block cipher if you don't have the whole output to
put back in.
And if you *don't* invert it, and you don't have a dynamic IV, then
you are just XORing a fixed value to your message, which is not very
secure.
If you have a minimum message size of 8 bits, you might do this:
use the length of your message in bits as your IV,
generate nine 256-byte S-boxes using OFB as a source of random data
into some method of producing permutations, then continue generating
words using OFB, and each byte is encrypted with one word of OFB
output like this: byte -> S1 -> XOR with 1st byte of output -> S2 ->
XOR with 2nd byte of output -> ...
but even this, while it is about as good as one could do under such a
circumstance, is not really secure without a dynamic IV.
Could you not sneak an IV in:
i.e., for E-mail, derive the IV from the date and time that goes with
the E-mail; for disk encipherment, derive the IV from the current
track and sector numbers.
Doing without an IV and having messages shorter than one block is
_very_ difficult to do properly.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Mode of operation to maintain input size with block ciphers?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 20 Nov 2000 00:05:00 GMT
[EMAIL PROTECTED] wrote:
: Tim Tyler <[EMAIL PROTECTED]> writes:
:> You're thinking about "cyphertext stealing", I believe. Look it up in
:> (for example) Applied Cryptography.
: Cyphertext stealing does not maintain size. It is a modification of CBC
: mode and so requires an IV, which will add to the size.
I believe the OP explicitly stated that a fixed IV was to be employed.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Reply-To: [EMAIL PROTECTED]
Date: Mon, 20 Nov 2000 00:16:01 GMT
David Schwartz <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> To my mind a sequence that is one 80% 2s hardly qualifies as "random" or
:> "unpredictable".
: Then what about a sequence that is 50% 1's?
Assuming there are two possible elements, that might be more likely to be
a random stream. Whether it stood a high chance of being random would
depend on other properties of the sequence - besides the bit density.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Florist: Petal pusher.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Reply-To: [EMAIL PROTECTED]
Date: Mon, 20 Nov 2000 00:21:55 GMT
David Schwartz <[EMAIL PROTECTED]> wrote:
[defining terms]
: I use "random" (in a cryptographic context) to mean unpredictable (by
: an attacker with a specific presumed set of resources). How random
: something is is the same question as to what extent a hypothetical
: attacker could predict it.
How does that square with your supposedly-random dice with a '1' on one
side and a '2' on five other sides?
Surely the attacker would predict that it would come up with a "2" showing
- and be right much of the time?
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Sarcasm: Barbed ire.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Mode of operation to maintain input size with block ciphers?
Date: Mon, 20 Nov 2000 00:06:25 GMT
On 19 Nov 2000 12:10:03 -0800, [EMAIL PROTECTED] wrote, in
part:
>Cyphertext stealing does not maintain size. It is a modification of CBC
>mode and so requires an IV, which will add to the size.
I understood ciphertext stealing to be a modification of ECB mode;
although the final encipherment could be in ECB mode while the regular
encipherment was in CBC mode or any other.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Reply-To: [EMAIL PROTECTED]
Date: Mon, 20 Nov 2000 00:35:09 GMT
David Schwartz <[EMAIL PROTECTED]> wrote:
[physical randomness]
: Radioactive decay similarly qualifies -- as even if it is shown to be
: deterministic, it is still beyond the realm of imagination that someone
: might be able to remotely predict how a radioactive sample that they
: can't even examine will decay.
I can imagine it being completely determined rather easily -
here are the relevant headlines:
"Scientists discover molecular oracle";
"Truth-telling device solves hard maths problems instantly";
"Secrets of universe found embedded in lead atoms";
"Is hotline to God genuine?";
"Parallel universes are closer than was previously thought";
"Logicians try to force God to prove his non-existence";
"Man finally meets his maker".
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Free gift.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: Sun, 19 Nov 2000 16:45:02 -0800
Tim Tyler wrote:
>
> David Schwartz <[EMAIL PROTECTED]> wrote:
>
> [defining terms]
>
> : I use "random" (in a cryptographic context) to mean unpredictable (by
> : an attacker with a specific presumed set of resources). How random
> : something is is the same question as to what extent a hypothetical
> : attacker could predict it.
>
> How does that square with your supposedly-random dice with a '1' on one
> side and a '2' on five other sides?
>
> Surely the attacker would predict that it would come up with a "2" showing
> - and be right much of the time?
Exactly. But we know exactly how often he'd be right and exactly how
often he'd be wrong. So we have some randomness, and we know how much.
So this randomness is cryptographically usable. The important thing is
that you have a reliable lower bound on how much randomness you have.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: Sun, 19 Nov 2000 16:48:44 -0800
Tim Tyler wrote:
>
> David Schwartz <[EMAIL PROTECTED]> wrote:
>
> [physical randomness]
>
> : Radioactive decay similarly qualifies -- as even if it is shown to be
> : deterministic, it is still beyond the realm of imagination that someone
> : might be able to remotely predict how a radioactive sample that they
> : can't even examine will decay.
>
> I can imagine it being completely determined rather easily -
> here are the relevant headlines:
>
> "Scientists discover molecular oracle";
> "Truth-telling device solves hard maths problems instantly";
> "Secrets of universe found embedded in lead atoms";
> "Is hotline to God genuine?";
> "Parallel universes are closer than was previously thought";
> "Logicians try to force God to prove his non-existence";
> "Man finally meets his maker".
I guess it's not outside the realm of the imagination. <G>
Let me say this -- I have as much confidence that nobody will ever be
able to predict the measured decay rate of a radioactive sample that
they don't have access to as I do in the strength of any other
cryptographic structure or system that I currently know of.
Let's say this though, when and if someone ever figures out a way, do
you think they could possibly use it to retroactively figure out what
decay rate _was_ measured in past samples? Unless you assume that, we're
still secure so long as we stop using radiation once this hotline to god
is discovered. ;)
DS
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Randomness from key presses and other user interaction
Reply-To: [EMAIL PROTECTED]
Date: Mon, 20 Nov 2000 00:43:17 GMT
Steve Roberts <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote:
:>Steve Roberts <[EMAIL PROTECTED]> wrote:
:>: Aargh, the user will just hold a key down so that all the key strokes
:>: will have the same spacing in time!! Don't forget that humans will
:>: usually find the easiest possible way of doing something. [...]
:>
:>You can detect this easily. Insisting on a number of key releases
:>is one counter-measure to having the user hold down a key.
: But if that is implemented then the work-minimising user, on finding
: that holding the key down won't do, will repeatedly press the same
: key, or alternate with two different keys. [...]
There's still some juice in there - plenty more than holding a key down at
any rate.
If you want to make the user press more keys, do so - it's not that hard.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Free gift.
------------------------------
From: [EMAIL PROTECTED]
Subject: simple proof of summation
Date: Mon, 20 Nov 2000 02:44:59 GMT
OK,
As an assignemnt I am asked to solve the following Equation
Sum{i =1,n}Sum{j= 1,i}(i(i-1)/2+j-1)
OK
As I was asked to find the solution for it. I found it to be
(n-1)n(n+1)(n+2)/8
OK
I found it by trial and error and the solution I found works for the
given equation (It could be a wrong solution, but since it works for
almost every value of n hence I think it's correct)
COuld anyone help me out in proving such a solution (I mean there is a
proper way to prove it but I did it by trial and error)
Since I am new to this deja.com I am going to post it on different
newsgroups. So If you see this on different places then ignore others.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
