Cryptography-Digest Digest #7, Volume #13 Thu, 26 Oct 00 14:13:01 EDT
Contents:
Re: rc4 proprieties (Simon Johnson)
Xor values?? ([EMAIL PROTECTED])
Re: How do I detect invalid passwords? (Mike Rosing)
Re: Collision domain in crypt()? (Simon Johnson)
Re: Collision domain in crypt()? (Mike Rosing)
Re: Xor values?? (fvw)
Re: Collision domain in crypt()? (David Wagner)
Re: Q: Computations in a Galois Field (David Wagner)
Re: Q: Computations in a Galois Field (Mike Rosing)
Re: Computations in a Galois Field ("bubba")
Re: Rijndael and PGP ([EMAIL PROTECTED])
Re: Rijndael and PGP (Simon Johnson)
Re: hardware vs. software vs. crypto accelerators ([EMAIL PROTECTED])
Re: How do I detect invalid passwords? (Simon Johnson)
Re: Collision domain in crypt()? (David Wagner)
Re: My comments on AES ([EMAIL PROTECTED])
Re: Is OPT the only encryption system that can be proved secure? (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: rc4 proprieties
Date: Thu, 26 Oct 2000 17:06:33 GMT
In article <8t9dfn$ln7vo$[EMAIL PROTECTED]>,
"dexMilano" <[EMAIL PROTECTED]> wrote:
> As a lot of you knows, is available on the web a source code for an
rc4
> compatible cipher.
> I've worked on it making some modification.
>
> I want to verify if, with these changes, the algoritm can be deployed
to
> public.
> I know that rc4 is RSA's properties, but with changes? also the
compatible
> version?
> Any suggestion will be appreciated.
>
> dex
>
>
The name RC4 is RSA's Property, but the algorithm cannot be attributed
to RSA Inc, but only to Ron-Rivest. The algorithm was never patatented,
but kept a trade secret. Once this secret was revealed, RSA couldn't
claim to own it.
So providing you don't use the name RC4, its perfectly legal to use the
algorithm.
--
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]
Subject: Xor values??
Date: Thu, 26 Oct 2000 17:10:07 GMT
I have been looking and all I find about Xor
is somethings about logical exclusions with
true and false. What I want to know and am
asking any of you out there to help me fully
understand what is going on with some of the
encryption function I have seen around is to
explain the use of Xor with numbers.
Why
10 = 12 Xor 6
4 = 12 Xor 8
6 = 12 Xor 10
14 = 7 Xor 9
I would appreciate any info or pointers about
how this works.
Thanks,
Matt
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: How do I detect invalid passwords?
Date: Thu, 26 Oct 2000 12:24:31 -0500
[EMAIL PROTECTED] wrote:
> A. Is there a better (i.e. safer) way to do this?
> B. How do I detect an incorrect password? I don't want to decrypt the
> information if the password that the user gives in step 4 is incorrect
> since the result after step 6 would be garbage.
You have to store something for comparison. You can either store some
"magic number" to look for when you first try to decrypt or you can
store a "hash of the hash", something that won't help determine the
actually password or secret key. A cute way, which I don't really
recomend but it seems cool, is to hash the password for a secret key,
and use that to compute a "public key". You can store the public key
and when the user comes back, you can hash their password, recompute
the public key and see if it matches what's stored. If not, no point
in decrypting anything.
But a hash of the hash and storing that is much faster.
patience, persistence, truth,
Dr. mike
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Collision domain in crypt()?
Date: Thu, 26 Oct 2000 17:24:31 GMT
In article <eVWJ5.670$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> What's the collision domain in a standard (Solaris) crypt() function?
>
> I'm in need of a simple hash function for ~4 million items, with a
digest of
> approx 10-14 chars; MD5 et al at 32 characters is simply overkill.
Am I
> in the right ballpark?
>
>
MD5 produces a 128-bit output, using the birthday attack, you could
expect to find a two documents that hash to the same value after trying
18,446,744,073,709,551,616 pairs.
Defining wether its overkill depends on what u need you're hash to do.
If you simply want to uniquly identify a record then its overkill. You
would only need around 24-bits to represent all 4 million with a low
chance of collision. To avoid birthday attack, you need about 6
characters.
A CRC is probably you're best bet, though it isn't designed for this
task, because its realitivly simple to implement.
--
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: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Collision domain in crypt()?
Date: Thu, 26 Oct 2000 12:31:45 -0500
[EMAIL PROTECTED] wrote:
>
> What's the collision domain in a standard (Solaris) crypt() function?
>
> I'm in need of a simple hash function for ~4 million items, with a digest of
> approx 10-14 chars; MD5 et al at 32 characters is simply overkill. Am I
> in the right ballpark?
crypt() is based on DES which is 56 bits, way more than 4 million. Should
work fine for what you want. You get 8 chars digest, but that's pure binary
so expand it to ascii to get about 11 is right where you want to be. (via base
64)
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (fvw)
Subject: Re: Xor values??
Reply-To: [EMAIL PROTECTED]
Date: Thu, 26 Oct 2000 17:30:42 GMT
<8t9oh8$pcj$[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
>Why
>10 = 12 Xor 6
>4 = 12 Xor 8
>6 = 12 Xor 10
>14 = 7 Xor 9
It's really quite simple. XOR works on binary digits, thus 12=1100 binary,
and 6 is 0110. (if you don't know how conversion to binary works, try
searching for it with google, there are plenty of sites about it...).
XOR has the following truth table:
01
+--
0|01
1|10
This means that if both inputs are 0, the output is 0. If both are 1, then
the output is also 0. In the other two cases the output is 1.
So, if you lign up the numbers in your first example, you get
1100
0110
and if you then XOR each group of bits, you get
1100
0110
---- XOR
1010
1010 is of course 10 in the decimal system.
--
Frank v Waveren
fvw@[var.cx|stack.nl|chello.nl|dse.nl]
ICQ# 10074100
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Collision domain in crypt()?
Date: 26 Oct 2000 17:31:27 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
>What's the collision domain in a standard (Solaris) crypt() function?
What's a collision domain?
>I'm in need of a simple hash function for ~4 million items, with a digest of
>approx 10-14 chars; MD5 et al at 32 characters is simply overkill. Am I
>in the right ballpark?
crypt() has a 64-bit output. If you has N values, the chances
of a probability are about N^2/(2*2^64). At N = 2^22, this is
about 1 in 2 million. So it should be good enough to prevent
collisions.
BUT, crypt() only accepts 56-bit inputs. So, if you want to
hash anything longer than that, crypt() won't do the job.
In comparison, MD4, MD5 and SHA accept arbitrary-length inputs.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Q: Computations in a Galois Field
Date: 26 Oct 2000 17:33:40 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
kihdip wrote:
>Twofish and Rijndael (among others) use computations in a Galois Field.
>
>Can any of you explain to me why the Galois Field is usefull. (Advantages)
It is used in Twofish and Rijndael as a fast and cheap way to get diffusion.
In software, it can be implemented efficiently as a lookup table. In hardware,
it can be implemented efficiently in a number of different ways (due to the
mathematical structure of GF(2^n)).
Also, the mathematical structure of GF(2^n) allows you to build diffusion
structures with nice properties. For instance, Twofish uses it to build a
MDS matrix, which has some nice provable diffusion properties (see the
Twofish paper for details).
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Thu, 26 Oct 2000 12:38:15 -0500
Volker Hetzer wrote:
>
> kihdip wrote:
> >
> > Twofish and Rijndael (among others) use computations in a Galois Field.
> >
> > Can any of you explain to me why the Galois Field is usefull. (Advantages)
> > Is it because of the modulus, so you'll never get more than 8 bits ??
> > Or because it eases decryptation ??
> >
> > Rijndael uses 11B and Twofish uses 169 - how do one choose the irreductable
> > polynomia ?? Are some better than others ??
> Could anybody answering please post here? I'd like to learn a bit too.
A field is invertable. A Galois field is finite so you never get more (or less)
than a known amount of possible answers. It's also fast and easy on modern
microprocessors.
Those are a lot of good reasons, and I'm sure people can think of more.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "bubba" <[EMAIL PROTECTED]>
Subject: Re: Computations in a Galois Field
Date: Thu, 26 Oct 2000 12:44:30 -0500
I have no idea if this is the correct answer, but the math is easier
because of no carries or borrows (I am assuming fields of 2^n
elements).
The math lends itself to parallelism. Take the case of adding
two 1024 bit numbers. With Galois field operations, the operation
is exclusive-or, and sections can be done in parallel. But with
integer arithmetic, you have the carries to deal with.
"kihdip" <[EMAIL PROTECTED]> wrote in message
news:8t9dui$pmb$[EMAIL PROTECTED]...
> Twofish and Rijndael (among others) use computations in a Galois Field.
>
> Can any of you explain to me why the Galois Field is usefull. (Advantages)
> Is it because of the modulus, so you'll never get more than 8 bits ??
> Or because it eases decryptation ??
>
> Rijndael uses 11B and Twofish uses 169 - how do one choose the
irreductable
> polynomia ?? Are some better than others ??
>
> Kim
>
>
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Rijndael and PGP
Date: Thu, 26 Oct 2000 17:39:15 GMT
Of course the problem is that "Twofish" is added to PGP7 already, and it
wasn't the AES winner, and so I don't see Rijndael being added as too
far fetched of an idea. I'd frankly would love to see Serpent in
there...
Albert
In article <8t4jjk$hq9$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <bsgJ5.161$[EMAIL PROTECTED]>,
> "George Gordon" <[EMAIL PROTECTED]> wrote:
> > Rijndael and PGP. What's the word on this?
> >
>
> You have succesfully named two buzzwords. Your homework is to study
> why your question is stupid.
>
> Honest, the ciphers in PGP (IDEA, CAST, 3DES) are secure enough,
adding
> Rijndael will ****NOT**** make PGP any better or usefull then it
> already is.
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Rijndael and PGP
Date: Thu, 26 Oct 2000 17:44:58 GMT
In article <8t4jjk$hq9$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <bsgJ5.161$[EMAIL PROTECTED]>,
> "George Gordon" <[EMAIL PROTECTED]> wrote:
> > Rijndael and PGP. What's the word on this?
> >
>
> You have succesfully named two buzzwords. Your homework is to study
> why your question is stupid.
>
> Honest, the ciphers in PGP (IDEA, CAST, 3DES) are secure enough,
adding
> Rijndael will ****NOT**** make PGP any better or usefull then it
> already is.
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Indeed, Rijndeal is faster than Twofish but not as secure. It appears
than Zimmerman likes his ultra-secure ciphers (hence IDEA, CAST and 3-
DES). So i would agree with Tom's reasoning, and say its unlikely that
Rijndeal will be included in PGP.
--
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]
Subject: Re: hardware vs. software vs. crypto accelerators
Date: Thu, 26 Oct 2000 17:36:57 GMT
I do quite a bit of work consulting on enterprise solutions for crypto,
what is the tactical situation you need it for? What kind of budget?
Do you already have infrastructure in place? Platform(s)?
This is a very open-ended question...
Albert
In article <8t7023$sde$[EMAIL PROTECTED]>,
"Simon" <[EMAIL PROTECTED]> wrote:
> Could anybody point me in the direction of a good resource comparing
and
> contrasting the various approaches to delivering cryptographic
services for
> enterprise customers?
>
> Replies to [EMAIL PROTECTED] would be appreciated.
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: How do I detect invalid passwords?
Date: Thu, 26 Oct 2000 17:40:05 GMT
In article <8t88h7$j7v$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I am trying to write an application that does something like this:
>
> 1. Asks the user for a password.
> 2. Using the password, I get an MD5 hash.
> 3. I use the hash to encrypt the user's information (i.e. a data file)
> using a symmetric cipher such as BlowFish or triple-DES.
>
> Now when the user wants to retrieve the information I do something
like
> this:
>
> 4. Ask the user for the password (same one as in step #1 above). 5.
Get
> the MD5 hash using the password in step 4.
> 6. Decrypt the data using the hash.
>
> I have two questions:
>
> A. Is there a better (i.e. safer) way to do this?
> B. How do I detect an incorrect password? I don't want to decrypt the
> information if the password that the user gives in step 4 is incorrect
> since the result after step 6 would be garbage.
>
> Thanks in advance,
> Abu Wawda
> [EMAIL PROTECTED]
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Really, easy.
Encrypt the user-file with the user's password. Store a hash of a hash
of the password with user-file. When the user logs in, this happens:
1. Alice and Bob agree a random session key to be used with some stream
cipher to secure the connection.
2. Alice sends her hashed-passwd over the link, Bob hashes this and
checks it with the stored hash. If the two match, Bob send alice's
encryted user file across the link. Alice decrypts it with her
password, on her machine.
This should solve you're above problem.
--
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] (David Wagner)
Subject: Re: Collision domain in crypt()?
Date: 26 Oct 2000 17:57:16 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Simon Johnson wrote:
>If you simply want to uniquly identify a record then its overkill. You
>would only need around 24-bits to represent all 4 million with a low
>chance of collision.
No, you would need about 44 bits. (Birthday paradox.)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: My comments on AES
Date: Thu, 26 Oct 2000 17:45:28 GMT
> It is not inconceivable that all possible ciphers have some kind of
> academic break. I'd be intensely interested in a proof (or even a
sketch
> of a proof) that it is even possible for a non-OTP cipher to be
certified
> against such breaks.
While I can offer no absolute proof, you can take the following as an
indicator that it may be true.
Take a function ct=f(key, pt) that meets our requirements for
cryptography.
If there exists a (pt,ct) pair where there exists more than one value
of key to create it then an academic attack is immediately presented
once the pair has been found, because there is a detectable bias in the
system
If there exists a (pt,ct) pair where there exists only one key to
generate it, then given that pair (pt,ct) the value of key is
immediately identifiable.
This implicitly assumes a few things about sizes being larger than 2
bits (for a binary system), and the key not being at least as large as
the plaintext.
So there you have it, given any function of 2 variable there is an
academic attack, in some cases it may very well be that it reduces the
space by 1 value for the key, or 1 value for the plaintext, but an
attack exists.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Thu, 26 Oct 2000 20:18:30 +0200
John Savard wrote:
>
> A cryptographic system is a method of transforming a plaintext P into
> a ciphertext C.
>
> There must also exist a transformation by which the ciphertext C can
> be transformed into the corresponding plaintext P in the posession of
> the legitimate recipient of the message.
>
> Hence, for any cryptographic system, there exists a method of decoding
> messages, and it is known to the legitimate recipient fo the message.
>
> Hence, any cryptographic system has a "key", even if the algorithm is
> the key in defiance of Kerckhoffs. If the existence of a key means
> that it cannot be proven that the key cannot be lost or stolen, then
> _all_ cryptosystems have the same problem as you identify for the OTP.
>
> Of course, if they ever come up with a provably-secure public-key
> system _the private key of which can be memorized_ and _the
> computations for which can be carried out in one's head_, then subject
> to the assumption that reading minds is impossible (which is a
> reasonable assumption, since if it is false, it is impossible to keep
> secrets anyways) then there would be a system to which my proof does
> not apply.
>
> I am _not_ holding my breath; even secure symmetric-key algorithms
> with memorizable keys that can be carried out mentally are highly
> unlikely to be forthcoming.
I doubt that I understand you. Is the main stress of the
above sentence on 'secure algorithm' or on 'memerizable
key' or on 'mental computation'? I don't see why mental
computation is important. (Do you means e.g. bugs on the
computer that could leak the key or computations to the
opponent and hence much or all processing has to be done
in the brain?) As to memorizable key, symmetric systems
tend not to impose requirment of too many bits. If one
could, say, remember a relatively odd sentence, or a
reference to a paragraph of a book, or some other exotic
pointer to a series of digits and the like that can
provide enough entropy for deducing the key with the aid
of a certain equally odd computation scheme (e.g.
personally invented), I don't think that the opponent has
any chance to get hold of the key. Now, if the symmetric
algorithm is only breakable via brute force (to prove that
is certainly imfeasible in the rigorous sense, I presume)
and the effort of that is way beyond the capability of
the opponent, then everything seems to be o.k., isn't it?
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
******************************
