Cryptography-Digest Digest #346, Volume #14 Sun, 13 May 01 01:13:00 EDT
Contents:
Re: __Security Architect/Consultant wanted at HONG KONG ("Sam Simpson")
Re: Key escrow based on BBS ("Tom St Denis")
Re: __Security Architect/Consultant wanted at HONG KONG ("Tom St Denis")
Secure 'talk'? ("Harris Georgiou")
Re: Secure 'talk'? (Paul Rubin)
Re: DES Crypto Myth?? (David Wagner)
Re: Are low exponents a problem with RSA? (David Wagner)
Re: Comparison of Diff. Cryptanalysis countermeasures (David Wagner)
Re: Borg(warner) and Boeing? (John Savard)
Re: DES Crypto Myth?? (DJohn37050)
Re: DES Crypto Myth?? ([EMAIL PROTECTED])
Re: Comparison of Diff. Cryptanalysis countermeasures ([EMAIL PROTECTED])
Re: A simple encryption algorithm based on OTP (David Formosa (aka ? the Platypus))
Re: Is Differential Cryptanalysis practical? ([EMAIL PROTECTED])
Re: Comparison of Diff. Cryptanalysis countermeasures ([EMAIL PROTECTED])
Re: DES Crypto Myth?? ([EMAIL PROTECTED])
Re: Borg(warner) and Boeing? (Darren New)
Noekeon sbox design? ("Tom St Denis")
Re: Best encrypting algoritme ("John A. Malley")
----------------------------------------------------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: __Security Architect/Consultant wanted at HONG KONG
Date: Sat, 12 May 2001 23:33:26 +0100
Tom,
Don't feed the trolls dude............................................
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Key escrow based on BBS
Date: Sat, 12 May 2001 22:43:48 GMT
"Jeffrey Walton" <[EMAIL PROTECTED]> wrote in message
news:3afd9e36$0$[EMAIL PROTECTED]...
> It looks a little like El Gama, and a little like Rabin. I've always kind
> of viewed Rabin as a particular implementation of El Gamal, with exponent
2.
> (Please forgive my ignorance)
>
> I'm not sure what using the lower ln(ln(N)) bits would do.
May I suggest you read more? My KeyEscrow scheme is neither Rabin or
ElGamal. If anything it's BBS+DH.
You use DH to share a secret key between users and the BBS generator so that
the host can snoop too.
Tom
>
> Jeff
>
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:zraL6.73275$[EMAIL PROTECTED]...
> I was wondering after all the Key Escrow debackle in the mid 90s has
anyone
> suggested this trivial solution?
>
> 1. Host makes a blum integer N and publishes it along with a large prime
p,
> and primitive element in Z*p called g.
> 2. Each user picks their own large integer x (which is secret) and
> publishes y = g^x mod p
>
> Now I want to send a message to a user I do
> 1. Make a random k and compute y' = g^k mod p. I send y' to the user
> 2. I use K = y^k mod p, as my BBS seed.
> 3. I encode the message using the lower lg lg N bits xor'ed against the
> plaintext. i.e K = K^2 mod N and use the lower bits of K
> 4. I perform another squaring e.g. K = K^2 mod N and store K along with
the
> stream.
>
> Presuming that both factoring and discrete logs are hard with only g^k mod
p
> an attacker will not know the seed and with only the last K value an
> attacker cannot find the square root of K modulo N.
>
> The legitimate reader knows 'x' and can compute K from y' as y'^x mod p.
> Thus they can read the message. The host however knows the factors of N
and
> can easily work it backwards and obviously read the message too. Voila
> instant key escrow.
> --
> Tom St Denis
> ---
> http://tomstdenis.home.dhs.org
>
>
>
>
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: __Security Architect/Consultant wanted at HONG KONG
Date: Sat, 12 May 2001 22:44:39 GMT
"Sam Simpson" <[EMAIL PROTECTED]> wrote in message
news:9UiL6.14595$[EMAIL PROTECTED]...
> Tom,
>
> Don't feed the trolls dude............................................
Sorry .... it was funny though right?
Tom
------------------------------
From: "Harris Georgiou" <[EMAIL PROTECTED]>
Subject: Secure 'talk'?
Date: Sun, 13 May 2001 02:07:25 +0300
Eavesdropping question:
I stumbled onto a simple program for 'talk' with encrypted comms. The idea
is to use simple binary en/decryption functions like XORs and ROLs with
64-bit blocks to avoid direct eavesdropping over the net. The exact
functions used are really not important, the most interesting issue is that
the communication starts with a pre-determined secret key which is the seed
to a 64-bit random function. For every message a new "random" 64-bit key is
created, part of which is used for the encryption mode (sub-function
selections) and part for the actual key, so we have a mutable-key,
mutable-function encryption scheme.
Also, each for message sent a MD5-like signature is calculated by the sender
and by the receiver, so that the sender can compare his signature with the
one that receives as a reply by the other part (maybe as a basic mechanism
for comms integrity check?).
Given the key size (64-bit) and the mutable keys/functions, the question is
how easy it is for someone to tap into the session and recover all plaintext
message traffic (after some trials)? In other words, how easy it is for the
initial key randomizer seed to be discovered only from the ciphertext
message traffic? I guess a look-up table with the first few values of the
random function would be effective enough, but with 64-bit values (and a
good distribution) it is really not so easy.
PS: Random function is of standard form: X(n+1)=[a*X(n)+c]mod[m] and
en/decryption functions are all binary (combinations of 64-bit ROLs, XORs,
etc).
--
Harris
- 'Malo e lelei ki he pongipongi!'
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Secure 'talk'?
Date: 12 May 2001 16:29:00 -0700
"Harris Georgiou" <[EMAIL PROTECTED]> writes:
> Given the key size (64-bit) and the mutable keys/functions, the question is
> how easy it is for someone to tap into the session and recover all plaintext
> message traffic (after some trials)?...
>
> PS: Random function is of standard form: X(n+1)=[a*X(n)+c]mod[m] and
> en/decryption functions are all binary (combinations of 64-bit ROLs, XORs,
It sounds like this encryption scheme is no good and I wouldn't trust
its security for anything except very casual attackers. Replace it
with good cryptography and you'll have something. But why not use an
existing program, like ytalk?
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: DES Crypto Myth??
Date: 13 May 2001 00:33:03 GMT
Roger Schlafly wrote:
>But even if they had understood differential cryptanalysis well, they
>still might not have regarded "optimal robustness" as a necessity.
Actually, "optimal robustness" can potentially make DES *weaker*
(counter-intuitively). Read up on the story of the S^3 S-boxes:
the lesson is that optimizing each S-box in isolation can be bad
if you don't pay attention to their interaction. The DES S-boxes
may not be optimal in isolation, but they combine together in a
very elegant way (the sharing of inputs bits via the E-box, etc.).
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Are low exponents a problem with RSA?
Date: 13 May 2001 00:33:47 GMT
Paul Rubin wrote:
>I'd think you'd really want e=2 which is provably equivalent to factoring,
>though then it's not RSA any more.
Yes, I agree. Dan Bernstein's work is relevant here: For verification,
it is the fastest signature scheme that I know of.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Comparison of Diff. Cryptanalysis countermeasures
Date: 13 May 2001 00:37:41 GMT
>How can one tell that a 64-bit block is "meaningful" or "meaningless"?
For best results, consider multiple blocks.
If you like, you can read a paper Steve Bellovin and I wrote on fast
techniques for recognizing probable plaintext, in the context of exhaustive
DES keysearch: http://www.cs.berkeley.edu/~daw/papers/recog.ps
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: alt.business,alt.business.consulting
Subject: Re: Borg(warner) and Boeing?
Date: Sun, 13 May 2001 00:43:24 GMT
On Thu, 10 May 2001 17:19:28 GMT, Wayne "Mulder" Manzo
<[EMAIL PROTECTED]> wrote, in part:
>Why? Chicago is another huge "ALIEN HIVE" city.
>Wait till the Seattle Boeing Execs get a load of their
>neighbors? Na Nu, Na Nu!
>I'm not going to write about the subject but I,
>as a human American, was attacked by the alien
>race in Chicago. I was taken down unfairly.
Ah, yes, it should be *obvious* that Chicago is controlled by aliens
from outer space. It is - or was - the headquarters of a certain
magazine publishing empire that has been influential in distracting
American manhood from watching out for aliens from outer space.
And before that, there were all those mobsters who worked to ensure
that Americans would be too drunk to notice the aliens were coming.
Maybe the aliens have inefficient respiratory systems, so they need to
live in the "Windy City" to breathe properly.
>Northern Chicago is all white aliens
>and the south Chicago is the alien Negra territory.
You mean that the aliens aren't just disguising themselves as humans,
of whatever color is convenient, but that they're *really* white or
black themselves? Do the black aliens have rhythm too, and are they
able to jump higher when playing basketball?
John Savard
http://home.ecn.ab.ca/~jsavard/
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 13 May 2001 01:33:02 GMT
Subject: Re: DES Crypto Myth??
AFAIK, the S boxes were designed to meet certain criteria and many random ones
were tested against the criteria. This was all done by IBM.
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES Crypto Myth??
Date: Sat, 12 May 2001 16:48:38 -0800
David Wagner wrote:
>
> >The myth is that the DES team knew about differential cryptanalysis
>
> Why do you think it's a myth? All available evidence says they
> knew about it and did a very good job designing for strength against
> it, given the constraints.
Not all available evidence, just most. As I said, Seberry questions it
which is why I asked.
> >The problem with this "common crypto knowledge" is that the DES S-boxes
> >aren't very robust!
>
> Who cares? The properties of the S-boxes on their own don't matter
> diddly squat -- it's the properties of the DES cipher as a whole that
> matter.
Now that's the best news I've heard all day! Now I can quit drudging
through this bent function, Hadamard matrix, and SAC crap and just
throw in a random S-box and crank the number of rounds up to 32 or so.
Whew! I knew it wasn't as difficult as everyone was making out.
> You *really* need to read Coppersmith's paper before coming to any
> conclusions on this topic.
I'll try to do that.
So why do you think the NSA changed the S-boxes, given that the IBM team
had already optimized (s-boxes/cipher - take your pick) against
differential cryptanalysis? How much credit for the diff. analysis
hardening do we give to
the IBM team and how much do we give to the NSA ?
ps. I'M JUST ASKING :)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Comparison of Diff. Cryptanalysis countermeasures
Date: Sat, 12 May 2001 16:54:55 -0800
David Wagner wrote:
>
> >How can one tell that a 64-bit block is "meaningful" or "meaningless"?
>
> For best results, consider multiple blocks.
>
> If you like, you can read a paper Steve Bellovin and I wrote on fast
> techniques for recognizing probable plaintext, in the context of exhaustive
> DES keysearch: http://www.cs.berkeley.edu/~daw/papers/recog.ps
Thanks for that link. I've downloaded the paper and I'll look it over
when
I get a spare minute.
------------------------------
From: [EMAIL PROTECTED] (David Formosa (aka ? the Platypus))
Subject: Re: A simple encryption algorithm based on OTP
Reply-To: [EMAIL PROTECTED]
Date: Sun, 13 May 2001 01:53:53 GMT
On 10 May 2001 23:20:38 GMT, Bill Unruh <[EMAIL PROTECTED]> wrote:
> In <[EMAIL PROTECTED]> "Siva Prasad Gummadi [T]"
<[EMAIL PROTECTED]> writes:
>
> ]Bill Unruh wrote:
> ]> Nope. That permutation must be known for the other side to use the same
> ]> one.
> ]
> ] That's not at all a problem, if both of them agree upon a particular
> ]permutation-generating program, obviously both get the same sequence of
> ]permuted keys
>
> But you must assume that that program itself is available to the enemy
> (unless you want to call it a secret key as well).
Permutations can be numbered. If you use the output of a psydorandom
number geneartor to define wich permutation your going to be using.
Changing the permutation on a regular basis then the key to the
psydorandom generator becomes a shared key and that isn't a case of
security by obscuraty (well not more then any other cyrpto system is).
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is Differential Cryptanalysis practical?
Date: Sat, 12 May 2001 17:01:02 -0800
Tom St Denis wrote:
>
> <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> > Simon Johnson wrote:
>
>
> Probably they looked at statistical analysis (I think that occured first)
> and modified it.... Differential attacks were used before Biham on FEAL-4 by
> Sean Murphy which according to AC2 is the first published
> differential-cryptanalysis attack.
>
My first thought was that they were staring at one of the rounds really
hard
and recognized that a differential was sub-key invariant,and then went
from there, but it's just a guess.
> See "S.Murphy, "The Cryptanalaysis of FEAL-4 with 20 chosen plaintexts,"
> Journal of Cryptology V.2, n.3 1990, pp 145-154".
>
> Tom
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Comparison of Diff. Cryptanalysis countermeasures
Date: Sat, 12 May 2001 17:13:10 -0800
David Wagner wrote:
>
> >Differential analysis assumes that you know the contents of the S-boxes.
>
> Not always, not necessarily.
> (although often key-dependent S-boxes seem to be more resistant
> to differential cryptanalysis)
Are the key-dependent S-boxes generally constrained (to try to eliminate
weak boxes)? If not, it sounds like the s-boxes I mentioned in "method
3"
of the OP could be quite resistant to d.c.
What is your opinion on the OP ? Would you tend to go with carefully
optimized S-boxes or key-dependent boxes?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES Crypto Myth??
Date: Sat, 12 May 2001 17:19:45 -0800
Simon Johnson wrote:
> >
> > const unsigned sbox[1][64] = {
> > { 3, 1, 2, 5, 7, 6, 4, 12, 15, 11, 8, 10, 13, 9, 0, 14,
> > 15, 7, 11, 3, 2, 13, 14, 8, 12, 5, 4, 10, 9, 0, 6, 1,
> > 4, 14, 15, 10, 13, 8, 0, 3, 5, 11, 6, 2, 9, 12, 7, 1,
> > 3, 14, 0, 13, 1, 10, 11, 9, 5, 15, 12, 6, 2, 8, 7, 4 } };
> >
> > (lpmax is 10/64, dpmax is 12/64)
> >
> > But this sbox would probably suck in DES since it doesn't follow the
> > required design.
> >
> > So I would believe that they knew about the attacks.
> >
> > Tom
>
> What Tom is touching on, was that the DES team knew about Differential
> Cryptanalysis... but they did not know about linear cryptanalysis... so
> however your robustness quantity is defined it probably includes resistance
> to linear cryptanalysis which would explain how it strayed so far from the
> optimal.
>
> Simon.
I pretty sure the robustness calculation didn't take linear
cryptanalysis
into account. The equation is
Robustness R = (1-N/2^n)(1-L/2^n)
where N = non-zero entries in first column of diff. distribution table
L = largest non-zero value in diff. distribution table
The non-zero entries in the first column affects the probability of zero
output
differential with non-zero input differential and the largest non-zero
value
gives a high probability output differential.
I don't know anything about linear cryptanalysis so I can't say for
sure.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Crossposted-To: alt.business,alt.business.consulting
Subject: Re: Borg(warner) and Boeing?
Date: Sun, 13 May 2001 02:34:03 GMT
Wayne Mulder Manzo wrote:
> Why? Chicago is another huge "ALIEN HIVE" city.
Clearly, you're missing a link from your bookmarks:
http://www.zapatopi.net/afdb.html
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
This is top-quality raw fish, the Rolls-Rice of Sushi!
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Noekeon sbox design?
Date: Sun, 13 May 2001 04:13:36 GMT
I know the sbox in Noekeon is an involution but are there any other design
requirements?
After analyzing the sbox it seems it's not ideal for a bitslice cipher...
namely
The difference 8 leads to a difference 2 with prob 4/16 (i.e 8=>2) and 2=>8
with a prob of 4/16 also there are linear approximations with a bias
of -4/16 involving single bits.
I can't see an attack off hand but ideally the biases for single bit chars
should be zero or next to it. Also since the sbox is a involution the
inverse differential and linear chars hold just as easy (hence Pr[2=>8] =
Pr[8=>2] = 1/4) as compared to in TC15 where one of the best single bit
differences is Pr[4=>2] = 1/8 and Pr[2=>4] is zero.
A good question is: Is it worth it in terms of speed and size to use a
possibly weak sbox instead of something remotely better. Not to gloat since
I am not certain but it appears that although my TC15 sbox is a bit slower,
it is simpler and has lower single bit characteristics.
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Best encrypting algoritme
Date: Sat, 12 May 2001 21:26:18 -0700
wtshaw wrote:
>
[...]
>
> In short, everytime you encrypt the same thing, the ciphertext should
> substantially vary, no IV's, not reference to adjacent blocks. To get
> enough polymorphism, the length of the encrypted block will probably be
> longer than the plaintext considering character set size and/or length of
> the block in characters.
This sounds like a suggestion for homophonic substitution.
>
[...]
>
> Better block ciphers have some sort of obvious key changes going on that
> allows for increased variability; best is from an input of randomness.
> The problem of reestablishing a random sequence at both ends can be
> removed if the encryptive algorithm stores the path back as part of the
> cipher text. Therefore, original random generation need not be
> duplicated.
> >
Changing the key with each block by selecting a new key uniformly at
random from a key set looks like a significant improvement over ECB with
the same key. Now the challenge is sharing the key sequence secretly,
so only Alice and Bob know the random key sequence.
This sounds like Douglas Gwyn's proposal of Alice selecting a new key at
random from a key set, encrypting it with the current shared key and
transmitting it to Bob (well) before the ciphertext length under the
current key reaches its unicity distance.
Alternatively Alice and Bob could use a PRNG they both initialize to the
same secret seed value. The output of the PRNG serves as the key for
each block. (I wonder how this compares to Douglas Gwyn's proposal?
There's an interesting analysis.)
> >
> Inductive encryption means going from a specific to many, one plaintext
> can yield many equivalent ciphertexts. Deductive decryption means going
> from a range of equivalent but different data that can all yield a
> specific root plaintext. Different randomess should affect different
> blocks so that an codebook is not easily established and letting each
> block present its own decryption riddle.
>
This sounds like probabilistic encryption - and I had never read
anything on the semantic security of block ciphers, so I searched for
papers on it before posting a reply.
Phillip Rogaway's web site posts a paper on the semantic security of
symmetric ciphers, some very interesting analyses of block cipher
chaining modes and a paper (with Mihir Bellare) on variable-input-length
block ciphers:
http://www.cs.ucdavis.edu/~rogaway/papers/index.html
(Also worth reading is his research summary at
http://www.cs.ucdavis.edu/~rogaway/papers/research.html )
I'm still reading "A Concrete Security Treatment of Symmetric
Encryption: Analysis of the DES Modes of Operation" and as yet am not
ready to comment on it. But check it out!
[...]
>
> Making each block stronger requires a great increase in key size. I have
> done what looks wasteful in using huge keyspaces, but it need not be
> frightful. With lots of room to play, the means of generation to fill
> this keyspace becomes a bigger study that the base encryptive algorithm
> itself. Indeed effective keysize can be from almost nothing to the
> equivalent of tens of thousand of bits. While most want to narrowly
> define keys narrowly, I don't. After all, in the ideal algorithm the
> strength resides entirely in the keys; to get great strength, you need a
> keyspace that is frightful for an attacker to contemplate. Keeping a
> keyspace small can mean that you are running away from strength too hot to
> touch for some non-scientific reason.
We must also watch out for key clustering in the keyspace. We can fool
ourselves into thinking a large key in and of itself leads to greater
security and forget that if we aren't careful, we could reveal
statistics in the ciphertext that depend only on statistics of the
key. This would allow the cryptanalyst to limit his search for the
secret key to just a particular subset of the keyspace.
John A. Malley
[EMAIL PROTECTED]
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
