Cryptography-Digest Digest #677, Volume #9 Tue, 8 Jun 99 12:13:03 EDT
Contents:
Re: KRYPTOS ([EMAIL PROTECTED])
Re: Annoying Newbie.... ([EMAIL PROTECTED])
Re: Mandlebrot transform (Christof Donat)
Re: Cryptography CENSORED on web site? (Mok-Kong Shen)
DES ([EMAIL PROTECTED])
Re: DES (fungus)
Re: rc4 vs. rand() (fungus)
Re: Key lengths vs cracking time ([EMAIL PROTECTED])
Re: tomstdenis' simple.c ([EMAIL PROTECTED])
Re: rc4 vs. rand() ([EMAIL PROTECTED])
Re: Key lengths vs cracking time (Nicol So)
Re: Challenge to SCOTT19U.ZIP_GUY (Thomas Pornin)
Re: DES ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: KRYPTOS
Date: Tue, 08 Jun 1999 07:54:28 GMT
Thanks
I had a look at it and it's a joke alright!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Annoying Newbie....
Date: Tue, 08 Jun 1999 08:05:33 GMT
Hi;
Ok i'm going to reply to all of you nice people in one little post
(like magic!)
Tom; Cheers; those papers would be cool - i am
[EMAIL PROTECTED]
M. de la Ritter; likewise cheers -- i already read you site, and it
is pretty cool. (at my site, pgp.homepage.com (pretty sparse) i linked
you.
John ... wow! your site is massive! i have read some, and bookmarked
it for later reading...
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Tue, 08 Jun 1999 11:32:24 +0200
From: Christof Donat <[EMAIL PROTECTED]>
Subject: Re: Mandlebrot transform
> Hm, letīs see. There is definately no (known to me) way to get the
> original point when you only have the result of the Mandelbrot
> Transformation. Maybe as a Base for a Hash Function or for a Public Key
> System.
>
> This is of course shooting quickly. I have not _really_ thought about
> it.
OK, now I've thought about it. If you inverse the Mandelbrot
Transformation
you get back two points. That`s why I thought, that it is impossible to
reconstruct the real original Point. You just have to go enough rounds.
The
Problem is, that if you try to make a Public Key System from it, each of
the input Points must generate the same cypher text. Otherwise you can
not reconstruct the text with the original Point.
For a hash Function:
- use one point inside the quarter of (-1/4, -1/4) and (1/4, 1/4) as
input.
map the Integer numbers you usually have as input in lines or somehow
else
to this quarter.
- calculate the mandelbrot Transformation a defined number of times
- while the imaginary Part of the Result is > 1/4 reduce it by 1/4;
while it is
< -1/4 add 1/4.
- map [-1/4, 1/4] to the Output Space.
This could be a useable Hash algorithm. If you have the time, try to
implement it and check its quality.
Christof
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Cryptography CENSORED on web site?
Date: Tue, 08 Jun 1999 12:36:45 +0200
rosi wrote:
> I do not think people will have the 'suppressing' notion at all.
>
> You are right. It is not unimportant to talk about IT. It is my opinion
> that IT needs
> to be talked about in the 'right' context. Actually, it is important to talk
> about it AS
> IT IS.
One may argue whether censoring exists. Excepting that there was,
as I heard long time ago, a request to editors of journals of a
country to accept voluntary censoring, the only form of censoring,
I think, is indirectly through prohibition of publication of scientific
materials of certain category in general (cf. Bernstein process).
Recently I said elsewhere that one genuine reason of the bureaucrats
acting apparently irrationally (including treating export issues
differently depending on whether it is paper or magnetic disks)
may be that they need work items to justify their own payrolls.
There could be, however, much more deeper and subtle grounds too.
One is to create a myth about crypto and hence to generate publicity
in a particular sense (compare some stars who use scandals to
create bigger names). Crypto products that are prohibited or
restricted from export are 'from the beginning' better than the
others. I conjecture that that has helped in certain sense. The other
is to render a large set of people use crypto of inferior quality,
thus making interception for economical purposes easy. (Criminals
are presumably wise enough to use illegal strong cryptos anyway.)
In this respect it is to be remarked that France, which had laws to
forbid its citizens to use strong crypto, abandoned the crypto laws
and that after (not before!) the Wassenaar agreement. Several days
ago Germany took steps to ensure freedom of use and development
of strong crypto. Maybe materials like the STOA report will have
further impacts in the foreseeable future.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: DES
Date: Tue, 08 Jun 1999 09:03:35 GMT
DES;
1 That initial permutation; is it actualy worth anything
cryptograpicaly?
2 The fixed s-boxes? Surely if they are known, they are worthless?
Wouldn't it make more sense to have key dependant s-boxes?
I am new to this, so please don't attack me... I'm not being
pretentious; i genuinely want to know how fixed s-boxes give any
strength, and what the initial/final perms do.
Cheers, Jim
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: DES
Date: Tue, 08 Jun 1999 10:28:46 -0100
[EMAIL PROTECTED] wrote:
>
> DES;
> 1 That initial permutation; is it actualy worth anything
> cryptograpicaly?
No.
> 2 The fixed s-boxes? Surely if they are known, they are worthless?
Apparently not. DES has stood the test of time...
> Wouldn't it make more sense to have key dependant s-boxes?
>
It depends what you mean by "more sense".
Many people have done key-dependent S-boxes. See "Applied Crypto" for
examples of this.
The problem is in knowing that your generated S-boxes are any
good. If you want a bigger key then maybe you'd be better off
just using triple DES, it's tried and tested.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: rc4 vs. rand()
Date: Tue, 08 Jun 1999 11:29:53 +0200
[EMAIL PROTECTED] wrote:
>
> I have heard things about short RC4 cycles, and some bad properties.
Where?
> I would investigate them before using RC4 commercially.
This has been done. RC4 is used for most secure Internet transactions.
> Better yet is to use a block cipher in OFB mode.
>
Why better? More complex and slower, certainly, but "better"?
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Key lengths vs cracking time
Date: Tue, 08 Jun 1999 10:33:01 GMT
> Maybe. Most ciphers regarded as secure are only widely believed to be
> so. If somebody comes up with a 256-bit cipher that provably requires
> at least 2^64 elementary operations (say trial encryptions) to break,
it
> has a lot of value. If nobody could figure out how to reduce the key
> size to 64 bits while preserving the mathematical proof of security,
> somebody might just want to use it with 256-bit keys.
Why generate larger keys then you require? Why use them? If your
cipher is weak enough to only require 2^64 encryptions, then you should
reduce the key accordingly. It's probably professionalism, i dunno.
Better yet is to fix the cipher and reclaim some of the challenge.
> Let me play devil's advocate here. Breaking 1024-bit RSA certainly
> requires fewer than 2^1024 operations. Would you call the cipher
> insecure just for that reason?
RSA keyspace is not flat, it's that simple.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: tomstdenis' simple.c
Date: Tue, 08 Jun 1999 10:30:31 GMT
> I like the algorithm in simple.c. It is, as its name suggests, simple.
> :-)
>
Thanks, the algorithm is simply a demo into large sboxes...
> But there are some points I like to have cleared up:
> 1) in function schedule(), you need to have
> y = (y + key[x] + table[r]) & 0xFFFF;
Nope, 'x' 'y' are unsigned short. However to be sure we could add the
AND. On most platforms unsigned short is already 16 bits (it is in
DJGPP...). I will add the AND for completeness sake, thanks.
>
> 2) The round function always works on pairs of bytes
> (ab)->(a'b'), (cd)->(c'd'), etc.
> Am I wrong in thinking that all I need is 65536 plain-cipher texts to
> build a dictionary? Can't we modify substitution at the end of the
> round to rotate bytes? (a=table[b], b=table[c], ...h=table[a])
You can't because the bytes are mixed together. If you remove the PHT
you can simply crack this algorithm. This is how. You create 65536/8
or 8192 blocks which are the values from 0 to 65536. Then you perform
an encryption. No matter how many rounds there are you can always
assume that the cipher is one large function and you can build a simple
dictionary.
This is thwarted because you do not know what the output or inputs are
for the various rounds. Even the last output you do not know.
> 3) I forgot. Something to do with key scheduling table. I cannot
> convince myself that the table will be shuffled well enough for large
> tables, but I cannot say why. Any extra info, ideas to convince me
> otherwise?
Well the idea is from RC4 but I can still explain some stuff.
Basically the schedule is a feedback type swap. It's designed to have
the key as an input but also use the state as well. This way changes
propagate (note the y variable). Most people may not realize but swaps
may occur anywhere in the array, forwards or backwards. Who is to say
when you perform swap(state[r], state[y]) that 'state[r]=r'? The
schedule is supposed to build non-linear functions.
One problem with the source as presented is that in the output, if any
outputs are not equal then you know their inputs into the final
function are not equal. I will post a real simple fix to this later.
All you have todo is add a keyed constant (post-white) to the output.
In fact I will add it right after I post...
Thanks for taking interest. If there is anything else you need cleared
up just ask. Like I said it was simply an example into large s-boxes.
It's no slower then most ciphers (blowfish, rc5...) but requires a lot
more ram. DJGPP has a fun time optimizing it as it puts about four of
the words into registers, and the rest in local stack. It optimizes
the PHT pretty well too.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: rc4 vs. rand()
Date: Tue, 08 Jun 1999 11:31:06 GMT
> > I have heard things about short RC4 cycles, and some bad properties.
>
> Where?
>
I cannot remember, it was at a site about another RNG... sorry it was a
while ago. I wouldn't worry about it though.
> > I would investigate them before using RC4 commercially.
> This has been done. RC4 is used for most secure Internet transactions.
Really? It used to be a trade secret so who did the review?
> Why better? More complex and slower, certainly, but "better"?
RC4 = RSADSI!!! That's why. If I want to write a secure app I don't
want to shell out money to write the program. I would rather use
something like Blowfish in CBC (blocks) or CFB (streams) then something
commercial.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Key lengths vs cracking time
Date: Tue, 08 Jun 1999 08:27:17 -0400
[EMAIL PROTECTED] wrote:
>
> > Maybe. Most ciphers regarded as secure are only widely believed to be
> > so. If somebody comes up with a 256-bit cipher that provably requires
> > at least 2^64 elementary operations (say trial encryptions) to break,
> > it
> > has a lot of value. If nobody could figure out how to reduce the key
> > size to 64 bits while preserving the mathematical proof of security,
> > somebody might just want to use it with 256-bit keys.
>
> Why generate larger keys then you require? Why use them?
One word: assurance. Having a known lower bound on security outweighs
the inconvenience of slightly longer keys, at least in some
applications.
> If your
> cipher is weak enough to only require 2^64 encryptions, then you should
> reduce the key accordingly. It's probably professionalism, i dunno.
> Better yet is to fix the cipher and reclaim some of the challenge.
In my hypothetical example, I said that you might want to use the longer
key if: (1) you want the provable lower bound on security but (2) don't
know how to preserve the guarantee of security when switching to a
shorter key. It is obvious that one want to be able to use a shorter
key, if he knows how.
> > Let me play devil's advocate here. Breaking 1024-bit RSA certainly
> > requires fewer than 2^1024 operations. Would you call the cipher
> > insecure just for that reason?
>
> RSA keyspace is not flat, it's that simple.
It's not that simple. The RSA keyspace is not flat, but it is
relatively dense. Breaking the cipher requires substantially less work
than the abundance of keys would suggest.
Nicol
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: 8 Jun 1999 12:40:08 GMT
According to SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>:
> You can use IDEA ( or any AES candidate) use CBC encryption and then
> reverse so the front is the back and then encrypt agafin useing a
> different key. Know hex edit a byte in this file and then decrypt in
> reverse order. Only a small area is garabage. The rest of the file is
> recovered in tact.
First tell me that I understood well your 'method':
given a plaintext p1,p2,p3,...pn (n blocks), you encrypt this with
the key k1 in CBC mode, which gives c1,c2,c3,...cn.
Then you encrypt cn,...c3,c2,c1 with the key k2 and obtain
d1,d2,d3,...dn.
To decrypt: using k2, you recover cn,...c3,c2,c1, then you use k1 to get
p1,p2,p3...pn.
Ok, why not.
Then your assumption: when you modify, say, d17, the corresponding
plaintext will be essantially identical to p1,p2,p3...pn, whatever
block cipher is used.
That is true. Essentially, three plaintext blocks will be modified.
So what ? This just means that you misused or misunderstood what CBC
means. In fact, by reversing the chain and applying a second CBC, you
undo what the first CBC gave you. You are applying a different chaining
mode, that you basically build with one CBC and a reversed one, and this
new mode is weak. You know it. Then don't use it.
CBC is good for what it was meant for: modification of one block should
modify the following ciphertext blocks. Do not expect it to be a magic
intractable transformation: the cipher is there for this thing.
To sum up: CBC is not weak. Your 'double-CBC-with-reverse' is weak. To
make an analogy, the fact that you cannot build a multiply operation
with only xors does not mean that the xor is wrong, just that you made
wrong assumptions about what a xor is. If you want a chaining mode that
will ensure that each bit of plaintext modifies each bit of ciphertext,
then do not use CBC.
> The more I have looked at chaining the more I think that it is done
> wrong.
It is done right for what it is meant to be. Do not forget that
encryption is used mainly for streams of data, where you must deliver
ciphertexts in real-time, and cannot rewind. CBC is good for this. You
want something else, then do not use CBC. Design your own mode for your
own requirements.
Nobody speaks about this because there is not much to speak about, only
that one should not take a few random cryptographic primitives and put
them together, for this does not give good security.
--Thomas Pornin
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES
Date: Tue, 08 Jun 1999 12:54:05 GMT
> DES;
> 1 That initial permutation; is it actualy worth anything
> cryptograpicaly?
No, according to AC they are used to optimize hardware implementations.
Many software implementations skip it.
> 2 The fixed s-boxes? Surely if they are known, they are worthless?
> Wouldn't it make more sense to have key dependant s-boxes?
Well's it is not the s-boxes that make it strong (well they do... but
wait a sec). The secret information is the key, or more specifically
the round keys. It's expected that for the last output you didn't know
the plaintext so it's not easy to eliminate the roundkey/plaintext from
the output. The s-boxes are designed to promote avanlanche. Many
ciphers use fixed s-boxes and are secure, CAST for example which has
implementation dependant s-boxes has a strict design criterion for them.
Blowfish is an example of key dependant s-boxes (actually it's a spin
off of CAST...).
>
> I am new to this, so please don't attack me... I'm not being
> pretentious; i genuinely want to know how fixed s-boxes give any
> strength, and what the initial/final perms do.
Like I said fixed-sboxes are good if they are designed for at least to
criteria, non-linear and avalanche. One can assume good resistance to
linear attacks if no two inputs have outputs which share a common linear
expression. Avalanche is obtained when to adjacent entries have a
hamming distance of at least n/2 (n is the number of bits per output).
By adjacent I mean by flipping any one of the m input bits at a time (so
a single bit change will have an avalanche effect).
Random key dependant sboxes are harder to analyze, and are not as easy
to study. In DES since the sboxes are small they are easy to attack
because there less stuff to guess. In blowfish the sboxes (which are
8x32) are harder to guess since there is lots more information.
Anyways enough said.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
