Cryptography-Digest Digest #632, Volume #10 Fri, 26 Nov 99 12:13:01 EST
Contents:
Re: EncryptedChat V2 Dead ? and dozecrypt ? ([EMAIL PROTECTED])
Re: EncryptedChat V2 Dead ? ([EMAIL PROTECTED])
Re: Why Aren't Virtual Dice Adequate? (John Savard)
Re: Why Aren't Virtual Dice Adequate? (John Savard)
Re: AES cyphers leak information like sieves (Volker Hetzer)
Re: Stretching low-entropy keys (SCOTT19U.ZIP_GUY)
Re: brute force versus scalable repeated hashing (SCOTT19U.ZIP_GUY)
Re: FEAL-8 algorithm (JPeschel)
Re: Stretching low-entropy keys ("Gary")
Re: Random Noise Encryption Buffs (Look Here) ("Douglas A. Gwyn")
Re: Cryptological discovery, rediscovery, or fantasy? ("Douglas A. Gwyn")
Re: Random Noise Encryption Buffs (Look Here) ("Douglas A. Gwyn")
Re: FEAL-8 algorithm ("Trevor Jackson, III")
Re: FEAL-8 algorithm (Volker Hetzer)
Re: AES cyphers leak information like sieves ("Douglas A. Gwyn")
Re: What part of 'You need the key to know' don't you people get? ("Douglas A. Gwyn")
FEAL-8 algorithm ("Simon Odermatt")
Re: smartcard idea? (Shawn Willden)
Re: Random Noise Encryption Buffs (Look Here) (John Savard)
Re: The Code Book (Peter Galbavy)
How safe is Mobile Phone ? ("Hank")
Re: Why Aren't Virtual Dice Adequate? (Tim Tyler)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: EncryptedChat V2 Dead ? and dozecrypt ?
Date: Fri, 26 Nov 1999 13:19:22 GMT
>
> I do plan to include an IV in dozeCrypt III - and
> I rely on dedicated users like yourself to help me
> with my implementation. Currently I use an IV of
> $7F55A304BC - but as you suggest it is constant.
>
????
You use a 40 bits IV ?? Blowfish uses 64 bits blocks, then IV should be
64 bits long.
Why a 40 bits IV ?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: EncryptedChat V2 Dead ?
Date: Fri, 26 Nov 1999 13:29:20 GMT
>
> I am a software developer - my software may be
> freeware but it's not GPLed - I wish to keep my
> actual program source code "secret" - you can
> download the RSA implementation via the Scramdisk
> page - click on "delphi" and goto GInt/Triade
> Systems from there...
>
Yes but the bugs are in your softs not in RSA implementation.
Secret source code = a lot of bugs
Users can trust secret implementations
Sorry
Regards,
Alexander
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Fri, 26 Nov 1999 13:48:28 GMT
On 26 Nov 1999 05:12:29 EST, [EMAIL PROTECTED] (Guy Macon) wrote:
>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?
I said "add" the two results: since they are in the form of decimal
digits, addition of individual digits is the equivalent of an
exclusive-OR.
For two binary streams, one can add them in groups of several bits, or
one can completely avoid carries, and exclusive-OR. But AND will not
work, since that produces a 1 in the output only when both inputs are
1.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Fri, 26 Nov 1999 13:49:28 GMT
On 26 Nov 1999 05:09:24 EST, [EMAIL PROTECTED] (Guy Macon) wrote:
>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.
Terry Ritter's web site is at
http://www.io.com/~ritter/
and does contain much that is interesting, including an extensive
glossary of cryptographic terms.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: Fri, 26 Nov 1999 15:11:38 +0100
Tim Tyler wrote:
>
> Volker Hetzer <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
>
> [block size doubling ==> work required for a break doubling?]
>
> :> Perhaps if you have some theoretical basis for this notion, you
> :> might assist me by explaining what it is.
>
> : You've got twice as much data to process.
>
> From this it follows that doubling the block size increases the work
> factor necessary for a break by two?
Well, everything else being equal.
> I'm not convinced: you also have half the number of blocks.
Two answers:
1.: That's just fine. Then, for any attack that is independent
of the block size, diffusion over more data won't give you any advantage
since a block cipher with a smaller block size will have the same
work factor. (I include this answer just for sports :-) )
2.: Seriously, you were the one saying that diffusion is good and that
we need block ciphers with variable block size to make the blocks big.
I was trying to establish an upper limit for the increase of the work factor.
If the diffusion properties of your cipher stay the same for each block size
(i.e. every bit in the plaintext block affects approximately half the
ciphertext bits) then the usual attacks (like differential) will require
the same number of blocks, hence more data for bigger block sizes.
I can't prove this but from what I read so far this is my impression.
> Anything
> that works by comparing blocks will have half as many blocks to work on.
The question is rather, how much blocks you need.
If you have dictionary attacks in mind, then you DO need to store twice
amount of data.
For any attack that requires a fixed number of blocks, you need twice
as much data to compare or store.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Stretching low-entropy keys
Date: Fri, 26 Nov 1999 15:03:25 GMT
In article <81loru$4vc$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>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.
>
I have not read there paper. But not reading has never stopped Mr BS or
Wagner form commenting on my code. So I put it to you this way If you
start with 32 bits and expand to 128 buts. You still only have a 32 bit key.
Maybe this is how the big boys ship crypto to get around key length
limitations. From what little your saying it sounds like it would be far safer
to have a system that has thousands of bits for a key and then hash it done
to 128 bits if one wants 128 bits of security. But then again I am not sure
Mr BS or Wagner really cares if people use secure encryption systems.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.security.misc
Subject: Re: brute force versus scalable repeated hashing
Date: Fri, 26 Nov 1999 15:20:34 GMT
In article <[EMAIL PROTECTED]>, Juergen Thumm
<[EMAIL PROTECTED]> wrote:
>
>--------------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
This whole concept is a very bad idea for creating a key. If Mr BS
and his buddies support something like this they most think people have
oat meal for brains. One should never use any deterministic means
like this one to get a large key if one want to take advantage of a large
keyspace. It would be best to get as large a source of random data as
possible and then try to some what secure it with a password much like
the way PGP encyrpts its secret keys. If you have a large random key and
then you protect it with your passpharse this file is the only one protected
by the short key. But the big key that it protects is what you are using for
the real encryption and with it you can use all the possible keybits
available for the encryption system of your choice. For example in scott19u
you have over a million bytes of key space. You can carfully or not so care
fully construct the key or random S-table of your choice and then protect
that file in "keyenc.key" the protected key file. This way when you run
the code and you enter your phase phrase. Th pharse its self is a low
entropy key that was used to encrypt the key that you actually going to
use. An enemy intecepting a message and having the source could would
have far more to do that guessing you pass phrase he has to guess the
full key and it is "MILLIONS OF BITS LONGER" than any of the AES methods.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: FEAL-8 algorithm
Date: 26 Nov 1999 15:00:35 GMT
[EMAIL PROTECTED] writes:
>I'm sorry, I can't choose another algorithm. It's given by the customer.
Then, because of FEAL-8's weaknesses, perhaps you should
dissuade your customer from using it.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Stretching low-entropy keys
Date: Fri, 26 Nov 1999 15:09:06 -0000
I think you'll find that Counterpane always advocate large randomly
generated keys over stretching.
However stretching is useful for entropy problems and export restrictions.
The fact you haven't even bothered to read the papers on this subject let
alone this thread's question (in relation to entropy) comes as no surprise.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Fri, 26 Nov 1999 14:28:25 GMT
Tim Tyler wrote:
> I feel it's far from easy. Generating "genuinely" secure random numbers
> is not even known to be possible.
It's not *trivial*, and may not be "known" to amateurs, but
we do it all the time. There are commercial crypto chips that
implement this function (among other, more important functions).
------------------------------
Crossposted-To: sci.math,sci.misc,alt.privacy
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cryptological discovery, rediscovery, or fantasy?
Date: Fri, 26 Nov 1999 14:32:38 GMT
DSM wrote:
> What good is an unbreakable cipher system if your
> enemy is capable of capturing you and gaining
> the key from you by force? Most humans will surrender
> a password if placed under duress. In fact, this is
> one of the most frequent ways in which encryption is
> compromised.
No, it isn't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Fri, 26 Nov 1999 14:30:42 GMT
"M. Okra" wrote:
> Real chaos, as you know, is a little tricky to replicate.
"Chaotic" behavior, in its mathematical meaning, is not random.
------------------------------
Date: Fri, 26 Nov 1999 10:43:50 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: FEAL-8 algorithm
Simon Odermatt wrote:
> I'm sorry, I can't choose another algorithm. It's given by the customer.
If your customer is mandating the use of a broken crypto algorithm, you
should probably find another customer. The reasoning mehind this suggestion
is that if they are silly enough to use broken crypto they may have other
silly habits like not paying their vendors. Also, whether the customer
demanded it or not, your name will be linked to the final product as the
implementor. Thus your name will be tainted to the extent that the weakness
of the product becomes known.
>
>
> 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: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: FEAL-8 algorithm
Date: Fri, 26 Nov 1999 16:46:47 +0100
Simon Odermatt wrote:
>
> I'm sorry, I can't choose another algorithm. It's given by the customer.
Then, as a responsible business partner you should make sure your customer
knows that FEAL-8 is completely insecure and that he wants you to
implement it DESPITE of its problems.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: Fri, 26 Nov 1999 14:37:36 GMT
"SCOTT19U.ZIP_GUY" wrote:
> But CFB allows one to use a partial
> block at the end is less problem with block length.
You need to demonstrate that there *is* a problem with
"partial blocks". Take any respected block cipher,
assume *all* the plaintext except for the first bit
is known, and demonstrate solution for the unknown
bit without using knowledge of the key. That would
be a result worthy of publication.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Fri, 26 Nov 1999 14:49:07 GMT
Tim Tyler wrote:
> ... I used "IV" to refer to the initial value used as the
> cyphertext of the block before the first one available.
Please don't do that. "IV" is a standard acronym for
"initialization vector" and is used only with the first
block.
------------------------------
From: "Simon Odermatt" <[EMAIL PROTECTED]>
Subject: FEAL-8 algorithm
Date: Fri, 26 Nov 1999 16:06:29 GMT
Thanks for your links. I found for what I was looking for.
TomJefries <[EMAIL PROTECTED]> schrieb in im Newsbeitrag:
[EMAIL PROTECTED]
> The FEAL-8 Algorith is described in Chapter 7 of The Handbook of Applied
> Cryprography by Alfret J. Menezes. See
http://www.cacr.math.uwaterloo.ca/hac/
> for an online copy. You can get a C-Language copy of the FEAL-8 algorithm
from
> Pate Williams at http:///www.mindspring.com/~pate/.
------------------------------
Date: Fri, 26 Nov 1999 09:07:08 -0700
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: smartcard idea?
> >Craig Inglis schrieb:
> >>
> >> I wonder what it would cost to design a credit card sized smartcard
> >> with a numeric keypad, a little LCD display, and a processor
> >> powerful enough to a 2048bit modular exponentiation?
That much hardware isn't necessary, IMO. The PIN pad and display can be on
the ATM rather than the card as long as (1) the card can authenticate the ATM
and (2) the card can communicate the result of that authentication to the
user.
(2) can be accomplished by embedding an LED in the card which can be turned on
and off by the smart card microprocessor. (1) can be accomplished through
shared triple-DES keys. The keys stored on the card should be derived and
changed periodically, of course.
In practice, we would probably forgo the LED because in a smart card-based
scheme the PIN would only be known to the card and the holder, meaning the PIN
is completely useless without the card. A bogus ATM that grabbed peoples
cards would get noticed and shut down in a hurry.
Of course, the authentication of the card to the ATM or network could also be
accomplished with shared triple-DES keys -- no need for a large-integer
coprocessor.
Shawn.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Fri, 26 Nov 1999 16:19:03 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>Tim Tyler wrote:
>> I feel it's far from easy. Generating "genuinely" secure random numbers
>> is not even known to be possible.
>It's not *trivial*, and may not be "known" to amateurs, but
>we do it all the time. There are commercial crypto chips that
>implement this function (among other, more important functions).
If indeed generating "random" numbers that can't be guessed is
something that requires NSA-developed technology...
I wish to congratulate you both on winning next week's PowerBall draw.
Effectively guessing the next number in a sequence of numbers produced
from the conventional physical randomizers commonly used, such as
dice, or better, a drawing of lots or a roulette wheel, is
_definitely_ not known, or even suspected, of being possible.
Generating such numbers in quantity with electronics that can fit on a
microchip is more difficult, and _that_ is something that the NSA of
course would know how to do rather better than those on the outside.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Peter Galbavy)
Subject: Re: The Code Book
Date: 26 Nov 1999 16:31:45 GMT
Reply-To: [EMAIL PROTECTED]
In article <81kblh$ge9$[EMAIL PROTECTED]>, @li wrote:
>Where can I find the Code Book?
It is available in most UK book shops in hard back. If it not
published in the US then amazon.co.uk should find it at least.
I got a signed copy in Gatwick Airport "Books Etc." of all places.
Very good book BTW. Nice companion to Bruce's Applied Cryptography.
Regards,
--
Peter Galbavy
Knowledge Matters Ltd
http://www.knowledge.com/
------------------------------
From: "Hank" <[EMAIL PROTECTED]>
Subject: How safe is Mobile Phone ?
Date: Sat, 27 Nov 1999 00:45:14 +0800
I am curious if the mobile phone system uses any data encryption mechanism.
For example, if the handshaking process is not encrypted, someone might
easily intercept the ID of my phone and forge it to make a fake call. And
if the communicaion is not encrypted, someone can easily eavesdrop on
my conversation with friends. Are these all true ?
------------------------------
Crossposted-To: sci.math
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Why Aren't Virtual Dice Adequate?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 26 Nov 1999 16:51:09 GMT
In sci.crypt John Savard <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote, in part:
:>In sci.crypt John Savard <[EMAIL PROTECTED]> wrote:
:>: However, in practice, random numbers derived from throwing dice or
:>: flipping coins are adequate for producing secure one-time-pads.
:>Really? How do you judge how secure they are?
: If the output is _unbiased_, few other problems are likely.
Bias was my primary concern:
How can you make an unbiased die? If you make one, how can you be certain
it will not pick up dust? What makes you certain it is so uniform it will
be immue to thermal fluctuatiuons? Do you control the temperature of the
environment? Or try for a dice that can retain its lack of bias over a
range of temperatures? In what environment do you roll your dice?
Is the dice likely to be struck by cosmic rays, that cause it to gain
or lose matter from its surfaces? How far is the rolling arm from the
flat surface. Does the arm pick the dice up as it fell before rolling it
again? Does it shake the dice? Before rolling it? For how long?
: 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.
Adding two biased results produces an unbiased one? You may well be
making the problem smaller, but you are not making it vanish.
Besides, I thought in practice, "random numbers derived from throwing dice
or flipping coins are adequate for producing secure one-time-pads." -
surely you should not need a whole roulette wheel...? ;-)
Of course, roulette wheels are not random either. See the book
"The Newtonian Casino" for details of this...
:>What do you make of Terry Ritter's thoughts on the unattainability of
:>demonstrably secure OTPs in practice?
: I don't feel constrained to _demonstrate_ that such a thing is secure.
: There are many things we don't understand well enough to prove, even
: if they're obviously true.
It is not obviously true to me that a source of randomness sufficiently
good for making secure OTPs is available. All methods of extracting
entropy from the environment seem potentially flawed in one way or
another to my eyes.
: But I will admit that it is difficult to be sure that something using
: thermal resistor noise isn't being contaminated by electrical
: interference.
Yes. Approaches using magnifying quantum events seem to me to hold
most promise. However, AFAICS, these are also far from perfect today.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
...now, if you'll just touch these wires with your tongue...
------------------------------
** 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
******************************
