Cryptography-Digest Digest #16, Volume #12 Tue, 13 Jun 00 07:13:01 EDT
Contents:
Re: Q: Using two DES modules (Mok-Kong Shen)
Re: Multiple encryptions (jkauffman)
Re: Finding prime numbers (Safuat Hamdy)
Re: Onefish (Twofishes sibbling) (Runu Knips)
Re: Arithmetic Coding (Runu Knips)
Re: OT: Starmath font (Runu Knips)
Re: encoding of passwords (Runu Knips)
Re: And the search is on! ("Dark Nebular")
Re: Multiple encryptions (Guy Macon)
Re: encoding of passwords (Mark Wooding)
Re: My lastest paper on Block Ciphers (Runu Knips)
Re: More papers online (David A Molnar)
Re: Is Gretchen down? (David A Molnar)
Re: encoding of passwords (Mark Wooding)
Re: Q: Using two DES modules (Mark Wooding)
Re: And the search is on! ("matt")
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Using two DES modules
Date: Tue, 13 Jun 2000 10:18:50 +0200
Mok-Kong Shen schrieb:
> Given two two DES modules and two keys, which of the following
> schemes is to be preferred, (a) in ECB and (b) in CFB?
>
> 1. Superencipherment (2DES).
>
> 2. Use one DES in full OFB for preprocessing the plaintext
> with xor before input to the other DES.
>
> 3. Use one DES in full OFB to generate keys for the other
> DES.
>
> Note that (3) needs only one key. Does the comparison gets
> changed, if the two keys of (1) or (2) are identical?
We can modify (3) to use two keys to enable a better
comparison: Use the second key for whitening just like
what is done in DESX.
M. K. Shen
------------------------------
From: jkauffman <[EMAIL PROTECTED]>
Subject: Re: Multiple encryptions
Date: Tue, 13 Jun 2000 00:57:45 -0700
I feel I must reiterate a fundamental point being missed
here. If we are encrypting data with some cipher, E, then
the details of E will be known to the attacker. Some people
have made the point that E o D might be weaker then E alone
if D is in some way similar to or the same as E. But this
implies that, for example, I could mount an attack on 3DES
simply by encrypting some 3DES ciphertext with 3DES (using a
different key). This clearly must not be the case.
* Sent from AltaVista http://www.altavista.com Where you can also find related Web
Pages, Images, Audios, Videos, News, and Shopping. Smart is Beautiful
------------------------------
From: Safuat Hamdy <[EMAIL PROTECTED]>
Subject: Re: Finding prime numbers
Date: 13 Jun 2000 10:05:53 +0200
tomstd <[EMAIL PROTECTED]> writes:
whatever you wrote in your posting, it is wrong. If you believe, that
your statements are true, cite or prove.
--
S. Hamdy | All primes are odd except 2,
[EMAIL PROTECTED] | which is the oddest of all.
|
unsolicited commercial e-mail | D.E. Knuth
is strictly not welcome |
------------------------------
Date: Tue, 13 Jun 2000 10:18:09 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Onefish (Twofishes sibbling)
tomstd wrote:
> The source is at:
>
> http://tomstdenis.com/tc4.c
>
> Have a peek, it's rather neat. I doubt it's secure so I
> wouldn't bother analyzing it (I just made it in 30 mins).
Its not portable. The values of kb[] in the key initialization
depend upon the endianness of the current architecture.
I think because you don't use the pseudo hadamard
transformation of twofish you'll run into big problems.
However, GF things still make me running away except if they
are female ;-)
------------------------------
Date: Tue, 13 Jun 2000 10:34:10 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Arithmetic Coding
Tim Tyler wrote:
> Also, the file may not be an ASCII file in the first place -
> you may not know much about what it contains at all.
If you have no such criteria, no cryptanalysis is possible
anyway; you HAVE to have some test if a result is valid or
you can't do anything with it anyway.
------------------------------
Date: Tue, 13 Jun 2000 10:52:57 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: OT: Starmath font
tomstd wrote:
> In article <[EMAIL PROTECTED]>, Runu Knips
> <[EMAIL PROTECTED]> wrote:
> >tomstd wrote:
> >> You can get the starmath True Type Font off my website at
> >> http://tomstdenis.com/files/starmath.ttf
> >Thank you, but my Windows says its corrupted :-(
>
> Hmm just pick up the ps copy of the paper then
>
> http://tomstdenis.com/ffunctions.ps.gz
Thank you Tom, I can read you paper now without problems
with Linux.
(Paper itself looks very good)
------------------------------
Date: Tue, 13 Jun 2000 11:00:57 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: encoding of passwords
[EMAIL PROTECTED] wrote:
> You should bear in mind though, the crypt(3) algorithm is a bit dated,
> and has some drawbacks, such as limiting the length of a password to
> eight characters. If you need more security than it provides, you
> might want to look into another password hashing algorithm.
Is there any serious argument against using SHA-1 or RIPE MD160 for
that ? They would have no limits at all, and AFAIK they're also much
faster than DES or Blowfish, for they're designed for just that
task, making a one way hash.
------------------------------
From: "Dark Nebular" <[EMAIL PROTECTED]>
Subject: Re: And the search is on!
Date: Tue, 13 Jun 2000 09:10:51 GMT
I'll run it, for as long as it'll take!
J. DERIVIERE ([EMAIL PROTECTED]) ICQ# :
27913909 -------------------------------------------------------------- The
SPIRITED Homepage http://www.spirited.fr.fm You can subscribe to the
SPIRITED Newsletter by sending a blank e-mail to
[EMAIL PROTECTED] ----------------------------------------
======================
tomstd <[EMAIL PROTECTED]> a écrit dans le message :
[EMAIL PROTECTED]
> Just out of curiosity, if I wrote a small Windows program that
> runs this search at IDLE priority how many people would help me
> run it?
>
> I could have the program ready for this week...
>
> Tom
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network
*
> The fastest and easiest way to search and participate in Usenet - Free!
>
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Multiple encryptions
Date: 13 Jun 2000 05:12:37 EDT
Mok-Kong Shen wrote:
>
>Does the requirement 'the keys are independent' somehow
>implicitly also involve the additional requirement 'the ciphers are
>independent in design' (which is presumably difficult to ascertain
>in the absolute sense)? For otherwise I am afraid that counter-
>example could be constructed such that a combination of two
>ciphers is weaker than a single one.
>
That was exactly my reasoning until yesterday, when I read a
post here and saw the light. Let me explain where we both went
wrong in our thinking:
Let's say that you have a good, strong cipher. Good, strong ciphers
are strong even if the attacker knows the algorithm, can select
plaintexts and have you encrypt them with your key, can intercept
your ciphertext and repalace it with his own, who knows the length
of your plaintext, and any other ability you can name except for
knowing your plaintext or your key. In fact, the best cipher creators
make it a point to supply all of the above to everyone and to encourage
knowlwdgable attackers to try to break the system. Only after many such
attacks by many people do we say that a cipher might be strong.
Keeping the above facts in mind, let's assume that a combination of the
strong cypher with another one (maybe the same one!) weakens the strong
cipher. If it does, then you can attack someone who uses the strong
cipher alone by taking his ciphertext and encrypting it with this second
cipher. Using the same key is unfair, of course - we already know that
giving the attacker the key or the plaintext "breaks" any conceivable
cipher in a trivial way, so our attacker can use the same cipher twice
but he can't do it with the same key because he doesn't know what the
key is. Thus, if the second cipher weakens the first, then the first
wasn't a strong cipher in the first place.
This is what I love about this field. Common sense tells me that I
might weaken a strong cipher by using a second cipher, but once it is
explained to me, logic tells me that my common sense was wrong.
Common sense tells me that no cipher is immune to a brute force attack
by someone with infinite resources, cleverness, and time, but once OTP
was explained to me, logic told me that my common sense was wrong.
I love it!
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: encoding of passwords
Date: 13 Jun 2000 09:16:22 GMT
Runu Knips <[EMAIL PROTECTED]> wrote:
> Is there any serious argument against using SHA-1 or RIPE MD160 for
> that ? They would have no limits at all, and AFAIK they're also much
> faster than DES or Blowfish, for they're designed for just that
> task, making a one way hash.
That's one of the OpenBSD team's arguments against using faster hashes.
They use Blowfish, with a configurable number of iterations,
specifically *because* it's slow. It makes dictionary attacks harder.
-- [mdw]
------------------------------
Date: Tue, 13 Jun 2000 11:21:39 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: My lastest paper on Block Ciphers
"Trevor L. Jackson, III" wrote:
> tomstd wrote:
> > I will try to use the latex tools in the future.
>
> Careful Tom, if you start using professional tools it will become difficult to
> claim that crypto is only a hobby. ;-)
Hmm. If one uses Linux (or any other unixlike OS), with Lyx or KLyx TeX
is a
child toy. Not much different than Word, only you have to compile at the
end -
and the output looks nicer.
> Note also that it is good practice to reserve presentation tools for polished
> products. Something you scribbled on a napkin while eating lunch should be
> presented on the original napkin, not on a bonded, watermarked paper. The rule
> is that fuzzy ideas should look fuzzy and carefully thought out ideas should
> look professional.
In the cipher contest, I still like the plain text format most. You
simply
can open a new window with the paper and start reading it.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: More papers online
Date: 13 Jun 2000 09:24:22 GMT
tomstd <[EMAIL PROTECTED]> wrote:
> If anyone has a good easy to access collection of papers please
> post the links :-)
Cryptography Research :
http://www.cryptography.com/resources/papers/index.html
Cora "Just Research" search results :
http://cora.whizbang.com/Encryption_and_Compression/Encryption/index.html
Theory of Cryptography Library :
(replaced by eprint.iacr.org, but has old papers)
http://philby.ucsd.edu/cryptolib/
International Association for Cryptologic Research eprint archive :
http://eprint.iacr.org/
The Electronic Colloquium on Computational Complexity :
(note: you can get on a mailing list to be notified of new preprints)
http://www.eccc.uni-trier.de/eccc/
and while not collections of papers alone, Helger Lipmaa, David Wagner,
and Ron Rivest have excellent collections of links that include papers.
http://www.moomin.ee/~helger/crypto/
http://www.cs.berkeley.edu/~daw/
http://theory.lcs.mit.edu/~rivest/
-dmolnar
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.firewalls,alt.privacy.anon-server,alt.privacy
Subject: Re: Is Gretchen down?
Date: 13 Jun 2000 09:09:39 GMT
In sci.crypt Tommy the Terrorist <[EMAIL PROTECTED]> wrote:
> suspicious of going through a remailer chain
> c) they let through the curious message
> d) when an e-mail other than one of theirs comes out the remailer, they
> watch where it goes, and restore the e-mail stream
FYI, you just described the "trickle attack" as it's called in Gulcu and
Tsudik's paper on Babel[1], or Kesdogan et al's paper on Stop-and-Go
MIXes[2]. I don't see any easy way to prevent it. Another poster suggested
that the Remix capability of remailers provides a defense, but I'm not
sure this works.
Remix occurs when remailer A, instead of sending a message directly to the
next hop B creates a new chain of remailers to transport the message to
B. But this just means that the adversary has a different "next" remailer
to isolate instead of B, although it will have to isolate B later as well.
If we assume that the adversary can isolate all remailers equally well,
this doesn't seem to buy us anything.
On the other hand, if some remailers can be isolated and some can not(BIG
if), then remixing raises the probability that such an
"un-isolatable" remailer enters the mix chain. Once the message passes
through such a remailer, the adversary will have to follow the entire pool
of outgoing messages to all of their destinations in order to build a list
of possible destinations for the target message.
We could even try to reason about the size of that list -- basically we
just need to know how many "un-isolatable" remailers are in the chain from
sender to receiver and how large their pools are. So we can fix a set of
remailers, pick out some of them as "un-isolatable," and then consider
what the probability of picking an un-isolatable remailer is and go from
there. Then we could try to figure out failure rates, too, by assigning
each remailer a probability of failure.
The problem is that once we start trying to deal with the real world,
life becomes dificult. In the real world, we *don't* always pick
uniformly at random from the set of remailers for our next hop. We pick
based on Frog's reliability stats, our trust in the remop, and sheer gut
instincts. So we have a picking strategy, whether we can write it down or
not...and it may not fit neatly into an analysis.
This leads to an interesting queston : what is the ideal picking strategy
for remailer hops?? It seems to me that it is the strategy which maximizes
reliability and "security," whatever "security" means.
To get back to the trickle attack, we could define "security" as
increasing as the number of "un-isolatable" nodes increases. Then the
ideal strategy would maximize the number of such "un-isolatable" nodes,
and we could try to compare strategies on this basis.
Of course, that assumes that we can tell which nodes are
"un-isolatable" and which are not, if they even exist. and that, well,
that's the big question. :-( the other big question is how to define
"security" in a way that a hop picking algorithm can maximize it.
-dmolnar
1. "Mixing E-mail with Babel"
http://www.isoc.org/conferences/ndss96/gulcu.ps
2. Stop-and-Go MIXes : Providing Probabilistic Anonymity in an Open System
Proceedings of the 1998 Info Hiding Workshop
http://link.springer.de/link/service/series/0558/bibs/1525/15250083.htm
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: encoding of passwords
Date: 13 Jun 2000 09:30:18 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> 2*12=24. So I suppose that 24 remaining bits are unaffected by
> the salt. Is that right?
I think so. HAC 10.2.3 states that bit i is paired with bit 24 + i (1 <
i < 12). I don't know whether bits 13..24 and 37..48 are left alone or
swapped too.
> Is there any literature on the effect of this modification of the
> standard DES in respect of its strength? Thanks.
I don't believe that there is. Note that this particular use of DES as
a hash function, iterated 25 times, is probably not vulnerable to
differential cryptanalysis in any particularly meaningful way.
An analysis of the effect of the salt on DES as a standard cipher would
require a careful examination of the potential interaction between the
permutation P and the modified expansion E. The expansion E provides
the ability for single bit differences out of the previous round to
affect two S-boxes in the next round. The salt permutation is performed
after the expansion E, and moves bits 24 places. The only weakness I
can think of that this might introduce is if what would normally be a
2-active-S-box difference into E is collapsed down to a single-S-box
difference by the salt permutation. I suspect that this isn't too
serious if the salt is only known; I'm not so sure that it's safe
against a chosen-salt attack.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Q: Using two DES modules
Date: 13 Jun 2000 10:32:14 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Bryan Olson schrieb:
>
> > Mok-Kong Shen wrote:
> > >
> > > Given two two DES modules and two keys, which of the following
> > > schemes is to be preferred, (a) in ECB and (b) in CFB?
> > >
> > > 1. Superencipherment (2DES).
> > >
> > > 2. Use one DES in full OFB for preprocessing the plaintext
> > > with xor before input to the other DES.
> > >
> > > 3. Use one DES in full OFB to generate keys for the other
> > > DES.
> >
> > One and two are currently intractable (no one can afford the
> > space for the time-space tradeoff).
> >
> > Three is breakable.
> >
> > What's the point?
>
> To find out whether using two DES modules would be sufficient in
> place of three DES modules as in 3DES and hope that the same
> result could be transferred to other block ciphers.
>
> I am not sure of having understood the meaining of your term
> 'breakable' in the present context.. Does your 'currently intractable'
> mean 'unbreakable' or does it mean 'breakable', or is it something
> inbetween? Could you substantiate your claim of difference between
> (1) and (2) on the one side and (3) on the other side? Many thanks
> in advance.
I'm not sure ECB vs. CFB makes a great deal of difference.
Attacking 1 requires 2^{56} work and 2^{56} storage, using the classic
meet-in- the-middle attack.
Attacking 2 is more difficult, if the IV is unknown. (If it's known you
can use a variant of MITM.) Does anyone have a good attack against
this, with secret IV?
Attacking 3 is the easiest of the bunch. Break three consecutive
message blocks (cost less than 2^{58}). You now (almost) have two
plaintext/ciphertext pairs for the OFB generator, except you're missing
8 bits from each. Guess 8 bits of the first plaintext, and search for
keys which produce the appropriate ciphertext. Verify the guess by
checking that it matches the second plaintext/ciphertext pair. Total
cost 2^{64}, with negligible storage. This reduces to 2^{57} if the OFB
IV is known (you don't need to guess plaintext bits or break as many
message blocks).
>
> M. K. Shen
>
>
> >
> > --Bryan
> > --
> > email: bolson at certicom dot com
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
-- [mdw]
------------------------------
From: "matt" <[EMAIL PROTECTED]>
Subject: Re: And the search is on!
Date: Tue, 13 Jun 2000 18:33:26 +0800
I'll run it.
"tomstd" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Just out of curiosity, if I wrote a small Windows program that
> runs this search at IDLE priority how many people would help me
> run it?
>
> I could have the program ready for this week...
>
> Tom
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion
Network *
> The fastest and easiest way to search and participate in Usenet -
Free!
>
------------------------------
** 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
******************************
