Cryptography-Digest Digest #631, Volume #10 Fri, 26 Nov 99 08:13:01 EST
Contents:
Re: Why Aren't Virtual Dice Adequate? (Guy Macon)
Re: Why Aren't Virtual Dice Adequate? (Guy Macon)
Stretching low-entropy keys ([EMAIL PROTECTED])
Re: Ask about Certification-less Public Key ("PIPE Wong")
brute force versus scalable repeated hashing (Juergen Thumm)
Re: Stretching low-entropy keys ("Gary")
Re: FEAL-8 algorithm ("Simon Odermatt")
Re: Ask about Certification-less Public Key (Shahrokh Saeednia)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: 26 Nov 1999 05:09:24 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Tyler) wrote:
>What do you make of Terry Ritter's thoughts on the unattainability of
>demonstrably secure OTPs in practice?
Are these on the web somewhere? I would like to read them.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: 26 Nov 1999 05:12:29 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (John Savard)
wrote:
>I'm not averse to a little post-processing. Encrypt the output of a
>roulette wheel, and the output of a 10-sided die, by different
>methods, and then add the two results. That should satisfy any
>reasonable concern about an exploitable imperfection.
I was under the impression that exclusive-ORing was preferred
to ANDing. Did I misunderstand?
------------------------------
From: [EMAIL PROTECTED]
Subject: Stretching low-entropy keys
Date: Fri, 26 Nov 1999 10:53:50 GMT
hello all,
need your comments on the following.
with reference to a paper on www.counterpane.com "Secure applications
of low-entropy keys" by John kelsey, Bruce schneier, Chris hall and
David Wagner.they speak of key stretching by using a function H()
(possibly a hash function or otherwise) for stretching a s-bit key to l
bits (long key) by adding a salt of t bits and then iterating to create
l-bit key- a long key.
Here a question still arises if we have really increased with the key
space by t-bits. b'cos still a interceptor may do a key search on s-bits
key space and carry on the same iteration as above to create a l-bit key
for a brute force attack! Assuming that the algorithm is available after
implementation as well as the scheme for selecting the salt.
we understand that we are performing key stretching with the aim of
increasing the security of an algorithm by increasing the length of
given short key.. (refer paper).
So can we argue otherwise from the paper?
-thanking in advance,
rasane_s.
ps. need comments for incorporating such a scheme.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "PIPE Wong" <[EMAIL PROTECTED]>
Subject: Re: Ask about Certification-less Public Key
Date: Fri, 26 Nov 1999 18:38:08 +0800
Sorry for the confusing word in the past post. Finally I found better words
for what I want.
"An Identity-Based Cryptosystem"
and I've found RFC 1824 is about this kind of cryptosystem.
thanks Mark ;)
PIPE
PIPE Wong <[EMAIL PROTECTED]> wrote in message
news:81l6uh$[EMAIL PROTECTED]...
> Does anyone know about Certification-less Public key? I'm searching for
> information on it.
>
> All I know about certification-less is that we can use a Third Trusted
> Party's public key to verify a user's public key instead of verifying the
> certificate. In other words, no public key certificate is needed.
>
> The scheme seems to me that the Third Trusted Party need to generate the
> keypair for the user rather than user generates the keypair on his own and
> presents the CA with the public key.
>
> Can anyone give me more information on that kind of scheme??
>
> Thanks
>
> PIPE
>
>
>
------------------------------
From: Juergen Thumm <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: brute force versus scalable repeated hashing
Date: Fri, 26 Nov 1999 13:19:06 +0100
==============FE30C1B9923DC992A418BBCE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
to encrypt data by use of a passphrase and a symmetric cipher,
it is common practice to build an md5 or sha hash from the
passphrase, and use this as key material for the symmetric cipher.
applying just md5 on the passphrase, we get a 16-byte
hash output, which is sufficient, e.g. as key material for 128-bit rc4.
cracking this with brute-force is, however, relatively easy.
RFC 1810 assumes that an MD5 implemented in pure hardware
could hash 256 Mbps per second, or 32 Megabytes.
assuming an 8-character passphrase, this means a hardware-md5
could hash 4,194,304 passphrases per second;
if the passphrase is expected to contain only a-z and 0-9,
it's 2.82e+12 combinations to check;
the idealistic hardware md5 could do this in 6.72e+5 seconds,
that's approximately one week.
this scenario is a worst-case simplification - from the encryptor's
view - but even if the cracking takes a month, it's still not
allto much.
for this reason, open bcrypt v 1.5 implements scalable
repeated passphrase hashing: the passphrase is not hashed
just once, but thousands of times. not using only md5,
but md5, sha, and a simple mathematical combination of the
intermediate results.
this requires more time both on the encrypting machine
and the attacker's system.
open bcrypt performs as many hashing rounds as the encrypting
machine can do within 500 milliseconds;
this mechanism reduces the effort of brute-force cracking
to what it should be:
the pure difference in hardware power available
to the encryptor and the attacker.
the repeated passphrase hashing, as implemented in open bcrypt,
is now discussed in detail. the source-code can be found under
http://members.tripod.de/privacy/bcryptext.htm#bin
method 'keyFromSecret'
abstract:
creates a 16- or 32-byte output block, usable as
key/IV material, from an arbitrary-length input,
like a passphrase, or a random data block.
this process involves repeated hashing
to slow down brute-force tries at a scalable rate.
to assure that the entropy amount of the input data
is not reduced, the input data ('secret') itself
is also included in every hashing step.
input:
- byte block named 'secret', e.g. a passphrase
- minimum number of iterations
- maximum time to iterate
pseudocode:
md5_1 = md5(secret)
sha_1 = sha(secret)
n = max(min_number_of_iterations, maximum_time)
// don't mind the types, this is pseudocode.
for (i = 1 to n)
{
mix_0 = mathHash(md5_i, sha_i, 0)
mix_1 = mathHash(md5_i, sha_i, 1)
mix_2 = mathHash(md5_i, sha_i, 2)
...
mix_7 = mathHash(md5_i, sha_i, 7)
md5_i+1 = md5(mix_0, mix_1, ..., mix_2, secret)
sha_i+1 = sha(mix_0, mix_1, ..., mix_2, secret)
}
mix_0 = mathHash(md5_i, sha_i, 0)
mix_1 = mathHash(md5_i, sha_i, 1)
mix_2 = mathHash(md5_i, sha_i, 2)
...
mix_7 = mathHash(md5_i, sha_i, 7)
md5_k = md5(mix_0, mix_1, ..., mix_2, secret)
sha_k = sha(mix_0, mix_1, ..., mix_2, secret)
md5_material = concat(md5_i, md5_k) // -> 32 bytes total
sha_material = concat(sha_i, sha_k) // -> 40 bytes total
sha_material is truncated to 32 bytes.
material = md5_material xor sha_material
mathHash:
abstract:
this method mixes an md5 and an sha digest together
using simple mathematical/boolean operations,
into a 16-byte output block.
sense of this is to have an additional intermediate
operation to the pure repeated md5/sha hashing
during the keyFromSecret() process,
to make it slightly more difficult building this
process in hardware.
input:
- 16 bytes md5_material
- 20 bytes sha_material
- operation 'op'
pseudocode (reduced):
16_bytes_output = md5_material op sha_material
pseudocode (detail):
for (i = 0 to 20)
{
// i is a byte index
byte b1 = md5_material[i % 16]
byte b2 = sha_material[i]
switch (op)
{
case 0: b3 = (b1 + b2) OR carry
case 1: b3 = b1 xor b2
case 2: b3 = (b1 * b2) XOR carry
case 3: b3 = b1 OR b2
case 4: b3 = b1 AND b2
case 5: b3 = (b1 - b2) XOR underflow
case 6: b3 = (b2 - b1) XOR underflow
}
output[i % 16] = b3
}
how long would it take to brute-force crack this repeated hashing
scheme?
as an example, the following assumptions are made:
- the encryptor uses a 166 MHz pentium system for encryption,
making 3000 hashing rounds within 500 msec
- the encryptor uses an 8-character passphrase
built from a-z and 0-9 characters
- the attacker uses MD5 hashing hardware as mentioned in RFC 1810
- the attacker uses SHA hashing hardware operating at
the same speed as MD5
- the mathHash takes nearly no time at all
then it would take, at a *constant* speed of today's hardware
throughout the future, 1000 years to test halve of the possible keys.
for the calculation in detail, see
http://members.tripod.de/privacy/cracking.txt
expecting that the hardware speed doubles every year, however,
data encrypted with above scheme will resist approx. 10 years.
more than nothing, less than unbreakable - at least,
open bcrypt gives an idea of what it can supply and what not,
in contrast to most other tools.
greetings,
Juergen Thumm
--
[jthumm(@)lycosmail.com] http://go.to/bcrypt
address altered to deflect spam.
==============FE30C1B9923DC992A418BBCE
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
to encrypt data by use of a passphrase and a symmetric cipher,
<br>it is common practice to build an md5 or sha hash from the
<br>passphrase, and use this as key material for the symmetric cipher.
<p>applying just md5 on the passphrase, we get a 16-byte
<br>hash output, which is sufficient, e.g. as key material for 128-bit
rc4.
<p>cracking this with brute-force is, however, relatively easy.
<br>RFC 1810 assumes that an MD5 implemented in pure hardware
<br>could hash 256 Mbps per second, or 32 Megabytes.
<p>assuming an 8-character passphrase, this means a hardware-md5
<br>could hash 4,194,304 passphrases per second;
<br> if the passphrase is expected to contain only a-z and 0-9,
<br>it's 2.82e+12 combinations to check;
<br> the idealistic hardware md5 could do this in 6.72e+5 seconds,
<br>that's approximately one week.
<p>this scenario is a worst-case simplification - from the encryptor's
<br>view - but even if the cracking takes a month, it's still not
<br>allto much.
<p>for this reason, open bcrypt v 1.5 implements scalable
<br>repeated passphrase hashing: the passphrase is not hashed
<br>just once, but thousands of times. not using only md5,
<br>but md5, sha, and a simple mathematical combination of the
<br>intermediate results.
<br> this requires more time both on the encrypting machine
<br>and the attacker's system.
<br> open bcrypt performs as many hashing rounds as the encrypting
<br>machine can do within 500 milliseconds;
<p>this mechanism reduces the effort of brute-force cracking
<br>to what it should be:
<p>the pure difference in hardware power available
<br>to the encryptor and the attacker.
<p>the repeated passphrase hashing, as implemented in open bcrypt,
<br>is now discussed in detail. the source-code can be found under
<br><A
HREF="http://members.tripod.de/privacy/bcryptext.htm#bin">http://members.tripod.de/privacy/bcryptext.htm#bin</A>
<br>
<br>
<p>method 'keyFromSecret'
<p> abstract:
<p> creates a 16- or 32-byte output block, usable as
<br> key/IV material, from an arbitrary-length input,
<br> like a passphrase, or a random data block.
<br> this process involves repeated hashing
<br> to slow down brute-force tries at a scalable rate.
<br> to assure that the entropy amount of the input data
<br> is not reduced, the input data ('secret') itself
<br> is also included in every hashing step.
<p> input:
<p> - byte block named 'secret', e.g. a passphrase
<br> - minimum number of iterations
<br> - maximum time to iterate
<p> pseudocode:
<p><tt> md5_1 = md5(secret)</tt>
<br><tt> sha_1 = sha(secret)</tt><tt></tt>
<p><tt> n = max(min_number_of_iterations, maximum_time)</tt>
<br><tt> // don't mind the types, this is pseudocode.</tt><tt></tt>
<p><tt> for (i = 1 to n)</tt>
<br><tt> {</tt>
<br><tt> mix_0 = mathHash(md5_i, sha_i, 0)</tt>
<br><tt> mix_1 = mathHash(md5_i, sha_i, 1)</tt>
<br><tt> mix_2 = mathHash(md5_i, sha_i, 2)</tt>
<br><tt> ...</tt>
<br><tt> mix_7 = mathHash(md5_i, sha_i, 7)</tt>
<br><tt> </tt>
<br><tt> md5_i+1 = md5(mix_0, mix_1, ...,
mix_2, secret)</tt>
<br><tt> sha_i+1 = sha(mix_0, mix_1, ...,
mix_2, secret)</tt>
<br><tt> }</tt><tt></tt>
<p><tt> mix_0 = mathHash(md5_i, sha_i, 0)</tt>
<br><tt> mix_1 = mathHash(md5_i, sha_i, 1)</tt>
<br><tt> mix_2 = mathHash(md5_i, sha_i, 2)</tt>
<br><tt> ...</tt>
<br><tt> mix_7 = mathHash(md5_i, sha_i, 7)</tt>
<br><tt> </tt>
<br><tt> md5_k = md5(mix_0, mix_1, ..., mix_2, secret)</tt>
<br><tt> sha_k = sha(mix_0, mix_1, ..., mix_2, secret)</tt><tt></tt>
<p><tt> md5_material = concat(md5_i, md5_k)
// -> 32 bytes total</tt>
<br><tt> sha_material = concat(sha_i, sha_k)
// -> 40 bytes total</tt><tt></tt>
<p><tt> sha_material is truncated to 32 bytes.</tt><tt></tt>
<p><tt> material = md5_material xor sha_material</tt>
<br>
<p>mathHash:
<p> abstract:
<p> this method mixes an md5 and an sha digest together
<br> using simple mathematical/boolean operations,
<br> into a 16-byte output block.
<br> sense of this is to have an additional intermediate
<br> operation to the pure repeated md5/sha hashing
<br> during the keyFromSecret() process,
<br> to make it slightly more difficult building this
<br> process in hardware.
<p> input:
<p> - 16 bytes md5_material
<br> - 20 bytes sha_material
<br> - operation 'op'
<p> pseudocode (reduced):
<p><tt> 16_bytes_output = md5_material op sha_material</tt>
<p> pseudocode (detail):
<p><tt> for (i = 0 to 20)</tt>
<br><tt> {</tt>
<br><tt> // i is a byte index</tt><tt></tt>
<p><tt> byte b1 = md5_material[i % 16]</tt>
<br><tt> byte b2 = sha_material[i]</tt><tt></tt>
<p><tt> switch (op)</tt>
<br><tt> {</tt>
<br><tt> case 0: b3 = (b1
+ b2) OR carry</tt>
<br><tt> case 1: b3 = b1
xor b2</tt>
<br><tt> case 2: b3 = (b1
* b2) XOR carry</tt>
<br><tt> case 3: b3 = b1
OR b2</tt>
<br><tt> case 4: b3 = b1
AND b2</tt>
<br><tt> case 5: b3 = (b1
- b2) XOR underflow</tt>
<br><tt> case 6: b3 = (b2
- b1) XOR underflow</tt>
<br><tt> }</tt><tt></tt>
<p><tt> output[i % 16] = b3</tt>
<br><tt> }</tt>
<br>
<p>how long would it take to brute-force crack this repeated hashing scheme?
<br>as an example, the following assumptions are made:
<p> - the encryptor uses a 166 MHz pentium system for
encryption,
<br> making 3000 hashing rounds within 500
msec
<p> - the encryptor uses an 8-character passphrase
<br> built from a-z and 0-9 characters
<p> - the attacker uses MD5 hashing hardware as mentioned
in RFC 1810
<p> - the attacker uses SHA hashing hardware operating
at
<br> the same speed as MD5
<p> - the mathHash takes nearly no time at all
<p>then it would take, at a *constant* speed of today's hardware
<br>throughout the future, 1000 years to test halve of the possible keys.
<p>for the calculation in detail, see <A
HREF="http://members.tripod.de/privacy/cracking.txt">http://members.tripod.de/privacy/cracking.txt</A>
<p>expecting that the hardware speed doubles every year, however,
<br>data encrypted with above scheme will resist approx. 10 years.
<p>more than nothing, less than unbreakable - at least,
<br>open bcrypt gives an idea of what it can supply and what not,
<br>in contrast to most other tools.
<p>greetings,
<br> Juergen Thumm
<p>--
<br>[jthumm(@)lycosmail.com]
<A HREF="http://go.to/bcrypt">http://go.to/bcrypt</A>
<br>address altered to deflect spam.
<br> </html>
==============FE30C1B9923DC992A418BBCE==
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Stretching low-entropy keys
Date: Fri, 26 Nov 1999 12:28:08 -0000
Think of it in terms of the time it takes to check each possible variation
of key.
If each combination of a 32 bit key takes a cycle to check then a 200 MHz
Pentium could do every combination in 4000M/200M=40/2=20 Seconds.
Stretch the key by 24 bits and that becomes 20*16M=320 Million Seconds.
Encryption/Decryption algorithms can be made to be time consuming to obtain
the same effect.
------------------------------
From: "Simon Odermatt" <[EMAIL PROTECTED]>
Subject: Re: FEAL-8 algorithm
Date: Fri, 26 Nov 1999 12:42:45 GMT
I'm sorry, I can't choose another algorithm. It's given by the customer.
Tom St Denis <[EMAIL PROTECTED]> schrieb in im Newsbeitrag:
81k4t8$3fh$[EMAIL PROTECTED]
> In article <rXc%3.226$U67.151809@news>,
> "Simon Odermatt" <[EMAIL PROTECTED]> wrote:
> > Hello
> >
> > For my work I require FEAL-8. Does anybody has a code in C for
> encrypt and
> > decrypt messages?
> > Does anybody has an example of a decrypt text and the encrypt text?
> >
> > Thanks for your answers.
> > Simon Odermatt
>
> Please tell me the name of the project your are working on... so I can
> learn to avoid it.
>
> FEAL has been masacred by many people, over and over and over. Why not
> just use a Vinegere cipher and call it a OTP?
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Shahrokh Saeednia <[EMAIL PROTECTED]>
Subject: Re: Ask about Certification-less Public Key
Date: Fri, 26 Nov 1999 13:48:48 +0100
As far as I know, there is no known identity-based cryptosystem, and the
existance of such cryptosystems seems to be an open problem. Identity-based
identification and signature schemes, as well as identity-based key distribution
protocols, however, exist.
Shahrokh
PIPE Wong wrote:
> Sorry for the confusing word in the past post. Finally I found better words
> for what I want.
>
> "An Identity-Based Cryptosystem"
>
> and I've found RFC 1824 is about this kind of cryptosystem.
>
> thanks Mark ;)
>
> PIPE
>
------------------------------
** 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
******************************
