Cryptography-Digest Digest #3, Volume #13 Thu, 26 Oct 00 04:13:00 EDT
Contents:
Re: Decrypted Secrets (Peter Koppenaal)
How do I detect invalid passwords? ([EMAIL PROTECTED])
Re: Rijndael implementations ("Trevor L. Jackson, III")
Re: How do I detect invalid passwords? (SCOTT19U.ZIP_GUY)
Re: Is OPT the only encryption system that can be proved secure? (wtshaw)
Re: Decrypted Secrets ("John A. Malley")
Re: How do I detect invalid passwords? ([EMAIL PROTECTED])
Re: Is OPT the only encryption system that can be proved secure? (SCOTT19U.ZIP_GUY)
Re: Is DES without IP/FP just as strong? (Pascal JUNOD)
Re: Hardware RNGs (Cameron)
Open Request to Dr. Kaliski, Jr. at RSA Research - looking for your ("John A.
Malley")
Re: How do I detect invalid passwords? ([EMAIL PROTECTED])
Re: On block encryption processing with intermediate permutations (Mok-Kong Shen)
Re: Storing an Integer on a stream ([EMAIL PROTECTED])
Re: Is DES without IP/FP just as strong? (Thomas Pornin)
Re: Is OPT the only encryption system that can be proved secure? (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Peter Koppenaal <[EMAIL PROTECTED]>
Subject: Re: Decrypted Secrets
Date: Thu, 26 Oct 2000 03:22:50 GMT
Thanks to both you, and a follow-up question:
What is the distinction between the dashed and solid arrows (with or
without the vertical bar prefix), as in section 2.2.2.2 second paragraph
?
I will definitely investigate the resources listed in your responses.
Thanks again,
Peter Koppenaal
"John A. Malley" wrote:
>
> John Savard wrote:
> >
> [snip backroung to question: where can one find a list explaining all
> the symbology used in Chapter 2 of Bauer's "Decrypted Secrets"]
> >
> > I think that A --> B means a mapping of set A to set B, and x |-> y
> > means that element x of a set is mapped to element y of a set. The
> > other symbols are standard; thus, in 2.2.2.1 we get "if x maps to z,
> > and y maps to z, then x is the same as y".
>
> I read it the same way. The |-> symbol represents the reduction of one
> element in one set to another element in another set. That symbol is
> used with that meaning in other books. And, A <---- B means the inverse
> of the mapping from A to B.
>
> John A. Malley
> [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: How do I detect invalid passwords?
Date: Thu, 26 Oct 2000 03:30:46 GMT
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.
------------------------------
Date: Wed, 25 Oct 2000 23:47:47 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Rijndael implementations
"Douglas A. Gwyn" wrote:
> Tim Tyler wrote:
> > C is trying to accomodate hardware variations too much.
>
> Not in the opinion of the people entrusted with developing
> the C standard.
So, is there a Hardware Compatibility List that describes the
architectures at which the the C standard is aimed?
It appears that the goal is a universally implementable language, which
goal is of course bound to cause implementation and usage problem in
applying the standard to any particular architecture.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: How do I detect invalid passwords?
Date: 26 Oct 2000 04:12:42 GMT
[EMAIL PROTECTED] wrote in <8t88h7$j7v$[EMAIL PROTECTED]>:
>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?
Yes if password is shorter than the key
why bother to hash it at all. I assume you
are saving neither the hash or the password.
Also why use something fishy like blowfish
use the approved AES cipher would impress
your boss and customers more.
>B. How do I detect an incorrect password? I don't want to decrypt the
If you really want to do this I would encrypt the password
the user entered the first time. When the user enters a password
to get his data decypt the file that has his encrypted password
if they match then his in. But I would make this a very slow
operation if he guesses wrong so that he can't sit there and guess
quickly. That is if you do it at all I think not doing anything
and giving him garbage may be best.
>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.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Wed, 25 Oct 2000 22:07:04 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> However no method that is completely repeatable is secure
> against a plain text attack. If the same key is used twice.
> One could defeat this by changing key every time or add the use
> of secret random numbers.
>
The GVA does the trick of reusing two keys and changing some values in
one. It does something no other algorithm does as well, the secret
numbers are incorporated in a retreviable manner so that they are
automatically available in decryption and need not be independently
generated. I believe that this method ranks it well between the OTP and
other algorithms taken as a class.
--
Production technology goes wrong when the producers do not
understand the users. --Patrick Whitney
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Decrypted Secrets
Date: Wed, 25 Oct 2000 22:03:57 -0700
Peter Koppenaal wrote:
>
> Thanks to both you, and a follow-up question:
>
> What is the distinction between the dashed and solid arrows (with or
> without the vertical bar prefix), as in section 2.2.2.2 second paragraph
> ?
The dashed line for the relation between the two sets of words V*
(plaintext) and W* (ciphertext) as follows
V* -----> W*
represents an injective mapping from plaintext to ciphertext,
unambiguous from right to left. For each word in the ciphertext there
is a word in the plaintext, but more than one ciphertext sting can map
back to the same plaintext string. So a character in the plaintext
alphabet for V maps to more than one character in W* There are
homophones for some of the plaintext symbols.
If the mapping is also unambiguous from left to right, then the solid
line is used as follows
V* -> W*
and it means the mapping is a function. For each plaintext there is one
ciphertext. There are no homophones. However, let's say a string P
appears in the plaintext set and it maps to the string R in the
ciphertext set. If we look for the string R in the plaintext set, it
does NOT necessarily map to the string P in the ciphertext set.
If the mapping between strings in the plaintext set and strings in the
ciphertext set is one-to-one, then the bi-directional solid line is used
as follows
V* <-> W*
and it means that every element is V* maps to one and only one element
in W*, and every element in W* maps to one and only one element in V*.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How do I detect invalid passwords?
Date: Thu, 26 Oct 2000 05:16:47 GMT
>A. Is there a better (i.e. safer) way to do this?
>
> Yes if password is shorter than the key
> why bother to hash it at all. I assume you
> are saving neither the hash or the password.
> Also why use something fishy like blowfish
> use the approved AES cipher would impress
> your boss and customers more.
You are right, I am saving neither the hash or the password. The reason
I am planning on hashing the password is because most users will NOT
enter a 16 byte password (i.e. 128-bit). Let say that the average
person uses an 8-byte password. I don't want to pad the other 8-bytes
with 0s or something else that is fixed. This would reduce the number
of possible password combinations to 64-bits. I assume the hashing will
help fix this. Is this right?
> >B. How do I detect an incorrect password? I don't want to decrypt the
>
> If you really want to do this I would encrypt the password
> the user entered the first time. When the user enters a password
> to get his data decypt the file that has his encrypted password
> if they match then his in. But I would make this a very slow
> operation if he guesses wrong so that he can't sit there and guess
> quickly. That is if you do it at all I think not doing anything
> and giving him garbage may be best.
Let's say I still use the hash, then should I:
1. Get the password from the user.
2. Hash the password.
3. Encrypt the password from step 1 (not the hash) along with the data
using the hash from step 2 as the key for the symettric cipher.
4. When the user wants to access the data, he/she will give me a
password.
5. Take the password from step 4 and hash it.
6. Use the hash to decrypt the password that I originally encrypted. If
it is the same as the password that I got from the user in step 4, I
will continue to encrypt the rest of the data. Otherwise, the password
is invalid and quit.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: 26 Oct 2000 05:43:47 GMT
[EMAIL PROTECTED] (wtshaw) wrote in <jgfunj-2510002207040001@dial-244-
002.itexas.net>:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote:
>
>
>> However no method that is completely repeatable is secure
>> against a plain text attack. If the same key is used twice.
>> One could defeat this by changing key every time or add the use
>> of secret random numbers.
>>
>The GVA does the trick of reusing two keys and changing some values in
>one. It does something no other algorithm does as well, the secret
>numbers are incorporated in a retreviable manner so that they are
>automatically available in decryption and need not be independently
>generated. I believe that this method ranks it well between the OTP and
>other algorithms taken as a class.
But the GVA does count on the individual picking some random
columns so that you don't get the same message every time you
encrypt the exact some text. So I was not talking about your type
of encryption. Which is very solid.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
Date: Thu, 26 Oct 2000 08:25:23 +0200
From: Pascal JUNOD <[EMAIL PROTECTED]>
Subject: Re: Is DES without IP/FP just as strong?
> Yes, without the IP/IP' the cipher is weak when in a CFB-m mode where
> m<64.
Never heard about such a weakness... Could you give an (academic)
reference on this ?
How weak ?
Quoting AC, "The initial permutation and the corresponding final
permutation do not affect DES's security (As near as anyone can tell,
its primary purpose is to make it easier to load plaintext and
ciphertext data into a DES chip in byte-sized pieces)".
A+
Pascal
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Pascal Junod, [EMAIL PROTECTED] *
* Laboratoire de S�curit� et de Cryptographie (LASEC) *
* INR 313, EPFL, CH-1015 Lausanne, Switzerland ++41 (0)21 693 76 17 *
* Place de la Gare 12, CH-1020 Renens ++41 (0)79 617 28 57 *
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: Cameron <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Thu, 26 Oct 2000 16:33:01 +1000
Why don't you just use soundcard input?
pipe it into a file. It should be pretty darned random.
Mark Carroll wrote:
> Can anyone recommend any relatively cheap RNG cards for Intel boxes?
> I'd like really good random numbers, so I figured that if they'd
> satisfy you guys they'd satisfy anyone. (-: I'm particularly
> interested in ones that generate numbers based on some physical
> stochastic phenomenon and where I can easily get a driver for Linux
> that gives me access to raw data coming from the card, even if it's
> meant to be 'preprocessed' for good randomness. So, a card that
> insists on doing lots of on-board digital processing itself after the
> 'random physics' step is of less interest.
>
> An obvious follow-up question regards any tips regarding easy-reading
> sources of tests for randomness. I'm happy to do the actual coding
> myself, but I would like to be able to try to test the card under
> different conditions and satisfy myself with regard to the continuing
> quality of its output.
>
> -- Mark
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Open Request to Dr. Kaliski, Jr. at RSA Research - looking for your
Date: Wed, 25 Oct 2000 23:58:29 -0700
Dr. Kaliski,
Can you help me find an electronic/on-line copy of your MIT PhD Thesis,
"Elliptic Curves and Cryptography: A Pseudorandom Bit Generator and
Other Tools", dated January 1988? I'm researching an interesting
problem in PRNG with elliptic curves and my search lead to your thesis.
Unfortunately MIT did not post an electronic copy of it. And a trip to
Boston is right out. :-)
No email address is given for you at RSA Labs, hence my appeal via this
USENET group.
Mr. Silverman, should you read this, would you be so kind as to relay my
request to Dr. Kaliski?
Thank you in advance,
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How do I detect invalid passwords?
Date: Thu, 26 Oct 2000 07:14:11 GMT
In article <8t8ens$nta$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> >A. Is there a better (i.e. safer) way to do this?
> >
> > Yes if password is shorter than the key
> > why bother to hash it at all. I assume you
> > are saving neither the hash or the password.
> > Also why use something fishy like blowfish
> > use the approved AES cipher would impress
> > your boss and customers more.
>
> You are right, I am saving neither the hash or the password. The
reason
> I am planning on hashing the password is because most users will NOT
> enter a 16 byte password (i.e. 128-bit).
This means you have 340`yadda`yadda`yadda (39 digits) possibilities.
Let say that the average
> person uses an 8-byte password. I don't want to pad the other 8-bytes
> with 0s or something else that is fixed. This would reduce the number
> of possible password combinations to 64-bits. I assume the hashing
will
> help fix this. Is this right?
So you have 1844`6744`0737`0955`1616 possibile passwords. There is no
way to get a 39-digit number of possibilities out of a 20-digit number
of possibilities.
>
> > >B. How do I detect an incorrect password? I don't want to decrypt
the
> >
> > If you really want to do this I would encrypt the password
> > the user entered the first time. When the user enters a password
> > to get his data decypt the file that has his encrypted password
> > if they match then his in. But I would make this a very slow
> > operation if he guesses wrong so that he can't sit there and
guess
> > quickly. That is if you do it at all I think not doing anything
> > and giving him garbage may be best.
>
> Let's say I still use the hash, then should I:
> 1. Get the password from the user.
> 2. Hash the password.
> 3. Encrypt the password from step 1 (not the hash) along with the data
> using the hash from step 2 as the key for the symettric cipher.
> 4. When the user wants to access the data, he/she will give me a
> password.
> 5. Take the password from step 4 and hash it.
> 6. Use the hash to decrypt the password that I originally encrypted.
If
> it is the same as the password that I got from the user in step 4, I
> will continue to encrypt the rest of the data. Otherwise, the password
> is invalid and quit.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
--
Qwertyuiop asdfghjkl zxcvbnm!!
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Thu, 26 Oct 2000 09:43:52 +0200
James Felling wrote:
>
> Bryan Olson wrote:
>
> > <snip an excellent attack vs. Mok's scheme>
>
> Mok:
>
> Now the only way I can see of this scheme working in an even remotely
> plausible way is by seperating the mixing from the feistel. This is
> only accomplishable if the feistel is unballanced, or in the case of a
> balanced feistel, if the block is divided into an odd number of pieces
> by the permuataion. Otherwise this attack applies, as one can always
> find a set of properly formed blocks to peel off a 2 round pair.
> Unfortunately most cyphers use block sizes that are power of two bits in
> size. This will limit the aplicability of this method. In addition
> such splitting will likely result in a substantial slowdown of the
> cypher. OTOH, in these cases, this attack fails, and I have trouble
> seeing an alternate line of attack. Brian?
I have made some thoughts on the line which you wrote above
but I am not sure/conclusive about my own answers since I
am only starting to comprehend the nature of the ingenious
attack devised by Bryan Olson and certainly yet lack deep
understanding of it at the current moment. Supposing one
has a 128 bit block DES-like cipher, my question is:
Would the situation be different or at least essentially
better in the following cases:
(1) the permutation unit is in word size (32 bits).
(2) the permutation unit is in block size (128 bits).
(3) the permutation unit is in double block size (526 bits).
I like to take this opportunity to thank you for a previous
post that has helped me to understand certain points of
Bryan Olson's attack.
M. K. Shen
============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Storing an Integer on a stream
Date: Thu, 26 Oct 2000 07:28:03 GMT
If you know how much padding you will use, instead of encrypting the
length of the data, encrypt the ratio of data to (data + padding), using
enough bits to remove ambiguity.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: Is DES without IP/FP just as strong?
Date: 26 Oct 2000 07:53:00 GMT
According to David C. Barber <[EMAIL PROTECTED]>:
> After all these years of analysis, has a reason ever been found for
> the initial/final permutation?
These permutations have no influence on security (since they are
easily inversed). The usual explanation is hardware-oriented: these
permutations make DES easier to plug on an 8-bit parallel bus (with
this permutation, you assemble the 64-bit data with eight 8-bit shift
registers, which is technologically easier to build than a 64-bit shift
register that must be shifted 8 times in each clock cycle).
--Thomas Pornin
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Thu, 26 Oct 2000 10:11:01 +0200
Terry Ritter wrote:
>
> The mathematically-proven OTP depends upon various assumptions which
> cannot be provably achieved in practice. And proof based on
> unprovable assumptions is ultimately no proof at all.
Very well said. Need to be repeated time and again and again.
I like to remark that that provable security means only
that the aposteriori knowledge of the opponent with the
ciphertext at hand is equal to his apriori knowledge.
However, there could be cases where the occurence of
communication (the sending of a message as such) may mean
something to the opponent, in which case the employment of
any system, including OTP, would mean leaking of some
information.
M. K. Shen
===================================
http://home.t-online.de/home/mok-kong.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
******************************
