Cryptography-Digest Digest #545, Volume #9 Thu, 13 May 99 15:13:06 EDT
Contents:
Re: 3DES-CBC and key length (DJohn37050)
Re: Lemming and Lemur: New Block and Stream Cipher ([EMAIL PROTECTED])
Re: [Q] Are all encryption algorithms based on primes? (Patrick Juola)
Linear Solutions of S-Boxes ([EMAIL PROTECTED])
Re: Newbie: Encrypting short strings (wtshaw)
Re: Newbie: Encrypting short strings (Jim Felling)
Re: Hello I am paper, please read me. (Jim Felling)
Visual Basic OCX ? ("Billy Reed")
Re: 3DES-CBC and key length (Jim Gillogly)
Re: Crypto export limits ruled unconstitutional (Mike Eisler)
Re: Linear Solutions of S-Boxes (Medical Electronics Lab)
Re: 3DES-CBC and key length (DJohn37050)
Re: a source for random number generation ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: 3DES-CBC and key length
Date: 13 May 1999 13:49:02 GMT
112 bits of key due to the meet in the middle attack. Text attacks after 2**32
blocks of encrypted text, assuming random varying IV.
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Lemming and Lemur: New Block and Stream Cipher
Date: Thu, 13 May 1999 13:47:31 GMT
In article <[EMAIL PROTECTED]>,
Jim Gillogly <[EMAIL PROTECTED]> wrote:
> Cool. Could you post a test vector? Something pretty repetitive
> in the key would be fine, to avoid a huge pile of bits.
Choose the plaintext and key to be something simple:
block[i] = i
perm[i] = (i+5) % 256
key[i][0] = i ^ perm[i]
key[i][j] = (3*i+5*j) %256 (for j>0)
Then a trace of the encryption and decryption process is:
Plaintext: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
After 1 encrypt round: 44 05 04 08 0c 10 1c 18 24 20 24 38 3c 30 4c 48
After 2 encrypt rounds: 5f 49 d4 d2 d3 ec f5 f6 f7 d0 d9 da 3b 34 3d 5e
After 3 encrypt rounds: 36 64 6b f3 fe e2 da ce b6 b2 9a 96 8e 62 6a 5e
After 31 encrypt rounds: 81 0b 21 37 bd 93 21 57 65 6b 41 57 51 cb 94 50
After 32 encrypt rounds: 9e 86 83 ac a5 2a 0f 80 f1 ce db f4 ed ee 0f 5d
Ciphertext: 9e 86 83 ac a5 2a 0f 80 f1 ce db f4 ed ee 0f 5d
After 1 decrypt round: 81 0b 21 37 bd 93 21 57 65 6b 41 57 51 cb 94 50
After 2 decrypt rounds: 06 36 2b 9c b5 0a 67 50 51 7e 13 18 85 c7 08 dc
After 3 decrypt rounds: 31 b3 01 17 ad cb e1 e7 c5 d3 dd 4f 08 dc 05 d8
After 31 decrypt rounds: 44 05 04 08 0c 10 1c 18 24 20 24 38 3c 30 4c 48
After 32 decrypt rounds: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
The pseudocode for encryption, decryption, and key generation was given
in previous posts:
TO LEMMING ENCRYPT A BLOCK:
for (i=0; i<32; i++)
block = rotate(block ^ key[block[0]]);
TO DECRYPT A BLOCK ENCRYPTED WITH LEMMING:
for (i=0; i<32; i++) {
block = backwardsRotate(block)
block = block ^ inverseKey[block[0]]);
}
TO GENERATE A NEW KEY AND ITS INVERSE:
perm[0..255] = random permutation of the bytes 0 to 255
key[i][0] = i XOR perm[i]
key[i][1..15] = 15 random bytes
inversePerm[0...255] = the inverse of perm[0...255],
inverseKey[i][0] = i XOR inversePerm[i]
inverseKey[perm[i]][1...15] = key[i][1...15]
In a previous post, the last line above had a typo.
It had "i" instead of "perm[i]".
In the pseudocode, rotate(block) rotates the block by
8 bits so block[0] moves to block[1], and
backwardsRotate(block) does the reverse. block[0] is
the first byte of the 16-byte block. key[0...255][0...15]
is the 4KB key, which would presumably be generated from
a shorter key or passphrase.
There's been a lot of discussion about the permutations.
The key can be simplified by just using the identity
permutation, which gives key[i][0]=0 for all i. That
simplifies key generation. It might weaken the cipher,
but I don't see any way to exploit that weakness right now.
LCB
[EMAIL PROTECTED]
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: [Q] Are all encryption algorithms based on primes?
Date: 13 May 1999 08:38:41 -0400
In article <cbk_2.5740$[EMAIL PROTECTED]>,
Jessie <[EMAIL PROTECTED]> wrote:
> Are all encryption algorithms based on the fact that it is difficult to
>factor a number which is the product of two LARGE primes? If this is true,
>then, when a factoring function (of the type f(x), which yields all the
>factors of a number without checking the modulus of every number) is
>discovered, there will be ABSOLUTE CHAOS and PANIC!!
But it's not the case that all encryption algorithms are based on
factoring. First of all, almost no "symmetric" encryption algorithms
are based on factoring, so even if a fast factoring algorithm were
discovered, DES, 3DES, IDEA, BLOWFISH, &c would still be as secure
as they are today.
Second, although a lot of public key algorithms, including the
most famous one (RSA) *are* based on factoring, there are others
based on other problems -- discrete logarithms or ellipitic curves
in a finite field, for example. These would also likely survive
a fast factoring algorithm unless the algorithm were *SO* fast and
*SO* general as to be unbelieveable.
-kitten
------------------------------
From: [EMAIL PROTECTED]
Subject: Linear Solutions of S-Boxes
Date: Thu, 13 May 1999 13:28:37 GMT
In TwoDeck there are N! possible decks with N elements each. Simple
stuff. However for each deck (or table, or function) there exist at
least one linear solution for the entire table (Given size of input =
size of output).
Problem: How many solutions exist for N! possible functions (Or ratio
of solutions to table).
For example the table
0,1,2,3,...,255 is the linear function 'y = x'...
0,2,1,3,...,255 is ????
If it's about one solution per table then I am set. Any insight?
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] (wtshaw)
Subject: Re: Newbie: Encrypting short strings
Date: Thu, 13 May 1999 08:35:34 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> >
After a little rest and thinking, I can show a little different example
that is closer to what you want. First a correction on the first one
>
> Inventory item 34568kmn-ert could be represented in 2^56 ways, including
> {XD'/^9=Y%DS]XF+<WY%?S~ }
> {#L2GS^IC#<J"VT,,GBW%:~ }
> {/CB%5+0;NF=4V%*P*FCR=~ }
It should have been 2^54.
>
Assume some keys. You said that your inventory numbers were very short,
so let's use that: Consider repeating the number for as many times as you
can pack into, say 14,15, or 16 characters, a size you pick; fill the
field, perhaps not totally repeating number in the last place:
inventory number ab5 would be plaintext of ab5 ab5 ab5 ab
And, we will only try for 2^30 outputs, not adding as many characters.
Encrypted, one of the results is {8V;;&XKVN#7'Q*;C7)H~ }
The format characters could be dropped so the string to store would be:
8V;;&XKVN#7'Q*;C7)H The character set might be different considering
what characters you figure you need.
For a simple change to occur in this redundant entry, you can see that
several characters would need changing to decrypt to something different
and be consistent, and this is going to be pretty difficult to do.
The length of your inventory number is also hidden, so the user does not
know whether it is so short, or perhaps several characters longer.
> --
> Weathermen prosphesize and insurance companies predict, while both
pretend to be doing the other to get an audience.
--
Weathermen prosphesize and insurance companies predict, while both pretend to be doing
the other to get an audience.
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Newbie: Encrypting short strings
Date: Thu, 13 May 1999 10:14:11 -0500
Oh. Whoops! -- you are correct a standard Block Cypher is probably best then.
Matthias Bruestle wrote:
> Mahlzeit
>
> Jim Felling ([EMAIL PROTECTED]) wrote:
> > A secure hash will have the properties you look for --just pad with nulls out
>
> > Steve K wrote:
> > > I am looking for an algorithm that will be suitable for encrypting (and
> > > decrypting) short strings around 3 to 10 characters in length. I would like
>
> He probably needs to decrypt these numbers.
>
> Mahlzeit
>
> endergone Zwiebeltuete
>
> --
> PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
> --
> Die Katzen brauchten Jahrtausende zum Domestizieren des Menschen.
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Hello I am paper, please read me.
Date: Thu, 13 May 1999 10:11:42 -0500
Here is the reasoning that is used in the attack.
(Notational note C(X,i) is the ith output byte when encrypting string X)
Since Deck A is used in numerical order A(1),...., A(i),..., A(n) and A
contains all values from 1 to n
let deck A' be a simple ordered deck. A'(i)=i, now construct B' as follows
B'(i) =C(0000.....0000, i)
then B'(i) = B(A(i)). So I now have an isomorphic system to A,B and use it
to conduct my stream generation.
The fact that this is isomorphic is easily shown obviously B(A(i)) = B'(i) =
B'(A'(i)) and if A is shuffled
A* = Shufffle(A) so A*(i) =[ A(i/2) {i even} , A( (i+n-1)/2) {i odd}] then
B(A*(i))=[ B(A(i/2)) {i even}, B(A( (i+n-1)/2)) {i odd}]
= [B'(i/2) {i even}, B'((i+n-1)/2) {i odd}]
= B'(Shuffle(A'(i)))
[EMAIL PROTECTED] wrote:
> > Your algorithm is vulnerable to a fairly trivial attack unfortunately.
> >
> > Given Deck A and Deck B this is exactly equivalent to a completely
> ordered
> > deck A' , and B' being the result of taking card B(A(1)) and so on.
>
> The idea is you don't know deck A, so you don't know where the values
> came from in deck B.
>
> Am I missing something? Yes is deck A or deck B is known the security
> is pretty low, but the idea is you don't know either. There are N!
> valid solutions too, so how do you isolate one?
>
> 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: "Billy Reed" <[EMAIL PROTECTED]>
Subject: Visual Basic OCX ?
Date: Thu, 13 May 1999 16:15:20 +0100
I need to encrypt a text file using a recognised algorithm preferably
Blowfish or Twofish in VB 6 or via an OCX. Has anyone written an OCX or have
the appropriate VB code to at least get me started.
Are there any implications of using Blowfish in Europe as I am aware 64 bit
encryption cannot be exported from the US? I believe I can do this in Europe
as nothing is actually being exported. Is this correct.
Many thanks on the anticipated replys
Billy Reed
[EMAIL PROTECTED]
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: 3DES-CBC and key length
Date: Thu, 13 May 1999 09:18:53 -0700
DJohn37050 wrote:
>
> 112 bits of key due to the meet in the middle attack. Text attacks after 2**32
> blocks of encrypted text, assuming random varying IV.
> Don Johnson
Does the 112 assume enough memory to hold 2^56 pairs? The Wiener
& van Oorschot paper in the latest Journal of Cryptology (based
on their Rump Session presentation of a few years ago) considers
2DES, which should be worth only about 57 bits with MITM, but with
reasonable levels of pair memory it appears to be worth about
72 bits instead.
--
Jim Gillogly
22 Thrimidge S.R. 1999, 16:12
12.19.6.3.7, 10 Manik 15 Uo, Fourth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Mike Eisler)
Crossposted-To: talk.politics.crypto
Subject: Re: Crypto export limits ruled unconstitutional
Date: 13 May 1999 17:08:19 GMT
Reply-To: [EMAIL PROTECTED] (Mike Eisler)
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Mike Eisler wrote:
>>
>> The purpose of export control regulations is to limit
>> proliferation of the use of crypto software.
>
>But France had even banned domestic use of strong crypto but later
>found it wasn't particularly clever to do that. I personally can't
Because the boys in Menwith Hill, UK, listen in on all of France's in
the clear communications. France took the wise first step.
Now if they'd similarly relax export control, its software firms
would have an incentive to invest in development of general purpose
software that employs crypto. France would then dominate the
crypto market, and its citizens' privacy would be second to none.
>think of a genuine reason of the bureaucrats trying to do the
>(impossible) task of suppressing the development of crypto other than
>to get some items of work to justify their own payroles. The science
The reason is that if everyone is using crypto, the job of the NSA and
other national Intelligence gathering organizations is much harder.
These organizations scoop zillions of bits of data every day, and
run filters looking for interesting stuff. If it were encrypted above 56 bits,
then it becomes much harder to sift through, at least until Moore's
Law catches up.
Law Enforcement has concerns, but their concerns don't mesh precisely
with those of Intelligence. For instance, if Law Enforcement were told
that a product had a back door, but it required law Enforcement to be
physically on site to toggle a a knob on the product to enable the back
door, Law Enforcement would be happy. Note that the U.S. is realxing
export control og general purosoe software used for merchant,
financial, and medical purposes. Intelligence would not.
Just in case people misunderstand, I adhere to the export regulations
imposed upon me, but I don't believe in them. While I think *some* of
the arguments of Law Enforcement and Intelligence have *some* merit, in
the end, my data is none of their business until they can prove me
guilty, and more damage is going to result from everything in the clear
then if everything is encrypted. Clearly, the gov't of France came to
this realization, and no doubt there is a classified document that
explains how it came around.
>of cryptology is not a monopoly of a number of people or a number
>of nations. Control cannot work. If you have good ideas, you can
>just as well develop your crypto software in the wildness.
Yes, there are smart people everywhere. They are out numbered by people
who use 40 bit web browsers, simply because U.S. companies give it away
without a hassle. You and I will never have to worry about our data
being sent in the clear, because we care enough, and are savvy enough
to know how to get access to 128 bit encryption regardless where we
are. Most people are simply not as computer literate, nor do they grasp
the risks of weak or zero encryption. Consider that the American Bar
Association has pronounced that sending client confidential
information via unencrypted e-mail is safe. If bunch of above average
intelligence people like lawyers don't get it ... then how can you
expect Joe Six Pack to?
The Controls *are* working.
>The kernel, where the crypto-algorithm in the proper sense is, is
>in any case small. It is this that is target of endeavours of
>regulations. Software packages in general tend to be large often
No.
I've successfully gotten export licenses for source code that included
encryption code used just for the purpose of authentication and
integrity. The gov't doesn't appear to care if strong crypto gets
exported, they care if strong crypto privacy gets incorporated into
popular software like IE5, Office, Outlook, Windows98, NT 4.0, Linux
and the TCP/IP protocol stacks of the the latter 3 operating systems.
Ubiquity of crypto is the Big Fear, not a BSAFE 3.0 took kit in every
foreign programmer's hands.
It is non trival to incorporate crypto into complex systems which
have a primary purpsoe other than crypto.
>because of provision of good user interfaces. For a commercial
>product certainly one has to invest a sizable amount of resources.
>But at least for a 'lean' version that is not required to have optimal
>speed performance and user comfort, the implementation of the known
>crypto algorithms can't be a very big thing. There are plenty of much
>more complex jobs in software engineering that get done all over
>the world.
Fine, then show me the ubiquitous encryption in each of those jobs.
I'd love to be wrong.
--
-Mike Eisler Solaris NFS group
[EMAIL PROTECTED] Sun Microsystems, Inc.
remove the prefix 'NO_' and suffix '_SPAM' to reply.
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Linear Solutions of S-Boxes
Date: Thu, 13 May 1999 12:57:27 -0500
[EMAIL PROTECTED] wrote:
>
> In TwoDeck there are N! possible decks with N elements each. Simple
> stuff. However for each deck (or table, or function) there exist at
> least one linear solution for the entire table (Given size of input =
> size of output).
>
> Problem: How many solutions exist for N! possible functions (Or ratio
> of solutions to table).
>
> For example the table
>
> 0,1,2,3,...,255 is the linear function 'y = x'...
> 0,2,1,3,...,255 is ????
>
> If it's about one solution per table then I am set. Any insight?
What about 255,254,....,1,0 y = ~x, or y = -x or y = k - x mod 256?
In your N! tables, there will be lots of similarities, so many will
be linearly related.
Look for the paper "Good S-Boxes are hard to find" by C. Adams.
It will explain a lot of useful things and give you some pseudo
code for ways to generate your own s-boxes (decks).
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: 3DES-CBC and key length
Date: 13 May 1999 19:11:53 GMT
The question was for 3 different DES keys. FOr 2 keys the last I know is that
it is the minimum of (2**112, 2**120/n) where n is the number of known
plaintext/ciphertext pairs. This info is all in X9.52. I have not seen the
recent vOW paper, do they say there is a better attack than what I gave above?
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: a source for random number generation
Date: Thu, 13 May 1999 18:05:51 GMT
Someone posted about the Aware site.
I have a web page about using the
Aware Geiger counter, including photos,
source code, and the format of the data
file it records. Also help on
increasing your bandwidth with a smoke
detector and distilling the entropy
(RFC 1750 is great).
See my geocities page in
SiliconValley/Code/4704/radpage.html
Although this is a fun toy, you'll have better luck using
a sound card to digitize FM hiss and distill that. Sound
cards are also cheaper and more common. Also, you don't
need to find hot isotopes to get more bandwidth.
It is important to 1. turn up the volume of the hiss for
max entropy 2. measure the entropy of your raw hiss so you can know
how much to distill it. You should also measure the entropy
of your distilled sample; if its not up to par, you have
to continue distilling your bits.
An integrated FM receiver card is even more convenient.
--== 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
******************************
