Cryptography-Digest Digest #840, Volume #11 Tue, 23 May 00 00:13:01 EDT
Contents:
Re: pentium timings ("John E. Kuslich")
Re: bamburismus (John Savard)
Re: Reasonably secure OTP passing (John Savard)
Initialization Vector / Message Key with Stream Cipher? ("Elros")
how do you know your decyption worked? (Carb Unit)
problems compiling cryptographic file system (Torsten Mohr)
Encrypted communication between Applet and CGI (Torsten Mohr)
Re: Refs to "Hillclimbing" and other algorithms? ("Douglas A. Gwyn")
Re: Yet another block cipher: Storin ([EMAIL PROTECTED])
Re: Initialization Vector / Message Key with Stream Cipher? (John Savard)
Re: Encrypted communication between Applet and CGI (Paul Rubin)
Re: Initialization Vector / Message Key with Stream Cipher? ("C. Prichard")
Re: Encrypting random data (zapzing)
Re: Compare 3DES's. ("Scott Fluhrer")
Re: how do you know your decyption worked? (S. T. L.)
Re: Blowfish and Weak Keys ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: pentium timings
Date: Mon, 22 May 2000 15:58:19 -0700
I think the boys are being overly pedantic. For most applications the
timing that is important is the timing you measure under real operating
system conditions. What the heck difference does it make if you wind up
measuring some O/S overhead. That overhead will be there in the real
application so you might as well take it into consideration.
Taking averages of the results of GetTickCount() before and after execution
of a subroutine ought to be good enough for about 99.99999% of the
applications, provided you code takes longer to run than the ms resolution
of this function. If it does not, then just run it inline several times to
make it do so.
JK http://www.crak.com
Jerry Coffin <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] says...
> > Anyone interested in timing their code in cycles on a pentium
> > class computer (i.e k6, 586, ppro, MII, etc...) can use the code
> > I developped (well it's not my idea, I just put it together
> > nicely) here
>
> Unfortunately, you didn't put it together particularly well at all.
> RDTSC is NOT a serializing instruction, which means it can be
> executed out of order on a K5 or above or a Pentium Pro or above.
> That means it could execute part of the code you're timing before it
> executes the first RDTSC and/or could execute the final RDTSC before
> it's finished executing all the code you're trying to time. To make
> a long story short, the code will produce inconsistent and inaccurate
> results.
>
> If you want some timing code that actually works, I'll be happy to
> send it to you. Alternatively, I'm pretty sure I've posted it to
> comp.lang.asm.x86, so a search on deja.com should turn it up. Much
> like cryptography, making this work correctly can be substantially
> more work than most people expect.
>
> --
> Later,
> Jerry.
>
> The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: bamburismus
Date: Mon, 22 May 2000 23:51:19 GMT
On Thu, 18 May 2000 20:24:56 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>Further, I guess that
>correlations could be fairly sufficiently suppressed
It is true that, if an IV (initialization vector) is used in an
effective way, using something like the kappa test _directly_ may not
be very helpful. However, the principle is still important and useful,
even if in practice more elaborate or subtle applications of the
principle may be required.
With proper use of modern algorithms, and the power of the computer as
an encryption tool, though, one can probably suspect that
cryptanalysis itself (and not just the kappa test in particular) is
obsolete or close to obsolete. That is the perception I tend to have,
as an "outsider", but that perception is, of course, somewhat
counteracted by the fact that the NSA does still seem to be allocated
funds for SIGINT purposes.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Reasonably secure OTP passing
Date: Mon, 22 May 2000 23:55:43 GMT
On Sat, 20 May 2000 14:11:27 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>Send, enciphered very thoroughly, a whole bunch of OTPs, each of which
>comes with an identifying number. Now, the cryptanalyst also has to
>determine which OTP one's message is related to...
>and if a returning message is sent with a header (all also enciphered
>thoroughly in a conventional system) identifying _two_ of the OTPs,
>and starting points within them, the cryptanalyst has quite a search
>task ahead before even starting the difficult job of analyzing the
>correlations between two enciphered texts.
I found a spot in my web page where it seemed appropriate to put this
notion, explained more fully and with a diagram,
http://www.ecn.ab.ca/~jsavard/mi060901.htm
which page has been expanded in a couple of other spots as well. I
also added a picture of the resistor (and mica capacitor, but I didn't
go into that level of detail) color code and the color code of pool
balls to the introductory page (to accompany Braille and semaphore)
http://www.ecn.ab.ca/~jsavard/intro.htm
plus, a new image was added to the page on the fourth dimension. I
haven't updated my page in a while, and the last few things done with
it were the addition of new additional topics; the encryption part has
been static.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: "Elros" <[EMAIL PROTECTED]>
Subject: Initialization Vector / Message Key with Stream Cipher?
Date: Tue, 23 May 2000 00:48:07 GMT
Let's say that U is a key supplied by the user, that R is a string of
"random" characters (different for each encryption), and that M is a message
to be encrypted. With a stream cipher, is it better to:
1. Encrypt M with a key of R (giving Me). Encrypt R with a key of U (giving
Re). Store the ciphertext as Re+Me.
OR
2. Encrypt M with a key of U+R (giving Me). Store the ciphertext as R+Me
(i.e. R is not encrypted in the ciphertext).
________________________________________
PGP Public Key: http://elros.home.att.net/pgp.htm
------------------------------
From: Carb Unit <[EMAIL PROTECTED]>
Subject: how do you know your decyption worked?
Date: Mon, 22 May 2000 20:18:28 -0400
What few FAQs I could find on encryption were way over
my head. Just explain to me, as if you were talking to
your mom: How can you decrypt anything if you don't
know what you're looking for?
I mean, given that most computer files already have one
level of "encryption" --their respective software's proprietary
data format, and that there are thousands of such formats
in the world today, what do you do after you run your decryption
algorithm? Test if it's a GIF?, no?, a ZIP?, no?, a WAV?, etc?
Or is the assumption always that the material is plain text?
An extremely green question, I'm sure. I'd just like to know.
--tom
------------------------------
From: [EMAIL PROTECTED] (Torsten Mohr)
Subject: problems compiling cryptographic file system
Date: 23 May 2000 00:03:34 GMT
Reply-To: [EMAIL PROTECTED]
Hi,
i'd like to compile the cryptographic file system for Linux.
There are several options in the Makefile to choose, they are
mostly related to rpc_gen. Sadly i didn't find any that work
for me.
Does anybody know a way to compile it? I use the german
distribution SuSE 6.4, Kernel 2.2.14.
Regards,
Torsten.
------------------------------
From: [EMAIL PROTECTED] (Torsten Mohr)
Subject: Encrypted communication between Applet and CGI
Date: 23 May 2000 00:10:25 GMT
Reply-To: [EMAIL PROTECTED]
Hi,
i just wrote an example for a communication between an Applet and a
CGI. Now i'd like to add encryption to it. Basically a user can
choose a username and a password and send it to the CGI.
I'd like to use Diffie-Hellmann for this first communication. Has
anybody got an example for this in Java or Perl?
Regards,
Torsten.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Refs to "Hillclimbing" and other algorithms?
Date: Mon, 22 May 2000 23:29:18 GMT
Mok-Kong Shen wrote:
> ... Hillclimbing in cryptanalysis appears to
> be a method due to Jim Gillogry.
Actually, "hill climbing" refers to a general and fairly obvious
approach to solving for parameters of some model. Gillogly has
explored this more than many in the "open" community, but with
all due respect, he did not originate the method.
There is a nice article on this in the NSATJ, but unfortunately
it's still classified, although I don't see why it needs to be.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Yet another block cipher: Storin
Date: Tue, 23 May 2000 01:49:54 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mark Wooding) wrote:
...
> operation is multiplication by a fixed invertible 4x4 matrix over
> Z_{2^{24}}. The key can be any number of 24-bit words up to 864, in
> theory. I'm not recommending more than 120 bits (5 24-bit words) yet.
> Certainly, more than 576 bits would be bad for a number of reasons.
...
> You can fetch the package from the usual place (which, if memory
serves,
> is http://www.wizard.net/~echo/crypto-contest.html) if you like. You
> can get just the paper, as compressed postscript, from my own web
pages
> at http://www.excessus.demon.co.uk/crypto/storin.ps.gz.
>
> Any cryptanalysis is welcome.
>
> -- [mdw]
Mr Wooding,
A quick look brought a question to mind. It appears that it is
possible to get two plaintext to encrypt to one cipher text. It is
possible that the 4X4 matrix can give two multiplies that both give a
zero vector as a result?
A quick example. Let the modulo be 16 i.e. 2^4
1 2 3 4
0 1 2 3
0 0 1 2
0 0 0 2
If we multiply the matrix by (0,0,0,0) then of course the zero vector
is the result. Suppose we multiply by (0,8,0,8)? The zero vector is
also the result due to the modulo addition and multiplication.
I have not tried to reduce the fixed matrix in the cipher but the
general principle would seem to hold with 24 bit logic.
Let just suppose that two plaintext can encrypt to one ciphertext. The
cipher is then non-reversible. Also by guessing the first round key, a
collision can be produced to verify the guess. With eight rounds the
round keys could be guessed for 2^99 work, much less than the 2^120
suggested key length.
I have not verified this idea with the actual cipher so I may be
totally offbase.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Initialization Vector / Message Key with Stream Cipher?
Date: Tue, 23 May 2000 01:52:42 GMT
On Tue, 23 May 2000 00:48:07 GMT, "Elros" <[EMAIL PROTECTED]> wrote,
in part:
>Let's say that U is a key supplied by the user, that R is a string of
>"random" characters (different for each encryption), and that M is a message
>to be encrypted. With a stream cipher, is it better to:
>1. Encrypt M with a key of R (giving Me). Encrypt R with a key of U (giving
>Re). Store the ciphertext as Re+Me.
>OR
>2. Encrypt M with a key of U+R (giving Me). Store the ciphertext as R+Me
>(i.e. R is not encrypted in the ciphertext).
In 1), it was obvious that + meant concatenation; and that is
certainly a valid scheme of storing M, encrypted, so that if you know
U you can find M, and R supplies variation.
In 2), I thought that + meant something like XOR. If that's what it
means the first time, while it is concatenation the second time, this
would be valid as well, although I'd feel safer with (1); if + is
concatenation the first time, part of the key is in the clear, so that
is not very good, even if U is "long enough".
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Encrypted communication between Applet and CGI
Date: 23 May 2000 02:07:52 GMT
In article <8gci9h$o8$[EMAIL PROTECTED]>, Torsten Mohr <[EMAIL PROTECTED]> wrote:
>Hi,
>
>i just wrote an example for a communication between an Applet and a
>CGI. Now i'd like to add encryption to it. Basically a user can
>choose a username and a password and send it to the CGI.
>
>I'd like to use Diffie-Hellmann for this first communication. Has
>anybody got an example for this in Java or Perl?
This has been done several times before, but in most situations I
think it's best to just set up an SSL web server (www.modssl.org).
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: Initialization Vector / Message Key with Stream Cipher?
Date: Tue, 23 May 2000 02:02:51 GMT
Practically its sometimes not desireable to pass the R whitener string. =
If it is already unique for each message then it is redundant to encrypt =
it, serving no real purpose.
Using a public R string however, requires that it be encrypted by a =
session key. Your choice should be articulated by your security =
requirements. I think that using a fairly long, publicly known random =
mask is ok, if you then encrypt it with a sophisticated key. Needless to =
say that security is weakened, but it is less trouble to exchange a key =
to alter the mask each time than it is to exchange the entire mask =
somehow.
With a stream cipher its often the case that efficiency weighs heavily =
in optimization.
-Charles Prichard
Elros <[EMAIL PROTECTED]> wrote in message =
news:bzkW4.1595$[EMAIL PROTECTED]...
> Let's say that U is a key supplied by the user, that R is a string of
> "random" characters (different for each encryption), and that M is a =
message
> to be encrypted. With a stream cipher, is it better to:
>=20
> 1. Encrypt M with a key of R (giving Me). Encrypt R with a key of U =
(giving
> Re). Store the ciphertext as Re+Me.
>=20
> OR
>=20
> 2. Encrypt M with a key of U+R (giving Me). Store the ciphertext as =
R+Me
> (i.e. R is not encrypted in the ciphertext).
> ________________________________________
> PGP Public Key: http://elros.home.att.net/pgp.htm
>=20
>=20
>=20
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Encrypting random data
Date: Tue, 23 May 2000 02:34:38 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Tom St Denis wrote:
> > You seem like a very confused individual.
>
> Just ignorant, really. :-)
>
> > So you cannot share random bits over an insecure medium at all,
unless
> > you are willing to sacrifice randomness at the hands of
deterministic
> > finite algorithms.
>
> My thought was more along the lines of sharing a hardware RNG over a
LAN,
> rather than necessarily what I do with the random numbers afterwards.
I
> didn't have any particular application in mind. I was just trying to
figure
> out if something like really random numbers encrypted with a decent
> encryption were at all breakable by someone listening in on the LAN.
Of
> course, if they get both the encrypted random numbers and the message
> encoded with the decrypted OTP, it'll be easier to break, and I
realize now
> I'm confused as well as ignorant, having forgotten that the final
recipient
> is going to need the OTP to decrypt, too.
>
> My thoughts were really about using a hardware RNG over a LAN, rather
than
> what one does with the bits afterwards. I.e., if I securely
transmitted a
> RC4 key to HotBits, would that keep people from sniffing my random
numbers
> from their machine? Would there be any way for people to break that if
those
> numbers never left my machine again?
>
> Thanks for your thoughts!
If you are just doing something with
the random numbers that does not need to
be particularly secure, then of course
you do not need to encrypt them at all.
If RC4 level security is OK vis-a-vis
an evesdropper on your LAN then yes
of course you may encrypt them using
RC4. They might then be useful for,
say, paranormal experiments or
whatever. But you should not assume
that they are any *more* secure than
RC4 just because they "were" random at
one time.
--
Do as thou thinkest best.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Compare 3DES's.
Date: Mon, 22 May 2000 19:54:28 -0700
Stefan Lucks <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
m.de...
> Known attacks on double DES, 2-key triple DES and 3-key triple DES:
>
> -- double DES: best known attack needs about 2^57 encyptions
>
> -- 2-key triple DES: also about 2^57 encyptions (!) with many chosen
> plaintexts
Stefan: do you have details on this attack? Is it similar to your 3-key
triple DES attack?
--
poncho
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Subject: Re: how do you know your decyption worked?
Date: 23 May 2000 03:41:41 GMT
You could have an SHA-1 hash of the plaintext, and if the decrypted stuff's
SHA-1 hash matches, then you're in business. Or looking for a header or
something.
-*---*-------
S.T. "andard Mode" L. ***137***
STL's Wickedly Nifty Quotation Collection: http://quote.cjb.net
Join the Minions of Orthodoxy today!
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Blowfish and Weak Keys
Date: Tue, 23 May 2000 03:49:45 GMT
In article <9fcW4.44$[EMAIL PROTECTED]>,
"Kasper Pedersen" <[EMAIL PROTECTED]> wrote:
>
> <[EMAIL PROTECTED]> wrote in message
> news:8g0pb9$vmi$[EMAIL PROTECTED]...
> > I have extended the attack on weak keys in Blowfish. You are
correct
> > there is no way to exploit weak keys in general. If a key is known
to
> > be weak however, then a faster than exhaustive search can be
mounted.
> > The attack essentially stops each guess after running the P
generation
> > for the schedule. Since 512 more encryptions are required to set
up the
> > s-boxes, the attack is much faster than exhaustive search. On the
down
> > side, the best attack on a weak key is 128 faster than exhaustive
> > search. With a 128 bit key, 2^120 full guesses will be required,
pretty
> > stiff.
> >
>
> If I understand correctly, you will still be trying every input key?
Then
> it's similar to when you use 13/14/15-round DES in a DES keyserch;
you just
> decide early wether you want to complete the test of a specific key.
>
> If so, he should NOT filter out weak keys; It would make breaking his
> implementation 0.5% faster (isn't it 1 in about 200-something?) than
brute
> force.
>
> /Kasper
Filtering out weak keys is ok. In order to determine if a key is weak
the schedule must be run. So any brute force search would still have
to run the slow key schedule and then check for a duplicate entry
before discarding the key.
You did understand correctly, BTW. Every key must be tried but only
one in about 2^14 must be fully checked. A bunch of set up work is
required however. The key size must be above 64 bits for the attack to
be faster than brute force. The collision index must also be known.
Not likely.
--Matt
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
******************************
