Cryptography-Digest Digest #613, Volume #13 Fri, 2 Feb 01 12:13:01 EST
Contents:
Re: On combining permutations and substitutions in encryption (Paul Crowley)
Re: Blowfish (Paul Crowley)
Re: fast DES implementation for 64-bit (alpha) architecture (Tom St Denis)
Re: CipherText patent still pending (Tom St Denis)
Re: How good is Diamond2 and Saphire ciphers? (Paul Crowley)
Re: CipherText patent still pending (Paul Crowley)
Re: Very short redundant serial number ([EMAIL PROTECTED])
Q: Base64 mapping ("Manuel Pancorbo")
Re: Durstenfeld Transpositions & ARC4 ("r.e.s.")
Re: Base64 mapping ("Stefan Habenschuss")
A story of distrust .... my ex-mother, Eeva Nuora, Varkaus, Finland tried to make me
lose all ... and so on ... collaborated with the embassy of Finland (Markku J.
Saarelainen)
Re: Durstenfeld Transpositions & ARC4 ("r.e.s.")
Re: CipherText patent still pending ("Prichard, Chuck")
Tree algorithm (Ned Scholes)
----------------------------------------------------------------------------
Subject: Re: On combining permutations and substitutions in encryption
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Fri, 02 Feb 2001 14:12:49 GMT
"Matt Timmermans" <[EMAIL PROTECTED]> writes:
> 3-SAT is the (probably) most commonly known NP-complete problem.
FWIW I'd argue that Travelling Salesman Problem is by far the best
known; it's the one that appears in all pop science presentations of
the P?=NP question. Knapsack probably comes next. 3-SAT is known to
all students of computational complexity because it's a very useful
step in proving other problems NP-Complete.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
Subject: Re: Blowfish
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Fri, 02 Feb 2001 14:12:49 GMT
Splaat23 <[EMAIL PROTECTED]> writes:
> If your main concern is speed, a 128-bit block cipher would most likely
> perform faster than a 64-bit block cipher. So you could just use
> Blowfish's older brother Twofish, or another AES cipher.
Younger brother. Also, strictly speaking, Rijndael is the only AES
cipher; the others were candidates but were not chosen. Rijndael's
pretty fast too; pretty much everyone should be using it unless they
have a particular reason not to.
If that's too slow, can you use a stream cipher like RC4, or failing
that PANAMA or ISAAC?
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: fast DES implementation for 64-bit (alpha) architecture
Date: Fri, 02 Feb 2001 14:08:28 GMT
In article <95cude$n5o$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hello all,
>
> Does anyone have any C code that is optimized for the Dec Alpha 64-bit
> processors?
>
> I just read the '97 paper by Eli Biham on "A Fast New DES
> Implementation in Software". I wish there was an appendix with the C
> libraries involved in the paper! Does anyone have a C library that
> uses this implementation or a newer implementation that is even
> faster? I would appreciate any links that describe any updates to
this
> idea or any improvements. I would like to see some code too to better
> understand the ideas used.
>
> One reason this sounds so interesting is that I am trying to
understand
> the Alpha architecture and thought this would be a good starting
point.
> Are there fast implementations in Alpha assembly?
If you read the paper you would note that the ultra fast DES on a 64-bit
processor (or 32-bit for that matter) is done by processing multiple
blocks in parallel. You don't need ASM todo that since only boolean
logic is used anyways.
Also processing blocks in parallel goes against chaining modes most
people like using. You can however encrypt 64 (or 32) 64-bit binary
counters in parallel and use those to encrypt your data (i.e xor the
encrypted counter against your data). That requires significant foolery
since you have to make sure you add 64 (or 32) to each counter.
Another bottleneck is going either from 64 (or 32) 64-bit words to a
parallel sliced format (as described in his paper) or back to a serial
form so you can update the counters. If your core is fast enough the
bottleneck should be the only delay and perhaps would be less then
processing 64 (or 32) blocks of DES in series.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: CipherText patent still pending
Date: Fri, 02 Feb 2001 14:16:11 GMT
In article <[EMAIL PROTECTED]>,
Richard Heathfield <[EMAIL PROTECTED]> wrote:
> Bryan Olson wrote:
> >
> <snip>
> >
> > Good as those questions are, when I read yet another report
> > of the development of a new symmetic cipher, the first
> > question I ponder is not one those, or others listed in the
> > FAQ.
> >
> > Is is: Why?
> >
> > Does it solve some problem that other ciphers don't? Can
> > they prove something interesting about this cipher that is
> > not true of others? Is there some reason anyone should care?
> >
> > Are people so mis-informed as to think that a symmetric cipher
> > for which no one produces an effective attack is an interesting
> > or novel result? Or that there might be commercial potential
> > for one? Or that a good learning exercise for a student is to
> > design a cipher?
>
> None of the above.
>
> We do it because it's fun.
>
> Of course, that doesn't mean that it's fun for everyone else on
> sci.crypt to read about it. Some of us learn that, eventually. We know
> we're not going to write a competitor to Rijndael (all right, AES) or
> Twofish, but that doesn't matter. The idea of making an omelette out
of
> our bits, and then turning that omelette back into an egg /only if/
the
> right magic words are uttered, is intrinsically fascinating. Once
we've
> done that, it's only natural (if a little child-like) to want to show
> other people - "Look what I did! Isn't it /cooool/?" And who do we
want
> to show our achievement to? Well, obviously it should be to people
> who'll understand it. Equally obviously, that means sci.crypt. (Yes,
the
> FAQs, but sometimes we're a bit too excited to remember to read them.)
>
> In the midst of our natural joy of discovery, we tend to forget that
> sci.crypt understands what we have achieved only too well. I first
> posted my "CDX" algorithm here over a year ago (if I recall
correctly).
> It was torn into tiny little pieces (quite gently, to be fair) by a
> couple of people. Since then, I've toyed with it occasionally, fixed
> some stuff, added some stuff... it's a lot quicker than it was, and a
> lot more secure than before. But I no longer ask people here to
> cryptanalyse it. That's too dispiriting. If truth be told, you see, I
> don't really want anyone to break it. I just want to pretend it's
> unbreakable. I don't pretend that to anyone else, of course. The only
> customer I have in mind for my snake oil is - me.
>
> My symmetric cipher was a lot of fun to write. It was less fun to fix
> after sci.crypt thumped it. It'll be still less fun to fix next time
> round, which is why there won't be a next time round. If I went that
> route, by the time I'd fixed every problem sci.crypt found with the
> algorithm, it would end up looking just like everyone else's
algorithm.
> And where's the fun in that?
I agree, but don't get dishearted. You have to be clever.
My first ciphers were stupid too (very stupid to be correct), then I
moved onto my TC1 which was throughly destroyed. By time I hit TC5 I
had proofs for it's security and it's still as of yet unbroken (despite
being rather slow).
I also invented the worlds fastest block cipher (TC6) which was slightly
insecure but ran at about 12 cycles per byte if I am not mistaken. I
used LUTs to perform 32x32 GF multiplications (I made the tables fit in
the cache which is why it was so fast).
The trick is to take what you have seen already, get rid of stuff you
don't like, patch it up and try analyzing it. I went through about 3
variations before settling on TC5.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
Subject: Re: How good is Diamond2 and Saphire ciphers?
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Fri, 02 Feb 2001 14:37:51 GMT
Rex Stewart <[EMAIL PROTECTED]> writes:
> Again, I am not a true cryptographer, but I have looked at both
> stretching and strengthening (including the paper you mention),
> and consider it a judgement call which to go with (and, IIRC,
> the paper also considered it a judgement call - even though
> the author agreed with you).
I was just clarifying the different terms. Basically, strengthening
costs no time on encryption and nondeterministic time on decryption,
while stretching costs the same deterministic time on both (modulo
differences in speed between the two platforms). I'd guess the latter
would usually but not always be preferable.
> > Not so; if the plaintext has the same prefix, the ciphertext will
> > to. The correct way to provide this property is to use an IV, like
> > CipherSaber.
> [...if] you mean the ciphertext up to the first changed byte will be
> the same, I concur.
Yes, a "prefix" of a string is basically a substring starting at the
beginning. So if P and P' share a common prefix of length l, then C
and C' will also share a common prefix that is perhaps a little
shorter than l but not much. For example, if you're using Rijndael in
CBC mode with fixed IV then the common ciphertext prefix might be up
to 15 bytes shorter. I think it's bounded on the internal state of
the cipher.
> I realize in some situations this would be bad (even disasterous)
> the problem is manageable if know ahead of time.
Cryptographic primitives should in general try to avoid putting such
burdens on protocol or application designers. Usually the small
expansion of the ciphertext due to the use of an IV is an
insignificant cost well rewarded by the security properties it
provides.
> Encrypting all zeros with Sapphire2 will not provide any
> useful information about the internal state. (As far as
> anyone can tell.
This means Sapphire can be used in a normal, KG-style stream cipher
mode.
> On this I agee completely, but that was not the question, and
> considering the origin of the message, I was considering the
> possibility there might be seperate reason for needing this
> information (availablity, compatibility, or already in use
> for some time).
Good point. Cheers!
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
Subject: Re: CipherText patent still pending
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Fri, 02 Feb 2001 14:37:51 GMT
Richard Heathfield <[EMAIL PROTECTED]> writes:
> Bryan Olson wrote:
> > Are people so mis-informed as to think that a symmetric cipher
> > for which no one produces an effective attack is an interesting
> > or novel result? Or that there might be commercial potential
> > for one? Or that a good learning exercise for a student is to
> > design a cipher?
I think the CipherText people are under *all* the misapprehensions you
list here. And more: such people usually complain that, say, an
adaptive chosen-plaintext attack requiring 2^64 time and 2^64 space
isn't an "effective attack" and therefore shouldn't discount the
cipher from serious use. It is very boring to argue with such people
> We do it because it's fun.
[...]
> And who do we want to show our achievement to? Well, obviously it
> should be to people who'll understand it. Equally obviously, that
> means sci.crypt. (Yes, the FAQs, but sometimes we're a bit too
> excited to remember to read them.)
I hope sci.crypt is always an OK place for amateurs to post their new
cipher designs, lack of originality be damned. The FAQs don't and
shouldn't say "don't post", they just say "describe using mathematics,
be polite and helpful to your friends the cryptanalysts, don't expect
to make money, don't stamp your feet and demand to be taken seriously".
Basically, play by the rules of modern cryptanalysis.
> My symmetric cipher was a lot of fun to write. It was less fun to
> fix after sci.crypt thumped it. It'll be still less fun to fix next
> time round, which is why there won't be a next time round. If I went
> that route, by the time I'd fixed every problem sci.crypt found with
> the algorithm, it would end up looking just like everyone else's
> algorithm. And where's the fun in that?
Hmm, I took strange pleasure in watching my symmetric algorithm get
destroyed by differential cryptanalysis (hi Scott!). It was strange
to go from thinking "there's no *way* anyone will push a difference
through that structure!" to "Why didn't I test for that flaw myself?
D'oh!". I think often about the problem of coming up with a good fix,
and it's a fun intellectual challenge. I'm sure my next iteration
will get broken too (though I hope it takes more than two weeks this
time!) but that's OK.
There are lots of unsolved problems in the world of symmetric ciphers.
For example, I'd like a fast stream cipher that fits in
smartcard-sized memory (64 bytes or so). And of course, I'd like a
very fast randomized block cipher with a large block size (4096 bits)
for disk sector encryption, which was the goal of my now-broken cipher
Mercy. I think there's no reason amateurs shouldn't have a go at any
of these challenges, or for that matter at designing a 64-bit block
cipher if that's what you feel like - see the sci.crypt summer cipher
contest. Despite the dire warnings that you have to glitter with
fascination before cryptanalysts will even look at you, sometimes
giants of cryptanalysis like David Wagner take the time to point out
flaws with amateur schemes proposed here. Just be as helpful as you
can and realistic in your expectations, and you could have lots of
fun.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Very short redundant serial number
Date: Fri, 02 Feb 2001 15:06:34 GMT
In article <[EMAIL PROTECTED]>,
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
>
> I'm not sure if this retains the properties of the CRC, but you could
> take the 16 bit CRC, and truncate to 8 bits.
>
> As to turning it into 2 base 10 digits... Why not instead turn it
into
> 2 base 16 (hexadecimal digits)?
Its an embedded app. The keypad does not have ABCDEF.
Ken
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Manuel Pancorbo" <[EMAIL PROTECTED]>
Subject: Q: Base64 mapping
Date: Fri, 2 Feb 2001 16:24:00 +0100
Where can I find this information?
I imagine that Base64 is based in transforming three 8-bit words onto four
6-bit numbers, and mapping these numbers in printable manner.
There are two 26-set of letters plus one 10-set of numbers, this yields 62
possible printable characters, plus characters "+" and "/" up to 64
characters needed. But, what is the exact mapping? 0 -> "+", 1 -> "/", 2 ->
"0", and so on?
Thanks in advance,
--
Manuel Pancorbo
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Durstenfeld Transpositions & ARC4
Date: Fri, 2 Feb 2001 08:10:14 -0800
"Benjamin Goldberg" <[EMAIL PROTECTED]> wrote ...
| Terry Ritter wrote:
| >
| > On Thu, 25 Jan 2001 19:57:58 -0800, in
| > <94qsjr$qfk$[EMAIL PROTECTED]>, in sci.crypt "r.e.s."
| > <[EMAIL PROTECTED]> wrote:
| >
| [snip]
| > >Also, is ARC4's byte-stream generator adequate as a CSPRNG?
| >
| > The ARC4 state is awfully small for Dynamic Transposition,
especially
| > if we shuffle twice. We want more active state in the RNG than is
| > used in a single encryption, and probably do want at least 128
bits in
| > the block. Since rejection in Shuffle (to achieve variable-range)
| > throws away values (and may throw away a lot), probably it is not
| > large enough.
|
| The purpose of having a particular size state PRNG is to allow every
| possible permutation to be a possible result of our PRPG (psuedo
random
| permutation generator). No significant change is made to the size
of
| the range of possible permutations by double shuffling, so there's
no
| reason to require a larger PRNG state if double shuffling is used.
A rejection method (like the ones posted by Benjamin Goldberg
and David Wagner, adapted to ARC4's byte-stream), might require
two consecutive non-rejected bytes from ARC4 for each PRN it
generates. If q(k) is the rejection probability for the PRN
produced from two such bytes, being required in the range 1..k,
then it seems that Durstenfeld's Shuffle can be expected to
require B(N) = 2 * ( 1/q(N) + 1/q(N-1) + ... + 1/q(2) ) of
bytes from ARC4 when used to shuffle a block of N bytes. So,
if the plaintext consists of L bytes, then approximately
(L/N)*B(N) bytes are required from ARC4.
Can approximate values for q(k) be found, allowing an estimate
of B(N), to get a more quantitative handle on the question?
--r.e.s.
------------------------------
From: "Stefan Habenschuss" <[EMAIL PROTECTED]>
Subject: Re: Base64 mapping
Date: Fri, 02 Feb 2001 16:16:38 GMT
> Where can I find this information?
>
> I imagine that Base64 is based in transforming three 8-bit words onto four
> 6-bit numbers, and mapping these numbers in printable manner.
>
> There are two 26-set of letters plus one 10-set of numbers, this yields 62
> possible printable characters, plus characters "+" and "/" up to 64
> characters needed. But, what is the exact mapping? 0 -> "+", 1 -> "/",
2 ->
> "0", and so on?
>
> Thanks in advance,
>
>
> --
> Manuel Pancorbo
>
(RFC 1521)
Each 6-bit group is used as an index into an array of 64 printable
characters. The character referenced by the index is placed in the output
string. These characters, identified in Table 1, below, are selected so as
to be universally representable, and the set excludes characters with
particular significance to SMTP (e.g., ".", CR, LF) and to the encapsulation
boundaries defined in this document (e.g., "-").
Table 1: The Base64 Alphabet
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Crossposted-To: alt.2600,alt.security,comp.security
Subject: A story of distrust .... my ex-mother, Eeva Nuora, Varkaus, Finland tried to
make me lose all ... and so on ... collaborated with the embassy of Finland
Date: Fri, 02 Feb 2001 16:14:05 GMT
Basically, this the story of distrust.
In 1990, my ex-mother was divorcing my father in Finland and had stolen
around 4000 US dollars from my accounts for her divorce proceedings and
living. After I had learned this in 1991 I did not want to have
anything to do with her ever.
In 1998, mu ex-brother Jukka S. Saarelainen tried to make me to talk to
her after I arrived from a Caribbean cruise (November, 1998). I knew
that my ex-borther was in some intelligence network that knew exactly
when I arrived at my home and private property, because his call and
trasnfer effort was timed in such a manner. I was a very very private
person and knew exactly what was going on in my surroundings and life.
There were only so many variables.
And in December, 1999 and January, 2000 after my U.S. born spouse had
left my ex-mother, Eeva Nuora, together with my ex-sister, Senja
Saarelainen-Schwedyc tried to make me lose all and they all
collaborated with the embassy of Finland, a consul Tina Nelin, and with
my separated spouse to hurt me. I was in the financial trouble at the
time. It is ironic that my ex-mother had stolen 4000 USD for her
divorce in early 1990s and tried to make me lose all during my divorce
process.
And in March, 2000, when I called my ex-mother the last and only time
in nine years, I told her not to tell about my call to anybody.
However, I knew she can not be trusted and when I called back to her
five minutes after my first call and interrogated her, she had already
told about this phone call to my ex-brother, Jukka S. Saarelainen and
to my ex-sister, Senja Saarelainen-Schwedyc. So this was the story of
the distrust.
In my opinion, my ex-mother is a stupid person and individual.
Markku from Miami
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Durstenfeld Transpositions & ARC4
Date: Fri, 2 Feb 2001 08:25:43 -0800
correction:
"r.e.s." <[EMAIL PROTECTED]> wrote ...
[...]
| If q(k) is the rejection probability for the PRN
^^^^^^^^^
acceptance
| produced from two such bytes, being required in the range 1..k,
| then it seems that Durstenfeld's Shuffle can be expected to
| require B(N) = 2 * ( 1/q(N) + 1/q(N-1) + ... + 1/q(2) ) of
| bytes from ARC4 when used to shuffle a block of N bytes. So,
| if the plaintext consists of L bytes, then approximately
| (L/N)*B(N) bytes are required from ARC4.
|
| Can approximate values for q(k) be found, allowing an estimate
| of B(N), to get a more quantitative handle on the question?
|
| --r.e.s.
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: Re: CipherText patent still pending
Date: Fri, 02 Feb 2001 16:27:21 GMT
I have not found any conflicting patents regarding how a checksum can be
used to articulate the rotation of a modified key in a second pass
cipher.
Regarding the second shift, it may be possible.
My patent application describes the checksum as "involving every key
element' so as to effect a somewhat unique key 'attribute' as the result.
In pure science it would be favorable to guarantee more uniqueness in the
key attribute, however it is not a critical issue and fairly redundant
where no matter what the rotation is, there will be only N possibilities.
The important thing is, its easily implemented and has proven reliable.
I have a couple of issues regarding ciphertext message domain that need
to be addressed before a serious commercial product can be delivered.
Also, the issue of symmetry is often 'not an issue' in some niche
applications. For example, when the algorithm is applied to encrypt
Page-Tags in CGI query strings, each user thread is assigned a new key.
This prevents known ciphertext attacks. The symmetry issue can possible
be addressed by expanding the key domain and using a different HTTP
transfer-encoding option in internet applications. My demonstrations and
testing has used a limited key domain of 32 characters (byte values) so
as to restrict output domain. The algorithm worked PROPERLY using a
larger domain and allowing UNICODE (16 bit) message domain values, but I
experienced dropouts in the ciphertext from HTTP transmission handling. I
abandoned further testing and gave up on finding a suitable transmission
mime. Give future development, its predictable that a new and suitable
mime could become very standard making the asymmetric mode very useful
within that protocol.
The symmetric/asymmetric cipher characteristic is determined by the
quantitative value of the algorithm's resulting key attribute. It is a
dynamic feature, controllable by restricting the key domain.
Generally saying that an algorithm has no value if it is either symmetric
or asymmetric goes against logic in view of the fact that once
implemented, anything can be of use and value.
This algorithm with its features is implemented in today's popular
internet languages including JavaScript, Java, Perl and Visual Basic.
Nobody has ever spent any time trying to prove it can be broken and it
never has been broken.
Here is the algorithm again without the whitener.
1.) A root key is taken as the root keystring. It can be of any
reasonable length. The longer the stronger.
2.) A key attribute is taken as a checksum-like value that has been
derived from a computation that involved all root key elements. I use a
common method that XOR's each value after having started with zero. Using
a restricted domain, my result never exceeds 32. The asymmetric feature
of the algorithm is affected by a degree of shift or offset that is later
applied as a consequence of having generated an attribute larger than 32
in magnitude. (SEE OFFSET)
3.) A modified key is created from the root key. The patent application
stipulates that this can be any conceived modification that is
repeatable. This includes appending or truncating the result. In my
demonstrations I simply reverse the root string taking an element from
either end depending on the even/odd condition of the attribute. The
result of having a different length for the modified key is a highly
desirable "staggered pattern" of the applied cipher (not easily
discernible after masking.) No pattern is repeated in a 100 character
message when a 10 character key is used.
4.) The attribute is scaled and used to articulate rotation of this
modified key.
5.) The cipher OFFSET is derived by scaling the attribute. 0..32 = 0
offset; 33..64=1 offset; 65..96 = 3 offset.
5.) The attribute is used to articulate a slight shift of the root key
before the first cipher.
6.) The XOR cipher is applied to the message string recursively rotating
through all the root key elements. As the cipher is applied, both
elements are converted by taking their ordinates and subtracting 31.
After the XOR operation 31 and the OFFSET is added to the result which is
appended to the ciphered string.
7.) The attribute is used to articulate a slight shift of the modified
key before the first cipher.
8.) The same XOR cipher is applied to the message string recursively
rotating through all the modified key elements.
This is the encryption method. Then a whitener is optionally applied to
effect greater randomness.
Decryption differs ONLY on the polarity of the applied offset and the
sequence of the applied keys. Of course when no offset is applied (ZERO
value), the two methods are identical and one realizes that it makes no
difference whether the modified key is applied first or second in the
decryption process. With an OFFSET, the two methods differ in this regard
only. (Of course the whitener would be applied first in the decryption
process.)
I hope this explains the algorithm properly.
--
Charles Prichard
http://greentv.crosswalkcentral.com -PWS referral
http://members.nbci.com/chuck_prichard -PWS referral
> I am afraid that your explanation is (due to the style
> and terminology) fairly unclear. Anyway, my humble knowledge
> doesn't enable me to make much out of the above. BTW, does
> your data-dependent shift conflict with Hitachi's rotation
> patents?
>
> M. K. Shen
You're an expert from here MK. ----
------------------------------
From: Ned Scholes <[EMAIL PROTECTED]>
Subject: Tree algorithm
Date: Fri, 02 Feb 2001 16:34:30 GMT
I'm interested in an algorithm which search through a tree for a special
value and then returns the "cheepest" way there.
The root is 1 and then there is 2 ways to go, one (right) increases the
value with 4 and the other (left) multiplicates it with 3.
It costs 10 to go left and 5 to go right.
Tree(int value, int search, int sum){
if(display==search)
return sum;
if(display>search)
return 0;
Tree(value*3, search, sum+10);
Tree(value+4, search, sum+5);
}
The function can be invoked like this: Tree(1,109,0), then value=1,
search=109, sum=0.
This function is only going left as long as poosible and then right,
what I need to do is test ALL possible ways.
I'm not asking you to solve this, but I'd be happy to get any tips.
Thanks in advance.
------------------------------
** 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
******************************
