Cryptography-Digest Digest #730

2000-09-20 Thread Digestifier

Cryptography-Digest Digest #730, Volume #12  Thu, 21 Sep 00 00:13:01 EDT

Contents:
  Re: Does this mean anything? (Jim Gillogly)
  Re: md5 fail -x test under Digital UNIX C Compiler (John Myre)
  Re: Intel's 1.13 MHZ chip (Jerry Coffin)
  Re: ExCSS Source Code (Bryan Olson)
  Re: Dangers of using same public key for encryption and signatures? (Paul Rubin)
  Maurer's FastPrime implementation. (RFC) (Vipul Ved Prakash)
  Re: SUN SPOT 6.51 BILLION square kilometers in size ([EMAIL PROTECTED])
  Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption (John Savard)
  Re: CDMA tracking (was Re: GSM tracking) (Roger Schlafly)
  Re: Software patents are evil. (Bill Unruh)
  Re: ExCSS Source Code (Bill Unruh)
  Re: Algebra, or are all block ciphers in trouble? ("Douglas A. Gwyn")
  Re: Questions about how to run a contest ("Douglas A. Gwyn")



From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Does this mean anything?
Date: Wed, 20 Sep 2000 23:20:41 +

JustAsking wrote:
> Take a seed number of sqr(aProductOfTwoPrimes)+1 (S).
> 
> Loop
>T = S^2 - N
>if sqr(T) is an integer, end loop, calculate prime1 and prime2
>S = S + 1
> until ??
> 
> comments?

Yes, it means something: if prime1 and prime2 are close to sqrt(N)
you can factor N easily.  Fermat discovered the method.
-- 
Jim Gillogly
Mersday, 29 Halimath S.R. 2000, 23:18
12.19.7.10.3, 12 Akbal 6 Chen, Fifth Lord of Night

--

From: John Myre <[EMAIL PROTECTED]>
Subject: Re: md5 fail -x test under Digital UNIX C Compiler
Date: Wed, 20 Sep 2000 17:33:26 -0600

[EMAIL PROTECTED] wrote:

>  I assume it is not an algorithm bug, most likely the compiler,
>  but I can't figure out what is going on. Any suggestions ?


Guess #1: little-endian vs big-endian; maybe there is a compile-time
flag to go the other way.

JM

--

From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Intel's 1.13 MHZ chip
Date: Wed, 20 Sep 2000 17:50:12 -0600

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...

[ ... ] 

> To recapitulate, you accused DIRNSA (which one would be easy
> to pin down from the dates involved) of irrationally forcing
> procurement of suboptimal and very expensive equipment, which
> if true would be malfeasance of a high order.

Doug, I never said anything about the equipment being suboptimal or 
anything like it.  The equipment was very expensive, and I'm not 
personally convinced that the original reasons for obtaining it were 
rational.  That does NOT mean the equipment was suboptimal, or that 
it wasn't useful.  In short, no accusation of malfeasance was made.

What I DID say was that I was convinced that justification for the 
purchases was made after the decision to make those purchases had 
already taken place.  I stand by that statement.  I never said that 
suboptimal equipment was purchased. I never said that anybody paid 
more for the equipment than it was worth.  I never said that uses and 
justification for the machines weren't found -- quite the contrary, I 
was quite specific in saying that I believe such justification WAS 
found, merely after the decision to make the purchase had already 
been made.

> I pointed out
> that that was a very serious accusation to make, one that
> would be justified only if you had evidence to back it up,
> and otherwise verging on libel.  Instead of producing a shred
> of supporting evidence, you then engaged in sophistry and
> sophomoric literalism.  A morally honest person would produce
> support for their accusation or else retract it, not argue
> beside the point.

I suppose you can claim anything you want to about a "morally honest 
person", since the number of definitions of "moral" seems to be 
roughly equal to (if not greater than) the number of people giving 
definitions.  Despite this, I'll stand by the fact that what I said 
in the first place was 100% honest, with no sophistry, literalism or 
any other sort of qualification necessary: I said that I believed 
something to be true, and I most certainly do believe it to be true.  
If you honestly think that what I've done is illegal, please do your 
duty and file a complaint with the Attorney General's office.

Whether that happens or not, I'm finished posting in this thread, at 
least on this subject.  If you want to continue posting, go for it, 
but I'll not be dragged into still more of your off-topic arguments.

-- 
Later,
Jerry.

The Universe is a figment of its own imagination.

--

From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: ExCSS Source Code
Date: Wed, 20 Sep 2000 23:47:45 GMT

Bill Unruh:
> The whole purpose in copyright is to free access to
> copyrighted works, not to control them

Actually it's to "promote the progress of science and the
useful arts."

> It does so by controlling copying so that the person
> can feel free to 

Cryptography-Digest Digest #729

2000-09-20 Thread Digestifier

Cryptography-Digest Digest #729, Volume #12  Wed, 20 Sep 00 19:13:00 EDT

Contents:
  Re: BUG in CryptLib 3.0. Is there a fix? ([EMAIL PROTECTED])
  Re: A conjecture - thoughts? (Anton Stiglic)
  Re: SUN SPOT 6.51 BILLION square kilometers in size (Eugene Griessel)
  Even-Mansour extension? (Doug Kuhlman)
  Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an  (Mok-Kong Shen)
  Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an  (Mok-Kong Shen)
  Re: Questions about how to run a contest (Doug Kuhlman)
  Re: Music Industry wants hacking information for cheap (zapzing)
  Re: SUN SPOT 6.51 BILLION square kilometers in size (Doug Berry)
  Does this mean anything? (JustAsking)
  md5 fail -x test under Digital UNIX C Compiler ([EMAIL PROTECTED])
  Re: Software patents are evil. (Bill Unruh)
  Re: ExCSS Source Code (Bill Unruh)
  Re: Even-Mansour extension? (David A. Wagner)
  Re: CDMA tracking (was Re: GSM tracking) (Jerry Coffin)
  Re: Simple hash function (Jerry Coffin)
  Re: Stream cipher (Jerry Coffin)
  Re: SUN SPOT 6.51 BILLION square kilometers in size ("Trevor L. Jackson, III")
  Re: Tying Up Loose Ends - Correction ("Trevor L. Jackson, III")
  Re: Software patents are evil. ("Trevor L. Jackson, III")
  Re: Software patents are evil. ("Trevor L. Jackson, III")
  Re: Software patents are evil. ("Trevor L. Jackson, III")



From: [EMAIL PROTECTED]
Subject: Re: BUG in CryptLib 3.0. Is there a fix?
Date: Wed, 20 Sep 2000 19:59:28 GMT

Question resolved


Sent via Deja.com http://www.deja.com/
Before you buy.

--

From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: A conjecture - thoughts?
Date: Wed, 20 Sep 2000 16:11:01 -0400

Ian Goldberg wrote:

> 
> What do you do when f(x) = x * 2 and g(x) = x * sqrt(3) ?
> 
>- Ian


That's an interesting example.
You won't get an answer of the form b(x_0, x) = cx + x_0,
for any c, because you end up with 
b(x_0, x)^i = (i-1)*c*x,  
but you won't get 2*x and sqrt(3)*x for some pair 
(i,j) of exponents (this is a side effect of the fact
that the additive group of the field R (Reals) is not 
cyclic).

Same thing if you look at the form b(x_0, x) = cx,
since the mult. group of R is not cyclic.

Note: maybe there is some other form for which you 
could get the answer, but from a quick look I don't
see any.

Looks like you could have better luck if you work in a 
field where the add. and mult. group are cyclic (Z is a 
cyclic add. group, for example, or some set having some
similar extra structure).
 
-- Anton.

--

From: [EMAIL PROTECTED] (Eugene Griessel)
Crossposted-To: sci.military.naval,alt.conspiracy,sci.geo.earthquakes
Subject: Re: SUN SPOT 6.51 BILLION square kilometers in size
Date: Wed, 20 Sep 2000 20:28:40 GMT
Reply-To: [EMAIL PROTECTED]

Ichinin <[EMAIL PROTECTED]> wrote:

>Eugene Griessel wrote:
>
>
>Let me guess, you want sci.crypt feedback?

Yep - I have rightly been slapped smartly on the wrist and taken to
task by some creature calling itself Stanislav Shalunov who is
indignant that I allowed my drivel to soil its pristine newsgroup.
I immediately tore open an emergency pack of sackcloth and ashes and
have been chastising myself ever since for this dastardly deed of
unpremeditated crossposting.  Inbetween beating my breast and
scourging myself I keep asking myself the "why?  Oh why? Why must that
particular newsgroup not suffer its share of off-topic crossposts,
lunatic foaming-at-the-mouth conspiracy whackos and plain
dyed-in-the-wool clueless newbies?

Eugene L Griessel  [EMAIL PROTECTED]   

www.dynagen.co.za/eugene
SAAF Crashboat Page - www.dynagen.co.za/eugene/eug3.htm
Snake Page - www.web.netactive.co.za/~sean

--

From: Doug Kuhlman <[EMAIL PROTECTED]>
Subject: Even-Mansour extension?
Date: Wed, 20 Sep 2000 15:00:21 -0500

OK, so I've read and sorta understood Biryukov and Wagner's paper on
sliding attacks, specifically implemented against Even-Mansour schemes. 
I was wondering about possible exentensions of the E-M scheme and
whether they would be secure.  Any advice/comments appreciated.

Throughout, n=# of bits of the scheme,
k = n-bit key
P = a fixed (known) psuedo-random permutation  (n bits -> n bits)
m = n-bit message
^ = XOR

Idea #1: ciphertext = P(m ^ k) ^ (k~) where (k~) is k with the bit order
reversed.
Does this still carry the Even-Mansour "guarantee"?  Can a sliding
attack (or another attack) work on this?

Idea #2: ciphertext = P(P(m ^ k) ^ k) ^k
How much does the sliding attack "degrade" in this case?  Other attack
ideas?

Thanks,
Doug

--

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an 
Date: Wed, 20 Sep 2000 22:59:00 +0200



Kostadin Bajalcaliev wrote:
> 
> I am sorry to say,

Cryptography-Digest Digest #728

2000-09-20 Thread Digestifier

Cryptography-Digest Digest #728, Volume #12  Wed, 20 Sep 00 16:13:01 EDT

Contents:
  Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an alternative 
intorduction] ("Kostadin Bajalcaliev")
  Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an alternative 
intorduction] ("Kostadin Bajalcaliev")
  Re: Tying Up Loose Ends - Correction (SCOTT19U.ZIP_GUY)
  Re: RSA Questions (Bryan Olson)
  Re: A conjecture - thoughts? (Anton Stiglic)
  Re: ExCSS Source Code (Bryan Olson)
  Re: One-way encryption ([EMAIL PROTECTED])
  Re: Questions about how to run a contest ("Simon  Dainty")
  Re: SUN SPOT 6.51 BILLION square kilometers in size (Ichinin)
  How do I cancel a question? ([EMAIL PROTECTED])
  Re: Software patents are evil. ("Dann Corbit")



From: "Kostadin Bajalcaliev" <[EMAIL PROTECTED]>
Subject: Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an 
alternative intorduction]
Date: Wed, 20 Sep 2000 19:52:25 +0200

I am sorry to say, but the only advice i can give you in order to properly
understand what we are talking about is to find 16th century dictionary and
try to find the word computer in it.

Mok-Kong Shen wrote in message <[EMAIL PROTECTED]>...
>
>
>Kostadin Bajalcaliev wrote:
>
>> Mok-Kong Shen wrote:
>
>> >Kostadin Bajalcaliev wrote:
>> >>
>> >[snip]
>> >> I hope you will find a little time to read my thesis, it is not the
>> regular
>> >> amateur-eureka-work.
>> >
>> >I have looked at your paper. The following are my comments:
>> >
>> >You have apparently thought that a function must be something
>> >written as a common mathematical expression like x^3+5. This
>> >is not true. Every mapping from one set to another set
>> >defines a function. In the discrete case, a function can
>> >be given by a table and there is no need to give a nice
>> >mathematical expression to describe it. If a blackbox
>> >delivers an ouput for each input, then it realizes a
>> >function. (The output for the same input may even be different
>> >at different times, but we shall not go that far here.)
>>
>> Not at all, i agree that any maping from one set to another is function,
but
>> it is very anpractical solution. Let the balck box accept 64-bit number
in
>> and produce a 64-bit number as output. Since the box is assumed to exist
in
>> the real world it is imossible to map it there are to many entries. Even
>> more there is some algorithm in side that make the transformation (if we
>> exculed random mapings). In order to analize this box we need to find the
>> algo inside. Maping it will be of no use.
>
>A mapping from n elements all to one single element
>is still a function, only that the function cannot
>be inverted. I used the box to emphasize that it
>is important only to know all pairs of input/output
>to define a function. How the output is computed from
>the input is essential to the implementor but for
>the user of the function it is of no significance.
>The implementation detail doesn't belong to the
>definition of a function.
>
>>
>> >A piece of code in the programming language, normally one
>> >having as header 'function', gives the explicit steps
>> >of computation and realizes a function. That in such code
>> >one uses different constructs of the programming languages
>> >like 'if', 'case' to determine exactly what to do (among
>> >a number of options) in any concrete situation (cf. your
>> >example with the case construct) is what every programmer
>> >has been doing. Thus I am afraid that your newly constructed
>> >term 'quasi-function' is very confusing.
>> >
>
>> This second oppinion is somthing closer to definition of function in
>> general. Function is an algorithm that executing finit number of steps
make
>> some transformation over the input or more theoreticly map the set of
input
>> values into the set of output values. May be the term Quasi Algorithms is
>> not the lakyest choise but i thing it is an existing form. If you expand
any
>> function into elementar steps (let say in ASM code) than it is easy to
>> notice that each step (instruction / operation) care 2 different types of
>> information in it, what should be done, and what are the argments
>> (operators). If the the operation is abstracted than we have a structure
>> that specifed by the order of step the kind of operation taking place in
>> each step and operand, but which operation is realy taking place in those
>> steps in unkown. Any algorithm have a skeleton, vertainly not all the
>> operations from the steps can be abstracted but most of tham can. In the
>> thsis there is a simple exmaple, a polynom function (they are not the
only
>> king of functions). Let say f(x)=ax^2 + bx +c a simple equante of 2nd
>> degree. there are 5 operation inside, if we abstract tham we can write
>> Qf(x)=a o x o 2 o b o x o c where o is any operation. second function
>> g(x)=a+x-2+b-xc have the same skeleton only different operatio

Cryptography-Digest Digest #726

2000-09-20 Thread Digestifier

Cryptography-Digest Digest #726, Volume #12  Wed, 20 Sep 00 14:13:01 EDT

Contents:
  Re: Software patents are evil. (Bill Unruh)
  Re: Software patents are evil. (Bill Unruh)
  Re: Proper way to intro a new algorithm to sci.crypt? (Mok-Kong Shen)
  Re: Software patents are evil. (Terry Ritter)



From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Software patents are evil.
Date: 20 Sep 2000 17:05:20 GMT

In  "Dann Corbit" <[EMAIL PROTECTED]> writes:

>So if someone else implemented encryption using RC5 before the patent ran
>out, there would have been no problem with that?

>What exactly is owned then, if it isn't the algorithm?  A hardware device
>only?  Can I implement the same algorithm without fear of reprisal?

What is owned is the right to make a device or program to accomplish
certain ends via a series of mathematical operations. I have not read
the claims of the RC5 patent, so do not know what is claimed. But let us
assume that what is claimed is the use of a certain sequence of
mathemtical operations on an input to produce an encrypted output. Then
I am perfectly at liberty to use exactly those same sequence of
operations to produce say a random number generator for use in my
physics simulations. It is not the algorithm which is patented but the
use of that algorithm to accomplish certain ends, in this case
cryptography. Just as the paper clip patents did not patent the bending
of wire, but the bending of wire to accomplish certain ends, namely the
production of a paper clip with certain properties.

(I am not a lawyer, so the above is not legal advice. If you have
anything riding on it, please consult a lawyer)

--

From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Software patents are evil.
Date: 20 Sep 2000 17:12:32 GMT

In <[EMAIL PROTECTED]> Runu Knips <[EMAIL PROTECTED]> writes:
]Not to note that using rotation is the oldest concept of
]encryption, even the first of all ciphers, the caesar one, was
]a rotation in 26 alphabetic characters, this patent was also given
]long after, for example, DES has been published (DES rotates the
]key bits), and this is a practical example how people patent maths.

]If you can get a patent on "using rotation in encryption", you
]can also get a patent on any piece of math you wish, don't you ?
]Why don't you patent "using addition in mercantile computations
]to get the sum of something" ? Hey, its patentable ! Maybe
]nobody has been so original to patent it yet ! But I'm not sure
]about that, of course.


You can get a patent on obvious stuff because the people working in the
patent office are sometimes incompetent. That is why a granting of a
patent is not final. The valididty of the patent can and often has been
successfully challenged.


]> Patents an copyrights are both monopoly rights granted by the govenment.
]> They may have a social benefit. They also have a social cost, as the
]> USSR found in their granting of monopoly rights to businesses.  Society
]> should make sure that they get back a lot for the grant of such monopoly
]> rights.

]Software patents will, for example, destroy free software if we
]can't hinder it. I can't see how you want to get such losses
]back.

The argument is that what you get back is increased inventiveness in
return for the granting of limited monopoly. Whether such is needed in
the software industry is something which has been debated far too
little. My own feeling is that no encouragement is needed for
inventiveness in software, that patents do hinder in that area more than
they help. this is something which needs social debate. Instead it is
largely companies and individuals arguing that have a natural right to
monopoly power. There is no such natural right. 

--

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Proper way to intro a new algorithm to sci.crypt?
Date: Wed, 20 Sep 2000 19:55:42 +0200



Albert Yang wrote:
> 
> Can anybody give me a quick run-through of the proper way to introduce a
> new algorithm to Sci.crypt?

I think it is conceivable that responses you have got
are not very satisfactory for your original need. Thus 
I'll try a bit on my part to see if I could eventually
do better:

Give a good English description of your algorithm.
To ease comprehension, you may do it in two phases.
In the first phase, give a concise sketch, indicating
what you think are the specically interesting 
features of you cipher. In the second phase, give 
sufficiently detailed elaborations such that
a third person with good programming experiences
can independently do an implementation. If you
employ some constants, explain exactly how you have 
obtained these, so that others may reproduce them
and hence it is clear that there are no backdoors
behind these constants. (Don't follow the very bad 
examples of DES and AES in this connection!) If 
something is well described in an easily acc

Cryptography-Digest Digest #727

2000-09-20 Thread Digestifier

Cryptography-Digest Digest #727, Volume #12  Wed, 20 Sep 00 14:13:01 EDT

Contents:
  winace encryption algorithm (correction) (An Metet)



From: An Metet   <[EMAIL PROTECTED]>
Subject: winace encryption algorithm (correction)
Date: Wed, 20 Sep 2000 14:03:32 -0400

Again (*sigh*), this is the secret Ace (and WinAce) encryption
algorithm. I hope it will be posted correctly this time! It is a
combination of a Blowfish derivation and a SHA-1 derivation and it
uses Cipher Block Chaining. I called it AceFish therefore...

About one month ago, there was a hint in sci.crypt, that it could be
a combination of BlowFish and SHA-1. This code was created by
disassembling, examining and debugging ace32.exe (version 1.2b) and
comparing the results to the original Blowfish and SHA-1 algorithms.
The differences are commented in the source code. I hope I didn't
forget to comment on one of them.

This code will only work on machines with Intel byte order! It
shouldn't be too difficult to adapt it for Motorola byte order,
anyway.

 begin AceFish.h 
#ifndef __ACEFISH_H__
#define __ACEFISH_H__

typedef unsigned long u32;

class AceFish {
u32 _p[18];
u32 _s[4][256];
u32 _cbc0, _cbc1;   // for cipher block chaining

static void hash(const char* str, u32 hash[5]);

void encrypt(u32& res_l, u32& res_r, u32 in_l, u32 in_r);
void decrypt(u32& res_l, u32& res_r, u32 in_l, u32 in_r);

public:
AceFish(const char* password);

void encrypt(void* buffer, size_t bytes);   // (bytes % 8) == 0!!
void decrypt(void* buffer, size_t bytes);   // (bytes % 8) == 0!!

void resetCBC() {
_cbc0 = _cbc1 = 0;
}
};

#endif
 end AceFish.h ==

 begin AceFish.cpp ==
#include 
#include "AceFish.h"

static u32 InitP[18] = {
0x243f6a88, 0x85a308d3, 0x13198a2e, 0x03707344, 0xa4093822,
0x299f31d0, 0x082efa98, 0xec4e6c89, 0x452821e6, 0x38d01377,
0xbe5466cf, 0x34e90c6c, 0xc0ac29b7, 0xc97c50dd, 0x3f84d5b5,
0xb5470917, 0x9216d5d9, 0x8979fb1b
};

static u32 InitS[4][256] = {
{
0xd1310ba6, 0x98dfb5ac, 0x2ffd72db, 0xd01adfb7, 0xb8e1afed,
0x6a267e96, 0xba7c9045, 0xf12c7f99, 0x24a19947, 0xb3916cf7,
0x0801f2e2, 0x858efc16, 0x636920d8, 0x71574e69, 0xa458fea3,
0xf4933d7e, 0x0d95748f, 0x728eb658, 0x718bcd58, 0x82154aee,
0x7b54a41d, 0xc25a59b5, 0x9c30d539, 0x2af26013, 0xc5d1b023,
0x286085f0, 0xca417918, 0xb8db38ef, 0x8e79dcb0, 0x603a180e,
0x6c9e0e8b, 0xb01e8a3e, 0xd71577c1, 0xbd314b27, 0x78af2fda,
0x55605c60, 0xe65525f3, 0xaa55ab94, 0x57489862, 0x63e81440,
0x55ca396a, 0x2aab10b6, 0xb4cc5c34, 0x1141e8ce, 0xa15486af,

//original blowfish ->  0x2ba9c55d
0x7c72e993, 0xb3ee1411, 0x636fbc2a, 0x2da9c55d, 0x741831f6,

//  0x9b87931e  <- original blowfish
0xce5c3e16, 0x9b87901e, 0xafd6ba33, 0x6c24cf5c, 0x7a325381,

0x28958677, 0x3b8f4898, 0x6b4bb9af, 0xc4bfe81b, 0x66282193,
0x61d809cc, 0xfb21a991, 0x487cac60, 0x5dec8032, 0xef845d5d,
0xe98575b1, 0xdc262302, 0xeb651b88, 0x23893e81, 0xd396acc5,
0x0f6d6ff3, 0x83f44239, 0x2e0b4482, 0xa4842004, 0x69c8f04a,
0x9e1f9b5e, 0x21c66842, 0xf6e96c9a, 0x670c9c61, 0xabd388f0,
0x6a51a0d2, 0xd8542f68, 0x960fa728, 0xab5133a3, 0x6eef0b6c,
0x137a3be4, 0xba3bf050, 0x7efb2a98, 0xa1f1651d, 0x39af0176,
0x66ca593e, 0x82430e88, 0x8cee8619, 0x456f9fb4, 0x7d84a5c3,
0x3b8b5ebe, 0xe06f75d8, 0x85c12073, 0x401a449f, 0x56c16aa6,
0x4ed3aa62, 0x363f7706, 0x1bfedf72, 0x429b023d, 0x37d0d724,
0xd00a1248, 0xdb0fead3, 0x49f1c09b, 0x075372c9, 0x80991b7b,
0x25d479d8, 0xf6e8def7, 0xe3fe501a, 0xb6794c3b, 0x976ce0bd,
0x04c006ba, 0xc1a94fb6, 0x409f60c4, 0x5e5c9ec2, 0x196a2463,
0x68fb6faf, 0x3e6c53b5, 0x1339b2eb, 0x3b52ec6f, 0x6dfc511f,
0x9b30952c, 0xcc814544, 0xaf5ebd09, 0xbee3d004, 0xde334afd,
0x660f2807, 0x192e4bb3, 0xc0cba857, 0x45c8740f, 0xd20b5f39,

//original blowfish ->  0x402c7279
0xb9d3fbdb, 0x5579c0bd, 0x1a60320a, 0xd6a100c6, 0x412c7279,

0x679f25fe, 0xfb1fa3cc, 0x8ea5e9f8, 0xdb3222f8, 0x3c7516df,
0xfd616b15, 0x2f501ec8, 0xad0552ab, 0x323db5fa, 0xfd238760,
0x53317b48, 0x3e00df82, 0x9e5c57bb, 0xca6f8ca0, 0x1a87562e,
0xdf1769db, 0xd542a8f6, 0x287effc3, 0xac6732c6, 0x8c4f5573,
0x695b27b0, 0xbbca58c8, 0xe1ffa35d, 0xb8f011a0, 0x10fa3d98,
0xfd2183b8, 0x4afcb56c, 0x2dd1d35b, 0x9a53e479, 0xb6f84565,
0xd28e49bc, 0x4bfb9790, 0xe1ddf2da, 0xa4cb7e33, 0x62fb1341,
0xcee4c6e8, 0xef20cada, 0x36774c01, 0xd07e9efe, 0x2bf11fb4,
0x95dbda4d, 0xae909198, 0xeaad8e71, 0x6b93d5a0, 0xd08ed1d0,
0xafc725e0, 0x8e3c5b2f, 0x8e7594b7, 0x8ff6e2fb, 0xf2122b64,
0xb812, 0x900df01c, 0x4fad5ea0, 0x688fc31c, 0xd1cff191,
0xb3a8c1ad, 0x2f2f2218, 0xbe0e1777, 0xea752dfe, 0x8b021fa1,
0xe5a0cc0f,

Cryptography-Digest Digest #725

2000-09-20 Thread Digestifier

Cryptography-Digest Digest #725, Volume #12  Wed, 20 Sep 00 13:13:00 EDT

Contents:
  Re: Hamming weight (Mack)
  Re: Maximal security for a resources-limited microcontroller (Runu Knips)
  Re: Hardware RNGs (Mark Carroll)
  Re: Algebra, or are all block ciphers in trouble? (Mack)
  Re: Software patents are evil. (Tim Tyler)
  Re: SUN SPOT 6.51 BILLION square kilometers in size (Eugene Griessel)
  Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption (David Empey)
  Re: My attempt at an alogrithm. (Runu Knips)
  Re: RSA Questions ([EMAIL PROTECTED])



From: [EMAIL PROTECTED] (Mack)
Subject: Re: Hamming weight
Date: 20 Sep 2000 16:18:42 GMT

>Mack, I'm a bit puzzled:
>
>>A good definition for base two.  But Hamming weight is also
>>applicable to other bases.  "The Theory of Error-Correcting Codes"
>>by MacWilliams and Sloane defines the Hamming Weight as
>>the number of non-zero entries in the numeric string and
>>the Hamming Distance as the number of places where they
>>differ or alternately the hamming weight of subtracting one string
>>from the other without carry.
>>
>
>
>Francois Grieu answered that the Hamming weight was only depending on the
>binary representation.
>The Hamming weight of 19 is thus 3 (2^4, 2^1 and 2^0).
>
>If it's applicable to other bases shouldn't 19 have a weight of 2 (1*10^1
>and 9*10^0) ??
>
>Kim
>

That is still calculating the base two weight.  In base ten the weight
is 2. In base 3 the number is (2*3^2+1*3^0) which is also hamming
weight 2.  Since 19 is prime it will have hamming weight of 2 for all
bases up to 18 except base 2. In fact any prime will always
have a hamming weight of at least 2 for bases smaller than itself.


Mack
Remove njunk123 from name to reply by e-mail

--

Date: Wed, 20 Sep 2000 18:18:56 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Maximal security for a resources-limited microcontroller

Sagie wrote:
> I'm in need of a symmetric (secret key) encryption process for one of my
> projects. I would love to use one of the popular schemes, such as blowfish
> and DES, but the cipher has to be implemented in a teeny-weeny
> microcontroller with very limited resources. The cipher's program footprint,
> memory footprint and execution time must therefore be as small as possible,
> while maintaining the highest security possible (I was thinking about a
> process that will take no more than 150 RISC cycles per byte, and a program
> footprint of no more than 384 words). Plus I'm also quite a novice in these
> issues.

We have discussed this issue here before a while. Skipjack was the
cipher which was finally suggested. It is very slow (compared to
the AES ciphers, on a normal PC or Workstation) and has only a
80 bit key (Schneider suggested once in his A.C. one shouldn't use
key sizes below 112 bit), but it might be implemented in really
low resource environments.

> What I had in mind was to implement a non-linear 4-bit or 8-bit lookup
> table (8-bit lookup table is as far as I can go -- and it must be used for
> both encryption and decryption, which is not a big deal because I can decide
> that incoming messages will be encrypted with the decryption key), along
> with maybe some bit splicing.
> The last line of defence I was thinking of is somehow making the
> encryption of every byte dependant of the encryption result of the last
> byte. But this raises question as for implementing the decryption process...
> 
> So this is basically what I'm asking:
> 1. Is the "progressive ciphering" (the "last line of defence" described
> in the last paragraph) at all possible to perform? If so, how is the
> encryption/decryption implemented? (I would appreciate a tutorial source
> code/link)
> 2. Can anyone direct me to a source code that demonstrates (and
> explains) how do table-based ciphers are implemented?
> 3. Is there anything else that can be performed to raise the security
> level (within the limits described above)?
> 4. After doing all of these tricks, how strong is the cipher going to
> be?
> 
> I hope I'm not asking too much here... I would appreciate any help,
> really.

Well maybe you would like to get a skipjack source:


/*
** Skipjack algorithm, from sci.crypt.
** Edited for better readability - Runu Knips
*/

/*

Subject: Re: Skipjack implementation in C (this one works)
Date: Thu, 18 May 2000 23:09:24 GMT
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Organization: @Home Network
Newsgroups: sci.crypt

SKIPJACK implementation in Standard C

last edit:  25-Jan-1999 [EMAIL PROTECTED]

This is a C89 implementation of the SKIPJACK block cipher
algorithm
described in version 2.0 of NSA's SKIPJACK specification dated
29 May 1998 .
*/
#ifdef DEBUG
#include
#endif

/*
** Interface specification:
*/
#defin

Cryptography-Digest Digest #724

2000-09-20 Thread Digestifier

Cryptography-Digest Digest #724, Volume #12  Wed, 20 Sep 00 12:13:00 EDT

Contents:
  Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an  (Mok-Kong Shen)
  Re: Hamming weight (Mok-Kong Shen)
  Re: On secret Huffman compression (Mok-Kong Shen)
  Re: Hardware RNGs ("ScottD")
  Re: Parity Checking in DES (Mok-Kong Shen)
  Re: Parity Checking in DES (Brian Boorman)
  SUN SPOT 6.51 BILLION square kilometers in size ([EMAIL PROTECTED])
  Re: CDMA tracking (was Re: GSM tracking) (Craig Paul)
  Re: Tying Up Loose Ends - Correction (Tim Tyler)
  Re: Tying Up Loose Ends - Correction (Tim Tyler)
  Re: Hardware RNGs (Mark Carroll)
  Re: RC4: Tradeoff key/initialization vector size? (John Myre)
  Re: RSA Questions ([EMAIL PROTECTED])
  Re: Known Plain Text Attack (Tim Tyler)
  Re: One-way encryption (Tim Tyler)



From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an 
Date: Wed, 20 Sep 2000 13:52:56 +0200



John Savard wrote:
> 
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> 
> >Polymorphism has been known in computer science since
> >decades, though much popularized only after C++. Already
> >in Algol68 one can use a datatype 'union' such that at
> >runtime one can obtain first the type and then the value
> >of an object and with these determine what is to be
> >computed next. Polymorphic Types have been much studied
> >by researchers of the functional languages.
> 
> I think that almost the only connection between that and the form of
> encryption under discussion is the use of the same word.

Actually not. He uses the data (at runtime dynamically)
to determine via a case-construct what the function
(at a particular step) should do. In programming, a
polymorphic function is one such that the code queries
the type and/or the value of certain input arguments
and uses that information to determine what is to be
done. In this way, one has only one function name
(instead of a bunch of these each for a different one)
to stand for a whole class of (more or less similar)
functions. That is polymorphism as the term is used in 
CS. If a cipher designer indends to exploit variability
at some small granuality level, this programming
paradigm would naturally come to his mind in 
implementation. (I myself once thought of letting PRNG 
to determine in one of my humble cipher designs whether 
xor or modular addition is to be done in certain steps, 
but I finally decided to leave that out, considering 
that my design already has enough variability and 
achieving more 'complexity' for the opponent via adding
more code is not worthwhile in that case. My design 
is PRNG driven, i.e. everything is controlled by PRNG 
and there is feedback from the result of processing to 
the PRNG, thus there is ample variability in my viw.) 
So what the original poster does is nothing new at all 
from the standpoint of programming. His explicitly 
pointing out (stressing) the advantage of using 
polymorphism (because of increase of variability) may 
on the other hand be considered 'new' in the sense
that he calls one's attention to polymorphism as a 
general technique useful in crypto design and 
implementation. As you pointed out, you and several 
others have earlier employed certain polymorphic
constructs.

M. K. Shen

--

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Hamming weight
Date: Wed, 20 Sep 2000 13:53:04 +0200



kihdip wrote:
> 
> Francois Grieu answered that the Hamming weight was only depending on the
> binary representation.
> The Hamming weight of 19 is thus 3 (2^4, 2^1 and 2^0).
> 
> If it's applicable to other bases shouldn't 19 have a weight of 2 (1*10^1
> and 9*10^0) ??

The 'basic' definition is the Hamming distance, which
it the number of unequal pairs of the corresponding
elements of two vectors. From that one 'derives' the 
definition of Hamming weight of a vecter, which is 
the Hamming distance between that vector and the zero 
vector. If by using a different base you are thinking 
of obtaining a different vector (the elements are no
longer of 1 bit), then you could have a different 
Hamming weight than in the binary case. I am unaware 
of practical use of Hamming weight in this way, however. 
On the other hand, Hamming distances between vectors 
whole elements are arbitrary (i.e. not necessarily 1 
bit) are commonplace.

M. K. Shen

--

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On secret Huffman compression
Date: Wed, 20 Sep 2000 14:06:53 +0200



Tim Tyler wrote:
> 

> IIRC, I've mentioned before the possibility of an attacker using
> known-plaintext at the start of the message to extract much of the
> Huffman tree.  *If* you can get the whole tree, it seems likely that it
> will be possible to recover the PRNG stream - which can be used to send
> forged messages (in the absence of a signature sc

Cryptography-Digest Digest #723

2000-09-20 Thread Digestifier

Cryptography-Digest Digest #723, Volume #12  Wed, 20 Sep 00 06:13:00 EDT

Contents:
  Re: Software patents are evil. (Jerry Coffin)
  Re: CDMA tracking (was Re: GSM tracking) (Jerry Coffin)
  Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption (John Savard)
  Re: Algebra, or are all block ciphers in trouble? (Mack)
  Re: Algebra, or are all block ciphers in trouble? ("Douglas A. Gwyn")
  Re: Intel's 1.13 MHZ chip ("Douglas A. Gwyn")
  Re: Hamming weight ("kihdip")
  Re: Software patents ("kihdip")
  Re: Double Encryption Illegal? (Arturo)
  Re: Optimization for speed question. (Jonathan Headland)
  Re: Optimization for speed question. (John Winters)
  Re: On secret Huffman compression (Tim Tyler)
  Re: Optimization for speed question. (Christian Bau)



From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Software patents are evil.
Date: Wed, 20 Sep 2000 00:38:13 -0600

In article <[EMAIL PROTECTED]>, 
[EMAIL PROTECTED] says...

[ ... ] 

> Well consider the patent on rotation. A japanese company recently
> claimed that most of the AES finalist violate their patent. So
> what is their patent ? Using rotation in encryption !!!

You're making the same mistake as most people who condemn software 
patents: you start by picking a patent that perhaps shouldn't have 
been granted in the first place because it may have been more or less 
marginal WRT things like originality.

You don't leave it at the fact that being run by humans, the PTO 
makes mistakes now and then though -- you got a step further, and 
grossly mis-characterize the patent entirely.

In this case, the patent is NOT simply on using rotations in 
cryptography at all.  It's on using a specific number of input-
dependent rotations combined in a fairly specific fashion.
 
> Not to note that using rotation is the oldest concept of
> encryption, even the first of all ciphers, the caesar one, was
> a rotation in 26 alphabetic characters, this patent was also given
> long after, for example, DES has been published (DES rotates the
> key bits), and this is a practical example how people patent maths.

No, it is not.  It is a practical example of how people stretch the 
truth to justify their positions.

> If you can get a patent on "using rotation in encryption", you
> can also get a patent on any piece of math you wish, don't you ?

As stated, this is a true statement (ignoring minor grammatical 
problems).  The problem with it is that you CAN'T (as far as anybody 
knows) simply get a patent on using rotation in encryption.  Given a 
false premise, the statement as a whole is vacuously true, but 
essentially meaningless.  IOW, no, you can't get a patent on any 
piece of math you wish.

> Why don't you patent "using addition in mercantile computations
> to get the sum of something" ? Hey, its patentable !

Says who?  So far, you've said so, but the PTO hasn't agreed.  Even 
if they did, it wouldn't necessarily mean a lot: you'd have to sue 
somebody for infringement and get your patent upheld in court before 
it meant much of anything.  Even assuming you threw enough 
circumlocution into your application to convince the examiner you had 
something, so you were granted a piece of paper, it's unlikely you'd 
get a court to enforce a bunch of nonsense.

> Software patents will, for example, destroy free software if we
> can't hinder it. I can't see how you want to get such losses
> back.

People have been saying this for decades now.  In fact the examples 
they first used (e.g. on RSA encryption) are now expired.  Look 
around, and try to tell me that there's less free software today than 
there was 20 or 30 years ago.

In reality, software patents are going to contribute heavily to free 
software: when somebody writes a patent, they must reveal all the 
secrets and details of how to implement the invention, and when the 
patent expires, the invention is automatically placed in the public 
domain.  There's no room for question about whether you can use it or 
not, etc. -- it's known for certain to be public domain.  
Furthermore, the inventor has provided assistance so any person of 
ordinary skill in the art can implement the invention as it was 
intended to work.  Further still more, there's a requirement that the 
inventor reveal the best mode of embodiment.  This basically means 
the inventor has to tell you the intended area for the invention's 
use.  For example, if he invents some method of building legs to put 
under buildings to prevent damage from both flooding and earthquakes, 
his patent can be completely invalidated if he tries to mislead you 
into believing that this is really about how to build table legs 
instead.

To summarize: most of your points are based on a premise that's known 
to be false.  If you want the details of the steps required in the 
patent on rotation in encryption, I posted an explanation a while 
back here in sci.crypt that you

Cryptography-Digest Digest #722

2000-09-20 Thread Digestifier

Cryptography-Digest Digest #722, Volume #12  Wed, 20 Sep 00 03:13:00 EDT

Contents:
  Re: RSA Questions (Bryan Olson)
  Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption (John Savard)
  Re: Kryptcon ("David Thompson")
  Re: Hamming weight (Mack)
  Hardware RNGs (Mark Carroll)
  Re: Intel's 1.13 MHZ chip ("Douglas A. Gwyn")
  Re: Dangers of using same public key for encryption and signatures? (Bryan Olson)
  Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an  ("Douglas A. 
Gwyn")
  Re: CDMA tracking (was Re: GSM tracking) (Mack)
  Re: Q: Crypto-PC ("Douglas A. Gwyn")
  Re: CDMA tracking (was Re: GSM tracking) (Roger Schlafly)
  Re: Hardware RNGs (Paul Rubin)
  Re: Algebra, or are all block ciphers in trouble? ("Douglas A. Gwyn")
  Re: Hardware RNGs ("Douglas A. Gwyn")
  Re: Algebra, or are all block ciphers in trouble? (Mack)
  revised code for brute forcing RC4 ([EMAIL PROTECTED])
  Re: Figures of Merit for Crypto=Systems (Mack)
  Re: Double Encryption Illegal? (Paul Schlyter)
  Re: transformation completeness and avalanche effect (Mack)
  Re: Intel's 1.13 MHZ chip (Jerry Coffin)



From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: RSA Questions
Date: Wed, 20 Sep 2000 02:56:01 GMT

Ed Pugh wrote:
> Bryan Olson writes:
> >
> > The modulus must be the product of distinct primes for
> > encryption to be invertible.

> But that is not quite true.
[...]
>  Don't forget that, if N
> is not "square free", then the message encrypted with e and N must
> be coprime to N.

That's what makes encryption non-invertible for N
that isn't square free.  Well, actually there exist
messages that are not relatively prime to
non-square-free N that will still encrypt and decrypt
correctly.  The point is that if N is not square free
the encryption function [0..N-1] -> [0..N-1] has no
inverse.


--Bryan
--
email: bolson at certicom dot com


Sent via Deja.com http://www.deja.com/
Before you buy.

--

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption
Date: Wed, 20 Sep 2000 02:59:38 GMT

On Tue, 19 Sep 2000 18:16:36 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>On Tue, 19 Sep 2000 14:57:01 GMT, in
><[EMAIL PROTECTED]>, in sci.crypt
>[EMAIL PROTECTED] (John Savard) wrote:

>>[...]
>>The specific type of polymorphism in Konstantin Bajalcaliev's designs,
>>though, as you can see from looking at Quadibloc II and the others of
>>my designs which use it, was basically added almost as an
>>afterthought, which is why it is present only in such a rudimentary
>>form.

>I have looked, but end up more confused than when I started:  Exactly
>what is it about this "specific type of polymorphism" which
>distinguishes from prior work?  What is the process at issue:
>combining, mixing, what?  Are we talking streams or blocks or what?

Very specifically, what I did and what Mr. Bajalcaliev anticipated me
in doing, is this:

in a block cipher particularly, but the concept also applies to stream
ciphers,

based on information dependent on the input plaintext or ciphertext
block,

select a different _operation_ (addition, XOR, multiplication) to
perform at some stage in the block cipher.

IDEA used different operations, and so did SAFER, but in a fixed
structure.

Some of your designs go one better: not only do you choose an
operation depending on the key, but you make a _general_ choice, by
choosing between Latin squares, so you have improved on simply
switching between addition and XOR based on the key in that way.

I can't, offhand, think of a specific example of that which predates
Mr. Bajalcaliev, although I agree with your confusion in the sense
that, since it _is_ a simple and obvious principle, it probably was
used by many people long ago.

>>My suspicion is that polymorphism has been around a long time, but
>>mostly in amateur designs. 

>Exactly how is a cipher distinguished as being an "amateur design"?  

>I claim that any such concept is fundamentally unscientific:  A design
>is what it is, and not who did it.  It can only matter who did it if
>we have no idea how to evaluate the result.  And if we don't, then,
>realistically, those doing it probably don't either.

In this case, I used the phrase 'amateur design' to mean exactly what
it says: a design that was not created in the course of either
employment or academic research. More specifically: I was not saying
that that principle was mostly used in ciphers that were insecure, but
that it was mostly used in ciphers that I was less likely to have
heard of.

Of course, this reminds me, in thinking of the concept of 'amateur' as
being unscientific: in an athletic contest for the championship of a
small town, it is less likely that the deciding margin will be less
than 1/100 of a second.

Despite the fact, therefore, that the athletes are all there
voluntarily, and, indeed, enthusiasti