Cryptography-Digest Digest #992, Volume #13 Sun, 25 Mar 01 06:13:00 EST
Contents:
Fractal Compression (Merrick)
Re: Fractal Compression - I meant ENCRYPTION (Merrick)
Re: 64 versus 128 (or bigger) bits cipher data block (SCOTT19U.ZIP_GUY)
Re: Operations for the DES (Jerry Proc)
Best encryption program for laptop? ([EMAIL PROTECTED])
Re: Operations for the DES (Merrick)
Re: 64 versus 128 (or bigger) bits cipher data block ("Scott Fluhrer")
Re: 64 versus 128 (or bigger) bits cipher data block ("Roger Schlafly")
Re: Uniform random integer ("Scott Fluhrer")
Re: 64 versus 128 (or bigger) bits cipher data block ("Tom St Denis")
Re: Fractal Compression ("Tom St Denis")
Re: Compression-encryption with a key ("Tom St Denis")
Re: 64 versus 128 (or bigger) bits cipher data block ("Scott Fluhrer")
Re: Fractal Compression - I meant ENCRYPTION (John Savard)
Re: Data dependent arcfour via sbox feedback (John Savard)
Re: decryprtion help please? (Hard)
Re: Keyloging (Peter Engehausen)
Re: Keyloging (Peter Engehausen)
Re: Uniform random integer (Frank Gerlach)
Re: Operations for the DES (Frank Gerlach)
DES C Source Code (Adrian Planinc)
Re: DES C Source Code (Frank Gerlach)
Re: Compression-encryption with a key (Mok-Kong Shen)
Re: Crack it! (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Merrick)
Subject: Fractal Compression
Date: Sun, 25 Mar 2001 02:20:22 GMT
Would someone please provide me with a simple explanation of Fractal
Compression?
Most of the search results I get are rather difficult to wade through,
and the simplest I found gave an example of using PI to offset the
values (eg abcdefg -> a+3 b+1 c+4 d+1 e+5 f+9 g+2 -> dcgejoi), which
somehow didn't seem quite right to me.
Any takers?
Thanks
------------------------------
From: [EMAIL PROTECTED] (Merrick)
Subject: Re: Fractal Compression - I meant ENCRYPTION
Date: Sun, 25 Mar 2001 03:06:23 GMT
Please excuse my mistake.
I meant Encryption as opposed to Compression.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: 64 versus 128 (or bigger) bits cipher data block
Date: 25 Mar 2001 03:12:24 GMT
[EMAIL PROTECTED] (Peter) wrote in <[EMAIL PROTECTED]>:
>Someone can explain me main reasons (or all) for which 128 bits block
>is better than 64 bits block?. I had made think on this and I found
>some goals for use bigger block but I still dont know if they are
>primary.
>
>Best regards
>
>Peter
>
Peter some rough rules all else being equal
1)The bigger the block the more secure the encyption
2)The bigger the key space the more secure the encryption
any byte size file can be mapped bijectively to 64 or 128
block files. So no reason to use 64 bit block if your machine
can handle bigger.
If your have problems with speed or space you can go to
smaller but will be less secure.
Many will falsely tell you that you don't need bigger keys
or blocks becase a blind seach of small keys commonly in
use would take tell sun burns out.
Will thats the main mistake through out history. Bigger is
better if it fits your needs.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Jerry Proc <[EMAIL PROTECTED]>
Subject: Re: Operations for the DES
Date: Sun, 25 Mar 2001 04:22:23 GMT
William Hugh Murray wrote:
> How many computer operations does a DES operation require?
>
> The context of my question is a program on the History Channel about
> NSA. At one point they assert that that they once had a machine that
> could do 73 quadrillion computer operation in five seconds. I thought
> that this was an interesting set of numbers in which to express the
> speed of a computer.
Hi William,
About a week ago there was an announcement (URL) posted to this group
that IBM will build
a supercomputer called Blue Gene with over one million processors to be
used for research into
protein structures.
I distinctly remember reading that the IBM says that Blue Gene will run
at 1 petaflops (1 quadrillion) per second.
Seems like the History Channel is referring to some machine beyond Blue
Gene :-)
--
Jerry Proc VE3FAB
e-mail:[EMAIL PROTECTED]
http://www3.sympatico.ca/hrc/haida
HMCS HAIDA Historic Naval Ship. Toronto, Ontario
------------------------------
From: [EMAIL PROTECTED]
Subject: Best encryption program for laptop?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 25 Mar 2001 04:38:30 GMT
My job is changing, and is going to require me to do some travelling.
I would like to purchase a laptop, and continue to keep my home
finances, and other private data, on it.
what would be the best way to keep data safe, in case the laptop was
stolen? Which encryption program? And, should it be encryption alone,
or encryption coupled with a secure os like NT?
Thanks.
------------------------------
From: [EMAIL PROTECTED] (Merrick)
Subject: Re: Operations for the DES
Date: Sun, 25 Mar 2001 04:39:40 GMT
>I distinctly remember reading that the IBM says that Blue Gene will run
>at 1 petaflops (1 quadrillion) per second.
>Seems like the History Channel is referring to some machine beyond Blue
>Gene :-)
A while back the NSA was taken to court (!) by John St Clair Akwei
(Civil Action 92-0449).
During the course of the trial, the NSA was required to reveal certain
technological information, which showed them to be about 8 years ahead
of the current technology, and already using nanotechnology for
computing purposes.
Don't be too surprised if that quote from the history channel refers
to one of their decommissioned "old" computers...
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: 64 versus 128 (or bigger) bits cipher data block
Date: Sat, 24 Mar 2001 20:32:24 -0800
Peter <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Someone can explain me main reasons (or all) for which 128 bits block
> is better than 64 bits block?. I had made think on this and I found
> some goals for use bigger block but I still dont know if they are
> primary.
Well, it mostly has to do with security when encrypting a large number of
blocks with the same key.
To take a common example, suppose you are encrypting mode a large number of
blocks (either one huge message, or lots of smaller ones) using a mode (such
as CBC or CFB) that effectively randomizes the input into the block cipher
proper. Then, by applying the birthday paradox, we would expect to find two
different places when the exact same input to the block cipher (and hence
the exact same output from the block cipher) after encrypting a number of
input blocks which is about the square root of the total number of possible
input blocks. For both CBC and CFB, which corresponds to the attacker being
able to derive a linear relationship between the corresponding two plaintext
blocks.
Hence, with a 64 bit cipher, an attacker can expect to be able to discern
the xor of two plaintext blocks (and no, he doesn't get the choose the
plaintext blocks) after scanning through about 2**32 * 8 = 2**35 bytes of
output, which is a lot, but not totally impractical. In addition, by
scanning through a lesser amount of ciphertext, he has a smaller but nonzero
chance of finding such a relationship. With a 128 bit cipher, he doesn't
have a good expectation of finding such a relationship until he scans
through about 2**64 * 16 = 2**68 bytes of output, which is totally
impractical. And, the probability of finding such a relationship with
reasonable amounts of ciphertext is close enough to zero that we can usually
ignore it.
--
poncho
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: 64 versus 128 (or bigger) bits cipher data block
Date: Sun, 25 Mar 2001 05:01:33 GMT
"Peter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Someone can explain me main reasons (or all) for which 128 bits block
> is better than 64 bits block?. I had made think on this and I found
> some goals for use bigger block but I still dont know if they are
> primary.
I think the main arguments related to encrypting a large number of blocks
with the same key. If I encrypt 2^32 random blocks, then there is a fair
chance that a block will occur twice and hence also show up as repeated
ciphertext. (Birthday paradox)
With 128-bit blocks, you'd have to process 2^64 blocks before having
similar problems, and no one is going to be doing that in the near future.
(That would be about a billion terabits of data.)
It is traditional for blocksizes to be a power of 2.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Uniform random integer
Date: Sat, 24 Mar 2001 20:56:02 -0800
Benjamin Goldberg <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I'm trying to find the name of the following algorithms:
Sorry, can't help you with names...
>
> rrange : An upper bound on the pre-existing rng.
> rand() : An rng which produces integers in the range 0..(rrange-1).
>
> int ranmod_a(int mod) {
> int val = 0, max = 1;
> do {
/* A */
> while( max < mod ) {
> max *= rrange;
> val *= rrange;
> val += rand();
/* B*/
> }
/* C */
> if( val >= (max%mod) ) {
> return val % mod;
> }
> max %= mod;
> val %= mod;
/* D */
> } while(1);
> }
Looks good (assuming rrange>1, of course). I believe that, using the
invariant "val is equidistributed in the range [0, max-1]" at points I
marked A, B, C and D, you can prove its correctness.
The "val %= mod;" line is unnecessary, as val<mod at that point.
>
> int ranmod_b(int mod) {
> int max = rrange % mod, val;
> do {
> val = rand();
> } while( val < max );
> return val % mod;
> }
ranmod_b doesn't work (infinite loops) if rrange < mod.
>
> Also, assuming that rand() gives a good distribution, and integers don't
> overflow, are there any situations where the above algorithms don't
> work?
--
poncho
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: 64 versus 128 (or bigger) bits cipher data block
Date: Sun, 25 Mar 2001 05:49:02 GMT
"Peter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Someone can explain me main reasons (or all) for which 128 bits block
> is better than 64 bits block?. I had made think on this and I found
> some goals for use bigger block but I still dont know if they are
> primary.
Mainly a larger block provides for a larger transform (duh). This means you
can use it in various constructions longer since the threat of a collision
is lower. Things like MACS and Hash constructions are vastly simplified.
This doesn't mean a 128-bit block cipher is always more secure then a 64-bit
block cipher (um Lucifer anyone?).
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Fractal Compression
Date: Sun, 25 Mar 2001 05:50:50 GMT
"Merrick" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Would someone please provide me with a simple explanation of Fractal
> Compression?
>
> Most of the search results I get are rather difficult to wade through,
> and the simplest I found gave an example of using PI to offset the
> values (eg abcdefg -> a+3 b+1 c+4 d+1 e+5 f+9 g+2 -> dcgejoi), which
> somehow didn't seem quite right to me.
>
> Any takers?
Wrong forum (try comp.compression)
Fractal compression takes advantage of self similiarities of an image in the
spatial domain(s). By breaking an image into IFS's (can't remember what
that stands for) you can compress the image by making reference to other
IFS's. Yadada....
Anyways Mark Nelsons book covers IFS's somewhat (The Data Compression Book).
Or ask in the right forum!
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Compression-encryption with a key
Date: Sun, 25 Mar 2001 05:52:04 GMT
"amateur" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Compression-encryption with a key is exist or no?
> The same algo compress and encrypt simultaneously the plain-text with a
> secret key, that is what I mean.
There are ways to encode a huffman trie such that it's dependent on a key.
But such systems are vulnerable to chosen plaintext attacks and are
generally inefficient and weak.
So it's possible just not a good idea yet.
Tom
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: 64 versus 128 (or bigger) bits cipher data block
Date: Sat, 24 Mar 2001 21:45:54 -0800
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:iFfv6.125875$[EMAIL PROTECTED]...
>
> This doesn't mean a 128-bit block cipher is always more secure then a
64-bit
> block cipher (um Lucifer anyone?).
ObHistoricalNit: Lucifer has a 64 bit block and a 128 bit key. Thus, for
the purposes of this thread, it's a "64-bit block cipher"
--
poncho
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Fractal Compression - I meant ENCRYPTION
Date: Sun, 25 Mar 2001 05:52:03 GMT
On Sun, 25 Mar 2001 03:06:23 GMT, [EMAIL PROTECTED] (Merrick) wrote,
in part:
>I meant Encryption as opposed to Compression.
Although the fractal compression of images is efficient and useful,
the use of chaos theory, strange attractors, and the like, in
cryptography has not proven to be of much use.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.crypt.research
Subject: Re: Data dependent arcfour via sbox feedback
Date: 24 Mar 2001 23:09:50 -0800
On 23 Mar 2001 14:53:51 -0800, Ken Savage <[EMAIL PROTECTED]> wrote,
in part:
>Any thoughts? Replies via newsgroup or email -- I read both :)
Making something like RC4 dependent on the plaintext will collide with
Terry Ritter's Dynamic Substitution patent.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Hard)
Subject: Re: decryprtion help please?
Date: Sun, 25 Mar 2001 07:21:00 GMT
A "buddy" had asked me yesterday, if it would be possible to "migrate"
all of our pins from the current main system to the "new test pin
vault".
You the new "go to" guy around the office, are you?
Get the...
On Sat, 24 Mar 2001 16:13:24 GMT, "rh" <[EMAIL PROTECTED]> wrote:
>A buddy had asked me yesterday, if it would be possible to
>migrate all of our pins from the current main system to the new test pin
>vault<snip>
------------------------------
From: Peter Engehausen <[EMAIL PROTECTED]>
Subject: Re: Keyloging
Date: Sun, 25 Mar 2001 07:13:16 -0100
Reply-To: [EMAIL PROTECTED]
Thank you, Nemo!
You posting was very usefull!
------------------------------
From: Peter Engehausen <[EMAIL PROTECTED]>
Subject: Re: Keyloging
Date: Sun, 25 Mar 2001 07:13:53 -0100
Reply-To: [EMAIL PROTECTED]
I mean youR posting... Sorry.
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: Uniform random integer
Date: Sun, 25 Mar 2001 10:33:00 +0200
NEVER use rand() from the c std lib for security-related purposes. To easy
to guess the next value from the current. Instead, use DES or RC4 or any
other strong symmetric cipher.
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: Operations for the DES
Date: Sun, 25 Mar 2001 10:37:48 +0200
Also, they do not only have a special relationship with the brits, but also
with some aliens !
------------------------------
Date: Sun, 25 Mar 2001 17:13:46 +0800
From: Adrian Planinc <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: DES C Source Code
Hello....
I am looking for an implementation (source code) of DES in C/C++ that
compiles on Linux and is as simple as possible - ie...closely follows
the original standard.
I have been assigned the task of analysing and modifying the code, and
thus need the original DES, and not Triple DES or any sort of algorithm
that's based on DES but is not proper DES. I've been told this is the
best place to ask...:)
Thanks in advance and please come back in email as I don't check these
forums too often.....
Cheers,
Adrian
[EMAIL PROTECTED]
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: DES C Source Code
Date: Sun, 25 Mar 2001 11:49:38 +0200
Adrian Planinc wrote:
> Hello....
>
> I am looking for an implementation (source code) of DES in C/C++ that
> compiles on Linux and is as simple as possible - ie...closely follows
> the original standard.
>
> I have been assigned the task of analysing and modifying the code, and
> thus need the original DES, and not Triple DES or any sort of algorithm
> that's based on DES but is not proper DES. I've been told this is the
> best place to ask...:)
>
> Thanks in advance and please come back in email as I don't check these
> forums too often.....
>
> Cheers,
> Adrian
>
> [EMAIL PROTECTED]
I have been told there are search engines. Somwhere in yankee-land.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Compression-encryption with a key
Date: Sun, 25 Mar 2001 13:00:08 +0200
amateur wrote:
>
> Compression-encryption with a key is exist or no?
> The same algo compress and encrypt simultaneously the plain-text with a
> secret key, that is what I mean.
You have the following possibilities (what you do is your
own decision):
(1) A fixed compression (without key) and then encrypt. This
is common but is not what you are asking.
(2) A variable compression dependent on a key, e.g.
an adaptive Huffman compression, with an initial
constellation (symbol frequencies) set so as to be
dependent on a key value. One simple way of doing
this is to use a PRNG with a key as seed to generate a
sequence of a certain length and feed it into an
adaptive Huffman and discard the output before feeding
the proper sequence to be compressed. Without
being followed by a normal encryption processing,
this is considered insecure.
(3) Do (2) and then encrypt.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Crack it!
Date: Sun, 25 Mar 2001 12:59:53 +0200
amateur wrote:
>
> The core of your post is clear. Is about "Thus we describe in the
> present note a more general substitution from an input alphabet to an
> output alphabet, where the symbols of the alphabets have variable number
> of bits as code values."
> You are discussing the issue of length-block : variable or not. What
> your are considering as new ( even if it is not new. I will send
> references about variable block size) is the "variability " of
> size-block.
> You are talking about encrypting group of bits.
Read the literature to find out what 'block' in crypto
commonly means. I said 'number of bits' of code values.
In ASCII 8-bit code, each symbol e.g. 'a' is coded into
8 bits. This is a constant length code, since all the 256
symbols are coded with 8 bits. In a more general case,
e.g. the Huffman code, each symbol will (in general) have
different number of bits as representation. Thus a Huffman
code (a term without further qualification) is more genearal
than ASCII and includes the latter as a special case.
In the same sense, encrypting groups of bits, n bits
(without specifying in discussion what n is) is more
general than considering specific cases of encrypting
given number of bits, say, 6 bits, 2 bits and 1 bit at
a time, the latter being the case you consider. So
I considered a more general encryption than yours and
includes yours as one special case. Do you understand
this or not ?? (See also below.)
> My idea is very simple : I encrypt every bit (stream cipher) by a value.
> And not any value. This value has to be clearly belonging at one
> category. I use two categories based on one property : (odd or even,
> consonants or vowels etc...).
> What I had hidden in my algo just to see how people react is more
> complicated.
> So before encrypting using the two categories, I use another algo which
> allow me to assign to every character a single and specific symbol or
> value. Without using any dictionnary. The recipent will retrieve all the
> symbols using a long algo that I did not published yet.
> In my idea the step cesar is useless. I knew it before.
> I use another algo instead of cesar.
> But it is very long to expose even if it is easy to compute.
> You have to talk about the idea of two categories which is new. Not
> about enciphering bit. All stream ciphers encrypt one bit at once.
> You are denying what is new : the idea of two categories.
>
> I hope it was clear.
If you use even/odd, then you have the mapping either
0 --> {0, 2, 4, ....} 1 --> {1, 3, 5, ....}
or
0 --> {1, 3, 5, ....} 1 --> {0, 2, 4, ....}
Doesn't that belong to the GENERAL type
0 --> {g1, g2, .... gm} 1 --> {h1, h2, .... hn}
that I mentioned in an earlier post? The same applies
to the case of consonants/vowels.
I am afraid that you are not clear of general/special
issue. If a general case is treated, then it is not
necessary to consider special (particular) cases in
scientific discussions. Analogy: If my friend goes to a
country where one drives on the left side, I need to remind
him only that in that country one drives on the left,
I needn't say to him that in city A of that country one
drives on the left, in city B one drives on the left, in
city C one drives on the left ............. Do you see
the point? Do you see now that your scheme is a very
special case that is included in what I mentioned in my
article last year?
M. K. Shen
------------------------------
** 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
******************************
