Cryptography-Digest Digest #662, Volume #12 Tue, 12 Sep 00 13:13:01 EDT
Contents:
Re: Problem with Tiger hash algorithm and binary files (John Myre)
Re: nice simple function (Mok-Kong Shen)
[Q] Design criteria for sboxes in Tiger/192 ? (Runu Knips)
Re: DCSB: RSA Expiration Fundraiser for EFF, Downtown Harvard Club of (Mok-Kong
Shen)
Re: Steganography and secret sorting (Ray Dillinger)
Encryption speed of *fish (Runu Knips)
Re: [Q] Design criteria for sboxes in Tiger/192 ? (Mok-Kong Shen)
Re: PRNG ("NP")
Re: Kryptcon ([EMAIL PROTECTED])
Re: RSA?? (Doug Stell)
Re: Bytes, octets, chars, and characters (Jerry Coffin)
Re: Getting Started, advice needed (FAQs , yes I read them) ("Scott Fluhrer")
Re: Encryption speed of *fish (Mark Wooding)
Re: Intel's 1.13 MHZ chip (Jerry Coffin)
Re: Bytes, octets, chars, and characters (Dan Pop)
Re: RSA?? (Rich Wales)
Re: IDEA - PGP (Arturo)
----------------------------------------------------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Problem with Tiger hash algorithm and binary files
Date: Tue, 12 Sep 2000 07:48:42 -0600
Daniel Leonard wrote:
<snip>
> While on the subject, which reference implementation is the right one: the
> one from Eli Biham site, or the one from Ross Anderson site ?
How are they different? Do they give different answers?
JM
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: nice simple function
Date: Tue, 12 Sep 2000 16:42:40 +0200
Tom St Denis wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> > I guess that, while employing different fields/rings may
> > buy you some complexity, always using linear functions is
> > much poorer than using non-linear functions. Now you
> > yourself will have the difficulty of inverting non-linear
> > functions. However, this is no problem if the functions
> > are used e.g. in a Feister cipher so that no inversion
> > is needed.
> >
> > I might be wrong and experts would like to correct me.
>
> Well the idea is to use it in a Feistel Network.
>
> The function is actually not a linear problem to solve without two
> pairs of inputs and outputs. I.e It can't be solved with linear
> algebra with only one pair.
>
> Also the std pair-wise decorrelation function f(x) = a.x + b is immune
> to order 2 differential and linear cryptanalysis iff (a, b) are random
> variables and you cannot find two pairs of inputs/outputs.
>
> My goal is to change the function so even knowledge of two pairs is not
> sufficient, but somehow I have the feeling my other idea f(x) = (a.x ++
> b.x) + c, won't work well either... I have to think it over
Perhaps I haven't been explicit. If you use non-linear
functions, you probably don't have to use more than one
ring in your computations and can achieve similar, if not
superior, results.
M. K. Shen
------------------------------
Date: Tue, 12 Sep 2000 16:51:55 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: [Q] Design criteria for sboxes in Tiger/192 ?
Eli Biham has designed a hash function, Tiger/192
(see http://www.cs.technion.ac.il/~biham/ and
http://www.cs.technion.ac.il/~biham/Reports/Tiger/).
It also has a nice paper which describes almost
everything except the design of the Sboxes. Does
anyone have any information (or an idea) how they
have been constructed ?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DCSB: RSA Expiration Fundraiser for EFF, Downtown Harvard Club of
Date: Tue, 12 Sep 2000 17:09:49 +0200
Robert Hettinga wrote:
>
> In Celebration of the
>
> EXPIRATION OF THE RSA PATENT
One patent is gone. But in a recent thread, there were
mentioned several patents that seem to fairly 'generally'
and gravely affect PK. Unfortunately, the discussions so
far in that thread didn't lead in my view to any
informations essential for the practice. In other words,
we are yet almost completely ignorant in that matter.
M. K. Shen
------------------------------
From: Ray Dillinger <[EMAIL PROTECTED]>
Subject: Re: Steganography and secret sorting
Date: Tue, 12 Sep 2000 15:01:41 GMT
Matthew Skala <[EMAIL PROTECTED]> wrote:
: So to hide a message, I envision taking a large file, sorting it, and then
: expressing the first few bits of the secret data as a number between 0 and
: n-1 and using that number to choose one of the sorted lines to be first in
: the output. Then I use the next few bits of the secret data to choose a
: number between 0 and n-2 and use that to choose one of the remaining
: lines, and so on. The receiver can take the file I transmit, sort it, and
: recover the sequence of numbers I chose, which in turn can be converted
: back to the secret data.
: Would anyone care to comment on this scheme? Do you know if anyone's
: investigated schemes like this before, where a secret message is concealed
: in the order of a bunch of things that don't have to be in any particular
: order?
I was recently writing a pair of functions to turn a permutation into
a number and vice versa, for a key generator (figured more likely to
get good keys if I told the users to shuffle a deck of cards than if
I told them to pick a passphrase), and it turns out there is a nice
way to get a perfect transformation from number space to permutation
space.
The thing is, the permutation *IS* a number -- it just has very strange
rules about what base each digit is in. Think about it this way:
The last element in the permutation is the "zero's place", so named
because it doesn't transmit any information at all -- it was basically
a "choice" of the last element and nothing else. The second-to-the-
last element is the "units place". It was a choice of two elements,
so it's a binary digit. The third-to-the-last element of a permutation
is the "two's place", and it's a ternary digit. The fourth-to-last
element is the "sixes place" ('cause 1x2x3=6) and it's a quaternary
digit. The fifth-to-last element is the "twenty-fours place" ('cause
1x2x3x4=24) and it's a base-5 digit. And so on.
So you can take your message, interpret it as a number, and decide
what the minimum size of the permutation required to represent it is
(an N-element permutation can hold a number up to N!). Then, at each
point in creating the permutation, from most significant "digit" to
least significant "digit", just decide how many units of that size
you need and pick the remaining permutation element that corresponds
to that choice. Don't forget that one of the elements -- maybe whichever
is first among those remaining -- has to represent "zero".
This way, your message is a number, and the permutation is a number,
and you get a perfect one-to-one correspondence between message and
permutation.
The downside of course is you have to calculate with bignums.
Hope that's not a problem.
Bear
------------------------------
Date: Tue, 12 Sep 2000 17:07:25 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Encryption speed of *fish
Mark Wooding wrote:
> Some will tell you that Twofish is faster. It depends. If you really
> pull all of the stops out, then Twofish is faster on some
> architectures.
I'm surprised to hear that Twofish is faster than Blowfish. The
encryption loop of Blowfish is extremely simple
a ^= p[i];
b ^= sbox1[(a >> 000) & 0xff] + (sbox1[(a >> 010) & 0xff]
^ (sbox2[(a >> 020) & 0xff] + sbox3[(a >> 030) & 0xff]);
while one round of Twofish looks like this (in my own AFAIK very
fast implementation):
x = ( (k->s[0][((a) >> 000) & 0xff]) ^ (k->s[1][((a) >> 010) & 0xff])
^ (k->s[2][((a) >> 020) & 0xff]) ^ (k->s[3][((a) >> 030) & 0xff]));
y = ( (k->s[1][((b) >> 000) & 0xff]) ^ (k->s[2][((b) >> 010) & 0xff])
^ (k->s[3][((b) >> 020) & 0xff]) ^ (k->s[0][((b) >> 030) & 0xff]));
x += y; y += x;
x += k->t[i++];
y += k->t[i++];
c = rotr (c ^ x, 1);
d = rotl (d, 1) ^ y;
Both algorithms have 16 rounds. The round of Twofish is
substantly more complex than that of Blowfish, isn't it ?
It is Blowfish with some additional instructions (an
addition, a rotation, and a xor). So how can Twofish ever
be faster than Blowfish ???????????????
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: [Q] Design criteria for sboxes in Tiger/192 ?
Date: Tue, 12 Sep 2000 17:38:40 +0200
Runu Knips wrote:
>
> Eli Biham has designed a hash function, Tiger/192
> (see http://www.cs.technion.ac.il/~biham/ and
> http://www.cs.technion.ac.il/~biham/Reports/Tiger/).
> It also has a nice paper which describes almost
> everything except the design of the Sboxes. Does
> anyone have any information (or an idea) how they
> have been constructed ?
I don't know. But I like to point out that the same
question apparently could apply to almost all well-
known block ciphers that have S-boxes, starting with
DES, whose design rationales are kept secret even
today. I always consider it extremely admirable that
experts are able to solidly evaluate the strength of
algorithms whose S-boxes don't have completely stated
design criteria and don't have computational means for
eventual reproduction. It's quite probable that they
are endowed with extra mental capabilities to read
the minds of the authors of the algorithms and hence
are able to work without requiring complete official
documents, capabilites which the amateurs and laymen
definitely couldn't have even in their dreams.
M. K. Shen
============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "NP" <[EMAIL PROTECTED]>
Subject: Re: PRNG
Date: Tue, 12 Sep 2000 17:40:10 +0200
> e=e/double(pvalue_count-1)*2.*1e6
My resuls are between 500 and 600
Do you have some references ?
NP
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Kryptcon
Date: Tue, 12 Sep 2000 15:28:26 GMT
While I appreciate you taking the time to look at
my program, I do not appreciate you being a jerk
and telling me that it is crap. My original post
was asking for anybody who would wish to help a
student with his research in cryptography. If
you can't understand that, maybe you should just
keep your thoughts to yourself.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: RSA??
Date: Tue, 12 Sep 2000 15:26:30 GMT
On 9 Sep 2000 20:38:44 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote:
>]Can any government in the world crack it?
>
>You will have to ask them. If they can, they have not told anyone.
Nor would they tell anyone. It would clearly be in their best interest
(the interest of national security) if they could crack it and
everyone else (the bad guys) thought it was secure enough to feel
comfortable using it. That would the ideal situation for any
government.
>]> Um, no to the best of my knowledge when used correctly RSA is still
>]> considered secure.
Bear in mind that "crack" is relative to such things as key size,
etc..
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: Tue, 12 Sep 2000 10:01:23 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> However, it now seems to be a widespread portability assumption that
> `int', and even `long', are 32 bits wide. This necessitated the
> creation of `long long': if people had stuck to the rules, a 64-bit
> `long' type would have worked without problems, as I see it. Thus
> in a way, the C standard has been tained by `32-bitness'.
Adding long long did NOT have to do with keeping from breaking
programs that assumed long was 32 bits wide. Rather, it was about
adding a type that was guaranteed to be a minimum of at least 64 bits
wide. There have been compilers (e.g. the one for Tru64 UNIX) that
have had long as a 64-bit type for quite some time, and portability
to them doesn't seem to be a major problem at all.
OTOH, if you want to write portable code that can deal with variables
of more than 32 bits, your only choice prior to C99 was to use some
bignum library. That's probably reasonable if you're doing something
like DH or RSA, but it's a lot less palatable to many people for
things like offsets in files. When C90 was approved, files of more
than 4 gigabytes were fairly unusual, and people working with them
generally had to jump through all kinds of hoops anyway. Nowadays,
they're common, and people expect to work with them easily...
--
Later,
Jerry.
The Universe is a figment of its own imagination.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Getting Started, advice needed (FAQs , yes I read them)
Date: Tue, 12 Sep 2000 08:53:17 -0700
Andy C <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On 11 Sep 2000, [EMAIL PROTECTED] (Scott Fluhrer) spake in
> <8pjtlg$ncn$[EMAIL PROTECTED]>:
>
>
> >One obvious thing to ask: if you were doing a brute force attack, how
would
> >you recognize the plaintext?
>
> Well I looked at that - and it seemed to be compressed. So I checked
> out Zlib since thats a common crompression libe due to it being
> unencumbered, and thats what was used to compress the data group
> before it gets run through this. I was thinking of using the
> compression header as known text. After all, other than the tree
> at the front, compressed data is supposedly fairly random?
>
> Is that the right way to go about thnking about attacking this?
Well, yes, that's the obvious way to go, assuming there is a header. If you
think you know what the header looks like, try it with an example
ciphertext. Even if you get only a partial block of known plaintext, that
reduces your time effort -- 16 bits of known plaintext leaves you with 2**16
work.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Encryption speed of *fish
Date: 12 Sep 2000 16:17:20 GMT
Runu Knips <[EMAIL PROTECTED]> wrote:
> Mark Wooding wrote:
> > Some will tell you that Twofish is faster. It depends. If you really
> > pull all of the stops out, then Twofish is faster on some
> > architectures.
>
> I'm surprised to hear that Twofish is faster than Blowfish. The
> encryption loop of Blowfish is extremely simple
[snip]
> while one round of Twofish looks like this (in my own AFAIK very
> fast implementation):
Ahh, yes, but it encrypts twice as much at a time. Loading a big chunk
is often more than twice as fast as loading two half-sized chunks
separately, and similarly for storing. The Counterpane really-optimized
version gets the key mixing for free. And the rotates are either very
cheap or free in many architectures.
-- [mdw]
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Intel's 1.13 MHZ chip
Date: Tue, 12 Sep 2000 10:15:28 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> On Mon, 11 Sep 2000 13:18:54 -0400, "Abyssmal_Unit_#3"
> <[EMAIL PROTECTED]> wrote, in part:
>
> >MECL (Motorola Emitter Coupled Logic) architecture has been available
> >for close to 25 years with capability to perform at 1 to 2 gig
> >rates.
[ ... ]
> Also, the 1 GHz speed of a microprocessor is for a machine cycle,
> which involves many elementary logic operations. The figure you quote
> may be the speed of individual NAND gates.
Seymour Cray's last machines were running at a 1 GHz clock speed
around 10 years ago now. OTOH, the earlier comment about the
military having used this level of technology for that long appears
likely to be more or less erroneous -- essentially all the orders for
these machines were cancelled, so only three were ever built and
unless memory deceives me, none of those ever went to the military,
NSA or anything similar. One stayed at the Cray plant here in
Colorado Springs. One went to the University of Colorado. Offhand I
don't remember exactly where the third went, but it seems like it was
to a university as well. FWIW, at one time the government HAD
ordered them, but they ended up getting so far behind schedule that
the orders got cancelled.
At least offhand, I don't know of any other machines in the same era
running at the same clock speed. There were, of course, various
massively parallel machines that achieved similar (and perhaps
greater) overall speed, but not at the same clock speed (and at the
expense of being applicable to a more limited range of problems).
--
Later,
Jerry.
The Universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Dan Pop)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: 12 Sep 2000 16:16:14 GMT
In <[EMAIL PROTECTED]> Jerry Coffin <[EMAIL PROTECTED]>
writes:
>OTOH, if you want to write portable code that can deal with variables
>of more than 32 bits, your only choice prior to C99 was to use some
>bignum library. That's probably reasonable if you're doing something
>like DH or RSA, but it's a lot less palatable to many people for
>things like offsets in files. When C90 was approved, files of more
>than 4 gigabytes were fairly unusual, and people working with them
>generally had to jump through all kinds of hoops anyway. Nowadays,
>they're common, and people expect to work with them easily...
Pray tell, what does C99 do to help people deal with large files easier
than in the C89 days? Is long long related in any way to fseek and
friends?
Dan
--
Dan Pop
CERN, IT Division
Email: [EMAIL PROTECTED]
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
------------------------------
From: [EMAIL PROTECTED] (Rich Wales)
Subject: Re: RSA??
Date: 12 Sep 2000 16:49:34 -0000
Someone (I'm not sure who) wrote:
> > > Can any government in the world crack [RSA]?
Bill Unruh replied:
> > If they can, they have not told anyone.
Doug Stell replied:
> Nor would they tell anyone. It would clearly be in their
> best interest (the interest of national security) if they
> could crack it and everyone else (the bad guys) thought
> it was secure enough to feel comfortable using it.
OK, how about this little thought experiment. Suppose you somehow
stumbled upon an easy solution to one of the "hard" math problems that
form the basis for modern cryptography -- factorization, discrete
logarithms, etc. If your discovery were to become common knowledge,
it would render much of the present-day crypto infrastructure useless.
What would you do?
Would you post your work to the net immediately, before any government
agency had a chance to suppress it -- figuring that everyone currently
depending on encryption needed to know about the problem ASAP, and
perhaps hoping to secure fame and fortune for yourself (or at least
make it impossible for anyone -- spooks, organized crime, etc. -- to
pressure or threaten you regarding dissemination of your discovery)?
Would you keep your discovery a deeply guarded secret forever -- for
fear of what it would do to human rights groups which depend on PGP,
or because it could lead to a collapse of a world economy dependent
on secure e-commerce, or perhaps out of a concern over what your own
government's spooks might decide to do to you covertly if they ever
found out about your work?
Would you try to report your work to your own government's security
people, to make sure they knew about it (in case they didn't already)
-- even though this might well mean you would be forbidden to speak a
word about it to anyone else, might find travel restrictions imposed
upon you, or could even become the target of foreign spies or crime
bosses eager to get their hands on your discovery?
Would you do something else altogether?
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED.
RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA
------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Arturo)
Subject: Re: IDEA - PGP
Date: Tue, 12 Sep 2000 15:58:19 GMT
On Sun, 10 Sep 0 07:39:48, "December" <[EMAIL PROTECTED]>
wrote:
>Hi:)
>
>Right, my computer setup is a Commodore Amiga 1200. It is likely I am
>going offline soon and wish to send a friend in the US disks now and
>again, which will contain personal texts. I want this to be encrypted and
>currently the best looking method is IDEA - found in PGP.
>
>This method doesn't require exchange of keys, only a passphrase.
>
>Stop me at any time if I'm wrong.
Then stop now. If you use PGP, you need to exchange public keys.
Remember that PGP is a hybrid system. Your message is encrypted to a symmetric
key (say, IDEA) called session key, and that session key is encrypted with the
public (or asymmetric) key, RSA or D-H.
There�s an alternative: use the "conventional encryption" feature when
encrypting. So your friend will only need the passphrase for that encryption
process. He/she doesn�t even need to have PGP installed, for he/she will
receive a .exe file, that when executed will prompt for the passphrase. Now you
only need to give your friend the passphrase without the friendly spy
noticing...
>
>As you can see, I'm not up on the subject that is cryptography, so please
>be gentle with your replies:P
Your life is spared ;-))
------------------------------
** 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
******************************
