Cryptography-Digest Digest #555, Volume #11 Sun, 16 Apr 00 01:13:01 EDT
Contents:
Yet Another CryptoBag Release (YACBR) (Tom St Denis)
Re: GOST with sbox? (stanislav shalunov)
Re: Yet Another CryptoBag Release (YACBR) (stanislav shalunov)
Re: Yet Another CryptoBag Release (YACBR) (Tom St Denis)
Re: Why is this algorithm insecure? (Newbie flamefodder) (NFN NMI L.)
Re: CLOSE Encryption (Jerry Coffin)
Re: CLOSE Encryption (Jerry Coffin)
Re: GSM A5/1 Encryption (Jerry Coffin)
GOST idea (Tom St Denis)
Re: Yet Another CryptoBag Release (YACBR) (stanislav shalunov)
Re: Yet Another CryptoBag Release (YACBR) (Tom St Denis)
Re: Why is this algorithm insecure? (Newbie flamefodder) (stanislav shalunov)
Re: Yet Another CryptoBag Release (YACBR) (stanislav shalunov)
Re: MD2? (Tom St Denis)
Re: Yet Another CryptoBag Release (YACBR) (Tom St Denis)
Re: General principles of design ([EMAIL PROTECTED])
One Time Pads Redux (Joaquim Southby)
Re: One Time Pads Redux ("Joseph Ashwood")
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Yet Another CryptoBag Release (YACBR)
Date: Sat, 15 Apr 2000 23:12:06 GMT
Well I released v1.06 after fixing numerous RSA related bugs (todo with
large keys), I also addressed numerous endianess issues. I fixed all of
the rsa routines to use platform independant field variables, and I
switched all the symmetric ciphers to use a platform independant
load/store routines.
I have also added Gost, Skipjack and XTEA to the list of symmetric
ciphers. I have fixed Blowfish to behave as expected [basically I
copied the ref source] as well.
If you want to check it out (it's free and the source is all their) it's
at http://24.42.86.123/cb.html.
If you don't know what CryptoBag (CB) is, it's my ultra-cool free
Cryptographic toolkit [in C] that supports symmetric ciphers (ten of
them), RSA encryption/decryption/exporting/importing/creating (keys),
Data Compression, three hash functions, a truly random source, a faster
cryptographically secure random source, a base64 encoder/decoder and
misc helper routines. It's all free and all their on my website.
If anyone has comments or questions, bugfixes or flames, please let me
know.
Tom
------------------------------
Subject: Re: GOST with sbox?
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Sat, 15 Apr 2000 23:20:15 GMT
Tom St Denis <[EMAIL PROTECTED]> writes:
> Are those sboxes ok to use?
That's the only set of S-boxes that has been analyzed by somebody
outside of FAPSI (and, presumably, NSA, etc.).
> (I lent out my copy of AC, so can someone please post them here?)
You can download implementations of the GOST block cipher from various
places.
> Why not? Has there been any analysis of gost? I know there is a
> related key type thing by Counterpane.... What else?
Size differs, etc.
In Russia, to have an approved cipher (e.g., you need one if you're a
bank) you have to get your S-boxes from an Approved Source, and keep
them mildly secret.
What would the Approved Source (FAPSI) do to generate them is
classified.
Some sets are obviously better than the others.
The only ``known approved'' set of S-boxes publicly known is the one
listed in AC2.
--
stanislav shalunov | Speaking only for myself.
My address in From: is correct; if yours isn't, I don't want to hear from you.
Try to reply in newsgroup. I don't need courtesy copies.
------------------------------
Subject: Re: Yet Another CryptoBag Release (YACBR)
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Sat, 15 Apr 2000 23:34:41 GMT
Tom St Denis <[EMAIL PROTECTED]> writes:
> CryptoBag [...] supports [...] a truly random source, [...]
How is this implemented and what is the bandwidth?
--
stanislav shalunov | Speaking only for myself.
My address in From: is correct; if yours isn't, I don't want to hear from you.
Try to reply in newsgroup. I don't need courtesy copies.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Yet Another CryptoBag Release (YACBR)
Date: Sun, 16 Apr 2000 00:38:40 GMT
stanislav shalunov wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> writes:
>
> > CryptoBag [...] supports [...] a truly random source, [...]
>
> How is this implemented and what is the bandwidth?
Depends on your platform. On unix type machines you can set it up to
use /dev/random. On windows it uses a free running counter, elsewheres
it can use keyboard input which is hashed.
If you doubt the windows_rng works, try my little rng challenge on the
page. Basically tell me which one was made by the prng and which by the
rng.
I know for a fact that on my pc I get about 80 bits/sec with the
windows_rng. The prng [a counter mode hash] creates over 100kb/sec on
my comp... so it's fast enough for key generation, etc...
See the file 'trng.c' in my CB package for how to setup the rng. The
nice thing is the overall api stays the same no matter what platform you
are on.
Tom
------------------------------
From: [EMAIL PROTECTED] (NFN NMI L.)
Subject: Re: Why is this algorithm insecure? (Newbie flamefodder)
Date: 16 Apr 2000 01:03:00 GMT
<<The algorithm is too simple to be secure, surely. It also suffers from
inefficiency, having a time complexity which I believe to be O(pk) where
p is the plaintext length and k is the key length, although - again - I
could be wrong about this. Having said that, it does lend itself to
stupendously long keys - http://users.powernet.co.uk/eton/crypto/cipher
contains a cipher (which I daren't reproduce here, since all 8 (or, if
you prefer, CHAR_BIT) bits of each byte are in the cipher 'space') which
was encrypted using a key over 20,000 bits long. (I never really
understood why people were hung up on 56 and 64 and 128 bits!)>>
128-bit, maybe 256-bit keys are fine. The larger the key, the more unwieldy it
is. If you don't care about large keys, just use an OTP!
<<Here's the algorithm, which I rather self-consciously call CDX-1:>>
Thanks for providing an English description.
<<It would be most foolish of me to expect anyone to analyse this
algorithm without my producing source code>>
Actually, if you just post source code, as many others do, no one usually reads
it.
<<Read the /whole/ plaintext into a buffer.
Read the whole of the key into another buffer.>>
You may as well just talk about the plaintext and the key.
<<For each byte of the key
Pick some number B with which that byte of the key is uniquely
identified (I used a bunch of primes)
Rotate the buffer left by B bits.
Perform a Vigenere-style XOR of the key all the way along the buffer.>>
So, you repeat this process Q times, where Q is the number of bytes in the key,
and the first time, you rotate the plaintext by 2 bits, the second time, by 3
bits, and the Qth time by P[Q] bits? And after each rotation you just XOR the
value KEYKEYKEYKEY...KEY to the plaintext? Obviously, you can just start with
0000...000 and then do this process, producing a really munged key, and then
XOR that key with the plaintext (this is equivalent to your algorithm). This
algorithm obviously fails horrendously for keys that are all 0's. What if your
key is one byte: 01101100, say? See how little your algorithm can munge this
key: rotating it by 3 bits is the same as rotating it by 11 bits. This would
really suck if a key could be 6 bits (why?) Perhaps a key of 6 bytes, 48 bits,
will suck too. Think about it.
Posted and mailed - phear Kibo.
-*---*-------
S.T. "andard Mode" L.
STL's Quotation Archive: http://quote.cjb.net
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: CLOSE Encryption
Date: Sat, 15 Apr 2000 19:47:16 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> Wouldn't it be a good idea that you post a good abstract (essence)
> of your algorithm to the group instead of asking people to
> read your web page?
If he was really interested in cryptanalysis, yes. If he's
interested primarily in getting more hits on his web page to collect
advertising money, then posting useful information would pretty much
ruin the whole point.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: CLOSE Encryption
Date: Sat, 15 Apr 2000 19:47:18 -0600
In article <ABNJ4.80$rv6.5063@news1-hme0>, [EMAIL PROTECTED] says...
> CLOSE is a new algorithm written by Chaos Legion,
>
> If you are a cryptoanalyzer then come visit our site and evaluate it
> for us. If you spot any weaknesses then post them on the CL Web Board
> not here.
Maybe I'm being cynical, but it seems to me that what you're asking
is that we not only do your homework for you for free, but also that
we spend plenty of time visiting your web sites so YOU get
advertising money based on our visits.
I did some looking, and I think it needs work. First of all, if it
has any security at all in its present form, it's in the hashing.
You've described the rest of the algorithm in sufficient detail to
assure us that all the other parts are completely linear.
Unfortunately, you describe the hash only as "a 32-bit
hash/checksum", whcih doesn't lead me to believe that it's a
cryptographically secure hash. If it's a checksum or CRC (which is
a linear transformation) you've still got no real security. Even if
it was a good hash algorithm, 32 bits is really too small to make the
algorithm as a whole worth a whole lot -- at best a good 32-bit hash
would change this from a complete joke to a nice toy-sized challenge.
Ultimately, you've got a Vernam cipher with an attempt at some key
stretching. Unless you're a LOT older than I think, the methods to
break this sort of thing were old before you were born.
You've mentioned using sub-keys: if done properly, this will at least
help diffusion. Unfortunately, unless your sub-key generation is
extremely sophisticated, this won't really fix any of the fundamental
problems with the cipher itself. Ultimately, you need some non-
linearity to have any real hope of security. The most common way of
introducing non-linearity is to use S-boxes, as they're easy to set
up and quick to use. Since you're apparently planning on using this
primarily (more likely exclusively) in software, it's probably best
to make the S-boxes quite large and preferrably key-dependent. You
might want to look on the Counterpane web site and/or in a book or
two on cryptography for information about the design of, e.g.,
BlowFish.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: GSM A5/1 Encryption
Date: Sat, 15 Apr 2000 19:47:20 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> Fine, but again, you can do 3DES at GSM speeds in a few percent
> of DSP capacity. Are you trying to tell me that these devices
> are built so close to the limit that there isn't 2-3% idle time
> in the DSP?
Probably -- extra processing capability translates directly to extra
power consumption. For most phones, there are three specifications
that matter more than anything else: small size, light weight, and
long battery life. You don't maximize the life of a small, light
battery by using processors that burn more power than necessary...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: GOST idea
Date: Sun, 16 Apr 2000 02:11:11 GMT
I like the simplicity of gost... hmm Let's change the F function to be
F(x) = S(2x^2 + x) <<< 11
Where S is the parallel application of the eight 4x4 sboxes. This would
have much higher avalanche and only make the F function slightly more
complex.
Any thoughts?
Tom
------------------------------
Subject: Re: Yet Another CryptoBag Release (YACBR)
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Sun, 16 Apr 2000 03:02:06 GMT
Tom St Denis <[EMAIL PROTECTED]> writes:
> Depends on your platform. On unix type machines you can set it up to
> use /dev/random.
Keep in mind the fact that only BSD and Linux currently have /dev/random.
Solaris 7 has a patch that provides it.
--
stanislav shalunov | Speaking only for myself.
My address in From: is correct; if yours isn't, I don't want to hear from you.
Try to reply in newsgroup. I don't need courtesy copies.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Yet Another CryptoBag Release (YACBR)
Date: Sun, 16 Apr 2000 03:09:21 GMT
stanislav shalunov wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> writes:
>
> > Depends on your platform. On unix type machines you can set it up to
> > use /dev/random.
>
> Keep in mind the fact that only BSD and Linux currently have /dev/random.
> Solaris 7 has a patch that provides it.
That's why [if you read the entire message] you would find that I have
*two* other types of rng inputs.
Tom
------------------------------
Subject: Re: Why is this algorithm insecure? (Newbie flamefodder)
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Sun, 16 Apr 2000 03:10:38 GMT
It appears that for any given key and length of plaintext there exists
a string of the length the same as the plaintext that you XOR to get
the ciphertext.
This is bad. For example, a chosen plaintext attack with just one
chosen plaintext reveals any further messages of the same length
encrypted with the same key.
There are many other problems.
--
stanislav shalunov | Speaking only for myself.
My address in From: is correct; if yours isn't, I don't want to hear from you.
Try to reply in newsgroup. I don't need courtesy copies.
------------------------------
Subject: Re: Yet Another CryptoBag Release (YACBR)
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Sun, 16 Apr 2000 03:16:25 GMT
Tom St Denis <[EMAIL PROTECTED]> writes:
> That's why [if you read the entire message] you would find that I have
> *two* other types of rng inputs.
Earlier (in <[EMAIL PROTECTED]>) he has said:
> Depends on your platform. On unix type machines you can set it up to
> use /dev/random. On windows it uses a free running counter, elsewheres
> it can use keyboard input which is hashed.
Does this mean that on Unix other than BSD and Linux the only RNG is
keyboard-based?
--
stanislav shalunov | Speaking only for myself.
My address in From: is correct; if yours isn't, I don't want to hear from you.
Try to reply in newsgroup. I don't need courtesy copies.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: MD2?
Date: Sun, 16 Apr 2000 03:17:21 GMT
Simon Johnson wrote:
>
> What is the strength of MD2?
Last I read MD2 was broken, or at least in theory.
> And do the S-BOX values have to be the digits of PI?
I don't honestly know.
For just mashing data MD2 is fine, and works well on 8-bit platforms
[for which it was developed]. Although new applications should think
twice about using it for signatures...
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Yet Another CryptoBag Release (YACBR)
Date: Sun, 16 Apr 2000 03:18:46 GMT
stanislav shalunov wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> writes:
>
> > That's why [if you read the entire message] you would find that I have
> > *two* other types of rng inputs.
>
> Earlier (in <[EMAIL PROTECTED]>) he has said:
>
> > Depends on your platform. On unix type machines you can set it up to
> > use /dev/random. On windows it uses a free running counter, elsewheres
> > it can use keyboard input which is hashed.
>
> Does this mean that on Unix other than BSD and Linux the only RNG is
> keyboard-based?
Bingo. You just type at least 100 chars, and it will output 76 bytes at
a time. This is acceptable since you normally would use the rng
routines to seed the prng. So you don't need mb's worth of rng output.
Tom
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: General principles of design
Date: Sun, 16 Apr 2000 04:22:25 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> I like to say a few more words on the principle of 'variability'
> that I suggested in the previous post.
>
There are certainly some principles that can be enumerated about block
ciphers.
1. The strength of the cipher should rest only in the secrecy of the
key.
2. The key length should be much larger than possible exhaustive
search. DES failed here.
3. After the first several rounds each bit should depend on all other
bits i.e. diffusion
4. By the end of the rounds each bit should depend on every bit of the
key. Having the round keys depend on the master key is a good way to
do this.
5. The cipher should be highly non-linear across multiple rounds i.e.
confusion. S-boxes are a good example
6. The cipher should be strong against differential attacks. DES did
fine.
7. The key schedule should act as a one way hash. To avoid giving away
the master key if a round key is recovered.
8. Each round key should give little information about other round keys.
9. Weak, semi-weak, eqivalent, complementary, etc keys should not
exists in great numbers.
That is a good start. Whole volumes have been written about cipher
design so my list is very incomplete.
As for variablity, it is a fine idea. Blowfish is an excellent example.
No one has managed an attack on Blowfish yet.
One danger is that some keys my be weaker than others. I recently
extended the weak key attack on Blowfish. The new attack is by no means
practical and it still requires some secret information. I believe it
is the best to date however.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: One Time Pads Redux
Date: 16 Apr 2000 04:43:24 GMT
This may have been discussed already; I could not find it in the reams of
messages in sci.crypt about one time pads. (To be honest, I gave up
after reviewing the first 50 or so -- Deja is a dog.)
>From what I've read about OTP, the major drawback is the key
distribution. Would something like the following help to alleviate that
and still be secure?
A) Bob and Alice each have a RNG at their disposal. These do not need to
be synchronized or even similar -- they just have to create numbers
acceptably random for an OTP.
B) Bob enciphers a message by XOR'ing the plaintext with numbers from his
RNG; he keeps a temporary copy of the numbers he used for this message.
He sends the enciphered message to Alice.
C) Alice repeats this process using her RNG and sends the result back to
Bob.
D) Bob uses his temporary copy of the numbers he used the first time,
XOR'ing them with Alice's return message to remove his stuff from the
mix. He sends the result to Alice.
E) Alice uses her temporary copy to remove her encipherment and retrieve
the original plaintext message.
F) Both of them destroy their temporary copies of their RNG numbers.
The obvious drawback I can see to this is how to keep track of what copy
of RNG output goes with what message. In an automated system, messages
could have headers identifying uniquely identifying themselves and their
accompanying RNG output files. This would work best when the exchange of
messages is completed within a very short period of time.
As I mentioned, this method would seem to preclude the need to distribute
OTP's to multiple users. It seems so simple (other than the correlation
of messages to RNG output) that there must be something wrong with it.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: One Time Pads Redux
Date: Sat, 15 Apr 2000 22:04:08 -0700
The first attack that comes to mind is based on the typical
method using the pad, namely XOR. It is a property of XOR
that is I have the plaintext, and the ciphertext, I can
retrieve the pad. Given this, the attack goes as follows
(editted into your proposal):
> A) Bob and Alice each have a RNG at their disposal. These
do not need to
> be synchronized or even similar -- they just have to
create numbers
> acceptably random for an OTP.
> B) Bob enciphers a message by XOR'ing the plaintext with
numbers from his
> RNG; he keeps a temporary copy of the numbers he used for
this message.
> He sends the enciphered message to Alice.
Eve stores a copy of ciphertext1
> C) Alice repeats this process using her RNG and sends the
result back to
> Bob.
Eve stores a copy of ciphertext2
Eve recreates Alice's pad. Pad = ciphertext1 XOR ciphertext2
> D) Bob uses his temporary copy of the numbers he used the
first time,
> XOR'ing them with Alice's return message to remove his
stuff from the
> mix. He sends the result to Alice.
>
> E) Alice uses her temporary copy to remove her
encipherment and retrieve
> the original plaintext message.
Eve performs the same operation based on Pad. Eve, Alice and
Bob all have the same plaintext.
> F) Both of them destroy their temporary copies of their
RNG numbers.
------------------------------
** 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
******************************
