Cryptography-Digest Digest #833, Volume #11 Mon, 22 May 00 04:13:00 EDT
Contents:
Re: conceptually simple cipher (tomstd)
Refs to "Hillclimbing" and other algorithms? (Sundial Services)
First differential attack (tomstd)
Re: AES final comment deadline is May 15 ("Scott Fluhrer")
Re: conceptually simple cipher (Guy Macon)
Re: Blowfish Claims ... something not right (Paul Rubin)
Re: Blowfish Claims ... something not right (tomstd)
Re: pentium timings (lordcow77)
Re: Interpretation of Hitachi patent claims ("Lyalc")
Re: Interpretation of Hitachi patent claims (Roger Schlafly)
Equivalent keys in WHIRL128 (David Eppstein)
Re: Reasonably secure OTP passing (John Savard)
Re: pentium timings (Mok-Kong Shen)
Re: pentium timings (Mok-Kong Shen)
Re: Interpretation of Hitachi patent claims (Mok-Kong Shen)
Re: Interpretation of Hitachi patent claims (Mok-Kong Shen)
Re: Reasonably secure OTP passing (Mok-Kong Shen)
Re: Compare 3DES's. (Stefan Lucks)
Advanced ASCII encryption demo uses whitener ("C. Prichard")
----------------------------------------------------------------------------
Subject: Re: conceptually simple cipher
From: tomstd <[EMAIL PROTECTED]>
Date: Sun, 21 May 2000 19:21:24 -0700
In article <[EMAIL PROTECTED]>, tomstd
<[EMAIL PROTECTED]> wrote:
>I changed it to use an array S[0..256+15] and did this
>
>for r = 0 to 15 do
> a = a + sbox[((sbox[256+r] + b) mod 257) mod 256]
> swap(a, b)
>next r
And here is the break...
find a pair (b, b') such that
sbox[256+r] + b mod 257 = sbox[256+r] + b' mod 257
And you can identify (can't think of exactly how right now) part
of the key.
Oh well, any other comments? I want to know how to use the
attack I just described...
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Date: Sun, 21 May 2000 19:31:42 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Refs to "Hillclimbing" and other algorithms?
Where can I find URLs and sample-code which refer to "Hillclimbing" and
other computer techniques relevant to cryptanalysis?
(I presume that many of them exist by now.)
------------------------------
Subject: First differential attack
From: tomstd <[EMAIL PROTECTED]>
Date: Sun, 21 May 2000 19:37:39 -0700
I hope this is right... This is my very first differential
attack.
Take my 'simple cipher' (http://www.tomstdenis.com/cipher3.c)...
this is how to break it.
The round function
a = a + S[((S[256+r] + b) mod 257) mod 256]
Which I will simplify as (to save space)
a = a + S[(Sr + b) mod 257|256]
Can be broken like this.
Find a pair (b, b') such that
Sr + b mod 257 = Sr + b' mod 257
There are about 2^24 multiples of the form 257a + b, that will
get the right result. So the chance of getting a pair is about
2^-9.
Once you find a good pair there is a zero diffrence with prob 1
thru that round.
so it looks like
1. (0, b) - (0, b') 2^-9
2. (a', b) - (a',b') 1
The output of round #2 is the same, but since the b's are
different the prob is again 2^-9
3. (a', B') - (a',B'') 2^-9
And thru all 16 rounds is about 2^-36 or (2^-9^(8/2)). If I did
this right, it will require 2^37 pairs to break...
This is my first differential attack, so I hope I got it right...
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: AES final comment deadline is May 15
Date: Sun, 21 May 2000 19:34:44 -0700
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> DJohn37050 wrote:
>
> > Key agility is the ability to change keys fast or not. Contrast with
> > encrypting a large file with one key. The most extreme case is changing
a key
> > for every block. In practise, it is say 4 blocks.
>
> Earlier I learned that for DES hardware the generation of the
> subkeys could be done parallel with the round processing, i.e.
> available just in time for the next round. Doesn't that fact at
> least greatly reduce the significance of the key agility issue?
Yes, if you have a hardware implementation, this can reduce or eliminate the
cost of changing a key.
For the record, Rinjdael and Serpent in encrypt mode, and Twofish
bidirectionally makes it relatively simple for hardware to do key scheduling
on the fly, making the cost of changing a key zero.
Of course, if you are doing a software implementation, you're talking about
MARS or RC6, or Rinjdael or Serpent in decrypt mode, key agility is still a
consideration.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: conceptually simple cipher
Date: 21 May 2000 23:23:59 EDT
Look at http://www.ciphersaber.gurus.com for a siple cipher that
is generally considered to be strong.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Blowfish Claims ... something not right
Date: 22 May 2000 03:25:33 GMT
tomstd <[EMAIL PROTECTED]> wrote:
>How about a DJGPP callable long int math library? Sounds like fun.
Yes, that would be nice. Much as I hate to say it though, those
running under Windoze are probably using Micro$oft C. And one of
the more important applications for a compact library is browser
plugins, which again means M$ C unless you want to go nuts with the
interfaces. :-P
In your case, since you're using DJGPP, I don't understand why you're
messing with Windoze in the first place instead of
GNU/Linux/FreeBSD/whatever.
------------------------------
Subject: Re: Blowfish Claims ... something not right
From: tomstd <[EMAIL PROTECTED]>
Date: Sun, 21 May 2000 20:25:53 -0700
In article <8ga9bd$e3v$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Rubin) wrote:
>tomstd <[EMAIL PROTECTED]> wrote:
>>How about a DJGPP callable long int math library? Sounds like
fun.
>
>Yes, that would be nice. Much as I hate to say it though, those
>running under Windoze are probably using Micro$oft C. And one
of
>the more important applications for a compact library is browser
>plugins, which again means M$ C unless you want to go nuts with
the
>interfaces. :-P
>
>In your case, since you're using DJGPP, I don't understand why
you're
>messing with Windoze in the first place instead of
>GNU/Linux/FreeBSD/whatever.
Four words. Windows Compatible Video Driver.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: pentium timings
From: lordcow77 <[EMAIL PROTECTED]>
Date: Sun, 21 May 2000 20:43:40 -0700
In article <[EMAIL PROTECTED]>, tomstd
<[EMAIL PROTECTED]> wrote:
>I will go ahead and disagree with you now. When timing my RC5
>code I always get the same clocks per block output, no matter
>what is running.
You don't seem to understand why your implementation of a cycle-
level timing routine is inherently flawed and cannot be relied
on to give correct results, except by accident. It's much like
declaring main to return void in C: your compiler may choose, at
its infinite discretion, to emit code that does what you want,
or alternatively, turn your computer into a toaster. RDTSC is
not a serializing instruction; the CPU may choose to execute it
at any point while it is in the instruction reorder buffer
waiting for dispatchment to its corresponding functional unit.
You cannot rely on the CPU to wait until a specific instruction
follows in lexigraphical order (ie. in the neat dissassembly
that you may see) to actually execute an instruction. Moreover,
the RDTSC may run in parallel with other instructions, may be
stalled in the pipeline, may run into a pipeline bubble because
of a register contention issue on an entirely seperate
instruction, may be flushed from the pipeline becuase of data
dependency problems, and its result may not even be committed to
programmer visible register space for an undefined period of
time UNLESS there is an explicit dependency, upon which the CPU
will respect apparent sequential execution of the instruction
stream. In other words, if it works at all, you are exceeding
lucky. It is unequivocally incorrect to call RDTSC and expect it
to return anything resembling what you may expect unless you
serialize the processor first. The easiest way to do this is to
execute the CPUID instruction before every instance of RDTSC.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Interpretation of Hitachi patent claims
Date: Mon, 22 May 2000 14:04:28 +1000
Perhaps the suggestion should be a formal process where we all get notified
of patent applications, then we all get a chance to have some formal input.
We all have the options to review patent applications on a initiative driven
basis - if you don't put in the effort, you get no chance to comment before
a patent is granted.
Public review of patent applications is possible, at least in Australia, and
under PCT (Patent cooperation Treaty). I assume the US has something
similar.
Once the patent enters the formal examination phase (I think that's the
right phase), it is openly published, and anyone is allowed to examine,
comment or challenge the application.
If the challenge is accepted as valid, the applicant may then make minor
changes (some rules exist on what 'minor' means, apparently), start again,
or give up.
If you/me/anyone doesn't look at all patents, then the axaminer only has
their own skills and interpretation for the basis of assing the validity of
the claim.
lyal
Mok-Kong Shen wrote in message <[EMAIL PROTECTED]>...
>
>
>"Trevor L. Jackson, III" wrote:
>
>> What may appear novel to a patent examiner may not be novel to someone
fully
>> aware of prior art. This is why patent apps have to disclose prior art.
Such
>> disclosures inform the examiners in areas they cannot be expected to be
>> adequately informed. Unobviousness it not as easy as novelty. The ISO
unit of
>> measure for prior art is the second. There is no unit for unobviousness,
so a
>> patent application cannot support the unobviousness requirement with
objective
>> information. Thus disputes about the obviousness of patent applications
resolve
>> down to subjective evaluations.
>
>This underlines the desirability of having public review of patent
applications.
>
>M. K. Shen
>
>
>
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Interpretation of Hitachi patent claims
Date: Sun, 21 May 2000 22:28:54 -0700
Lyalc wrote:
> Public review of patent applications is possible, at least in Australia, and
> under PCT (Patent cooperation Treaty). I assume the US has something
> similar.
No. In the US, an inventor has the right to keep his application
secret. They just passed a law allowing publication before issue
in some cases, but usually only because it is published overseas
anyway.
> Once the patent enters the formal examination phase (I think that's the
> right phase), it is openly published, and anyone is allowed to examine,
> comment or challenge the application.
>
> If the challenge is accepted as valid, the applicant may then make minor
> changes (some rules exist on what 'minor' means, apparently), start again,
> or give up.
>
> If you/me/anyone doesn't look at all patents, then the axaminer only has
> their own skills and interpretation for the basis of assing the validity of
> the claim.
The US issues about 100,000 patents a year. How many are you
willing to volunteer to scrutinize?
------------------------------
From: David Eppstein <[EMAIL PROTECTED]>
Date: Sun, 21 May 2000 22:57:08 -0700
Subject: Equivalent keys in WHIRL128
Whirl128 is a block cipher submitted to the sci.crypt cipher contest by
Runu Knip; see http://www.wizard.net/~echo/crypto-contest.html for details.
I have some concerns with the subkey generation phase of the algorithm,
specifically this loop:
*------------------------------------------------------------------*
| for j in [1..4] do |
| for i in [0..63] do |
| K[i] := K[i] + 0xb7e15161 |
| + (K[(i+ 3) mod 64] <<< K[i] shr 10) |
| + (K[(i+13) mod 64] <<< K[i] shr 25) |
| + (K[(i+32) mod 64] <<< K[i] shr 0) |
| + (K[(i+41) mod 64] <<< K[i] shr 15) |
| + (K[(i+57) mod 64] <<< K[i] shr 5) |
| + (K[(i+62) mod 64] <<< K[i] shr 25); |
*------------------------------------------------------------------*
Here K is initialized to the key data (D) and padded with zeros. But the
problem is that multiple values of D can lead to the same final value of
K. For instance, if D is a 128 bit key (the minimum recommended for the
algorithm) consisting of the 4 words (0x55555555 - 0xb7e15161, *, *,
0x55555555) and
D' = (0xaaaaaaaa - 0xb7e15161, *, *, 0x55555555), then the very first
iteration of the loop will set K[0]=0xffffffff in both cases, after which
those two keys act completely the same.
I was too lazy to work out the details of which key is mapped to which,
but I did a heuristic analysis based on the assumption that, if the K[i]'s
involved are random, the data-dependent rotation plus addition involved at
each iteration of the loop acts like a random function. Then, I think,
for a given 128-bit key (p,q,r,s), the expected number of equivalent keys
(p',q,r,s) such that K[0] becomes the same after the first iteration (as
in the example) is almost one (more precisely 31/32 since the values p'
with the same rotation amount as p certainly don't work and each remaining
value has a 2^{-32} chance of working). The second iteration of the loop
can't do anything interesting (all the other K[j]'s are still zero) but in
the third iteration we add a shifted copy of K[0] to K[2], so have an
expectation of almost one equivalent key (p,q,r',s) such that the K arrays
become the same in the third iteration. And similarly, we have an
expectation of almost one equivalent key (p,q,r,s') such that the K arrays
become the same in the fourth iteration.
Moreover, there are various possibilities for combining pieces from these
equivalent keys. If p' and r' both exist, then (p',q,r',s) is also an
equivalent key, since K[0] becomes the same on the first iteration after
which the third iteration looks exactly like the third iteration for
(p,q,r',s). If r' and s' both exist, then (p,q,r',s') is also an
equivalent key since r' and s' don't interact with each other until much
later in the subkey generation phase.
Finally, if s' exists, then there is an expectation of almost one for
there to exist a value p* such that the first iteration for (p*,q,r,s')
makes K[0] the same as the first iteration for (p,q,r,s). If so, then
(p*,q,r,s') is also an equivalent key, as is (p*,q,r',s').
With all these equivalent keys, if one could quickly identify one member
of each equivalence class, the cost of brute force searching should go
down from 2^128 to something smaller like maybe 2^125.
Roughly the same analysis would work for key lengths larger than 128 bits
and the savings would be greater since there seems to be more chances for
keys to become equivalent.
A patch is easy: simply make sure that each step of the subkey generation
stage is invertible. For instance, change the line
K[i] := K[i] + ...
to
K[(i+1)&077] += ...
but leave unchanged all the other occurrences of K[i] in the expression,
so that part of the key is acting on other parts of the key (like a
Feistel cipher) rather than on itself.
--
David Eppstein UC Irvine Dept. of Information & Computer Science
[EMAIL PROTECTED] http://www.ics.uci.edu/~eppstein/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Reasonably secure OTP passing
Date: Mon, 22 May 2000 06:12:39 GMT
On Sun, 21 May 2000 22:32:25 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>And, persuing the idea further, one could use
>a fairly good encryption algorithm to encrypt known texts (books
>etc.) to generate the streams.
Actually, this is a good idea - but possibly not in the way you were
thinking of it.
While the idea of passing an OTP in encrypted form - thus losing the
absolute security of the true OTP - to augment the security of a
conventional cryptosystem, although partly a fallacy in some forms, is
an interesting one - and not having true random bits seems to get us
away from this idea, and put us back in the world of conventional
cryptosystems, there _is_ a way in which something like what you note
above is related.
Let us say that we wish to save bandwidth, but encipher a message in a
fashion which is _equivalent_ to the following:
generate random keyletters, apply them to the plaintext using
Vigenere, and
send the keyletters enciphered by columnar transposition
send the plaintext+key enciphered by Playfair
We note that the enciphered keyletters are available for interception.
So, we could conclude that we don't lose anything by switching to the
following:
using a fixed table of random keyletters, which may be known
encipher (or, to be strictly equivalent, decipher!) them using
columnar transposition
apply the result to the plaintext by Vigenere
encipher the enciphered plaintext by Playfair
This still avoids some of the attacks available on
Playfair+transposition or transposition+Playfair. So what we have is
the concept that unkeyed 'scrambling' steps - like what modems do to
avoid a long string of 0 bits becoming a signal that doesn't clock -
can improve the strength of some cipher methods.
But that, in turn, hints that this only takes place if the cipher
methods are weak, or poorly designed, and hence we reach a more
sophisticated objection to this sort-of-OTP message splitting
proposal.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: pentium timings
Date: Mon, 22 May 2000 09:41:21 +0200
Jerry Coffin wrote:
> If you want some timing code that actually works, I'll be happy to
> send it to you. Alternatively, I'm pretty sure I've posted it to
> comp.lang.asm.x86, so a search on deja.com should turn it up. Much
> like cryptography, making this work correctly can be substantially
> more work than most people expect.
If you maintain a webpage, I suggest that you put it there for convenient
access by other people. To get accurate timing is indeed a difficult task
to do under modern operating systems, I believe.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: pentium timings
Date: Mon, 22 May 2000 09:41:26 +0200
tomstd wrote:
> What you have todo is call 'timer(void *)' more then once and
> take the average to get a good idea of what's going on.
The problem is that OS switches between tasks and does some
management work thereby. You don't know how much switching
time has been put onto your account.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Interpretation of Hitachi patent claims
Date: Mon, 22 May 2000 09:41:31 +0200
Roger Schlafly wrote:
> Lyalc wrote:
> > Public review of patent applications is possible, at least in Australia, and
> > under PCT (Patent cooperation Treaty). I assume the US has something
> > similar.
>
> No. In the US, an inventor has the right to keep his application
> secret. They just passed a law allowing publication before issue
> in some cases, but usually only because it is published overseas
> anyway.
On the other hand, (in journal etc.) published stuffs are in the
public domain and can't be subsequently patented in Europe,
as far as I know.
> > Once the patent enters the formal examination phase (I think that's the
> > right phase), it is openly published, and anyone is allowed to examine,
> > comment or challenge the application.
> >
> > If the challenge is accepted as valid, the applicant may then make minor
> > changes (some rules exist on what 'minor' means, apparently), start again,
> > or give up.
> >
> > If you/me/anyone doesn't look at all patents, then the axaminer only has
> > their own skills and interpretation for the basis of assing the validity of
> > the claim.
>
> The US issues about 100,000 patents a year. How many are you
> willing to volunteer to scrutinize?
But competitors that have sufficient patent expertise resources do
have a good opportunity to submit arguments against the patent
applications being submitted. This improves the situation quite a
lot in my humble view.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Interpretation of Hitachi patent claims
Date: Mon, 22 May 2000 09:41:35 +0200
Jerry Coffin wrote:
> Looking at things, it appears that they're 5,835,600 and 5,724,428.
> It's possible that the Hitachi patents invalidate the RSA DSI
> patents, but not the reverse -- the Hitachi patents are substantially
> older (both were issued before either of the RC5 patents was applied
> for). I doubt the Hitachi patents affect the RC5 patents though: the
> RC5 patents specifically call for _data dependent_ rotations, which
> is what appears to be new and unique.
Maybe one could say that Hitachi's 'predetermined' amount of rotation
doesn't cover dynamic values and hence doesn't conflict RC5. On
the other hand, RC5's data dependence is dependence in one
specific way and shouldn't be interpreted to cover using arbitrary
dynamic values of amount of rotation in general, I suppose.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Reasonably secure OTP passing
Date: Mon, 22 May 2000 09:41:07 +0200
John Savard wrote:
> <[EMAIL PROTECTED]> wrote, in part:
>
> >I think that within the framework of practical requirement, i.e. we
> >don't need 'absolute' security, the two OTPs could be replaced
> >by something that do not exactly qualify being (ideal) OTP.
>
> Then one doesn't need to bother sending it, one can just use this
> other thing as a normal stream cipher component. We still are falling
> short of a true OTP, since the random keystream is being transmitted
> in a way that is subject to interception and (when correlated with the
> regular messages with which it is used) cryptanalysis.
>
> I think the question of using true random numbers for message
> splitting, and under what circumstances that produces some genuine
> improvement in security, is one worth looking into.
I never intend to belittle the value of OTP. However, I believe the
difficulty of obtaining an ideal OTP and, more importantly, of
managing the material and ensuring proper usage of it seems to
render OTP less advantageous, when compared with alternatives
such as the one presently discussed, in the majority of practical
applications. The alternative discussed of course has its
weaknesses (e.g. it can NEVER have provable security, though
an (ideal) OTP doesn't have provable (testable) 'existence' in
practice, unfortunately) and may not be advantageous over other
schemes, which may be simpler, stronger, etc. etc. On the other
hand, I think that, excepting under circumstances the issue of
(computing) cost, it does constitute a viable method for practical
use, since it is plausible to consider that its strength should
improve with the number of constituent streams employed. In
many cases in practice a computer is not constantly working at
its full load. This allows some pre-computation of the streams.
Then the actual usage in a way akin to OTP at message encryption
time can in fact be fairly fast, I believe. In my humble opinion,
one should not limit oneself to the use of a single fixed encryption
scheme for all times. (Unfortunately there are cases that one has
to do so, though.) Using a diversity of algorithms renders the life
of the opponent much harder. Thus I believe the scheme discussed
deserves a place in one's repertoire. I like also to repeat that your
suggestion of encrypting an OTP-encrypted message is a good
idea in my humble view.
M. K. Shen
------------------------------
From: Stefan Lucks <[EMAIL PROTECTED]>
Subject: Re: Compare 3DES's.
Date: Mon, 22 May 2000 09:31:28 +0200
Known attacks on double DES, 2-key triple DES and 3-key triple DES:
-- double DES: best known attack needs about 2^57 encyptions
-- 2-key triple DES: also about 2^57 encyptions (!) with many chosen
plaintexts
-- 3-key triple DES: about 2^108 encyptions with many chosen plaintexts,
or about 2^113 encryptions with few chosen plaintext
All these attacks need a lot of memory, but there are Oorschot-Wiener like
time-space tradeoffs, which allow the attacker to save much memory at the
cost of a somewhat increased running time. Also, you can replace the
*chosen* plaintexts by *known* plaintexts at moderate costs.
Thus, double-DES is about as strong as expected from single DES. Two-key
triple DES is not much stronger, if many plaintexts can be encrypted under
the same key. Three-key triple DES is about as strong as one would naively
have expected from double DES (as far as we know).
On 20 May 2000, William Rowden wrote:
> In article <8g5g80$7s9$[EMAIL PROTECTED]>,
> Paul Schlyter <[EMAIL PROTECTED]> wrote:
> > In article <8g4lqn$1eb$[EMAIL PROTECTED]>,
> > William Rowden <[EMAIL PROTECTED]> wrote:
> > > . How much stronger is use of 24 bytes of key as compared with 16
> > > bytes? That is, how does E(K1,D(K2,E(K3,x))) compare to
> > > E(K1,D(K2,E(K1,x)))? A naive view would say that 24 bytes would
> > > take at least 2**64 longer to crack than 16 bytes, but this
> > > assumes that no attack more efficient than brute force is
> > > available.
> > 24-byte keys aren't much stronger than 16-byte keys, due to that
> > attack on 2DES which reduces a 24-byte key to a 16-byte key.
>
> Thanks! That's exactly the kind of information for which I'm looking.
> Where might I read documentation of the details of this attack?
Have a look at my "papers" page:
http://th.informatik.uni-mannheim.de/People/Lucks/papers.html
See the paper "Attacking Triple Encryption" and references therein.
--
Stefan Lucks Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany
e-mail: [EMAIL PROTECTED]
home: http://th.informatik.uni-mannheim.de/people/lucks/
====== I love the smell of Cryptanalysis in the morning! ======
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Advanced ASCII encryption demo uses whitener
Date: Mon, 22 May 2000 06:28:58 GMT
CipherText has been enhanced with a whitener.
http://greentv.com/Java/CipherText_2.html shows 2-way Java->Perl =
performance demonstration.
Key domain has been increased to 32 ordinates.
16 byte whitener key domain is 32 ordinates.
1024 byte whitener domain is 32 ordinates (not the 96 originally =
planned)
Message domain is 96.
Using a key of 16 values each with 32 possibilities to encrypt a message =
there are 1.208 E+ 24 possible key combinations. With a whitener 1024 =
bytes and a domain of 32 values, a whitener key of 16 values is applied =
to create a unique whitener. This creates 1.208 E+24 more possible key =
combinations. The two combined are 1.461 E+48 combinations.
Using 8 byte values result in E +24 values.
The numbers are based assuming a random cipher and whitener, but they =
also assume that a key length is known. Depending on the implementation, =
its possible that an attacker will not know the key length. In that case =
there is probability that a large portion of the attack will be =
manifested in key combinations involving keys of incorrect lengths. =
These combinations could arguably be as high as 8.617 E+20 when a 16 =
byte key is selected. This would yeild 1.193 E+69 possible combinations.
The cipher in the demonstration is still symmetric, however a small =
offset can be added making the encrypt method differ slightly from its =
counter method.
In practical use CipherText has been demonstrated for Page Tag =
encryption and for form data and email encryption. The demonstrations =
have assumed that the necessary key exchanges are practical.
The algorithm applies the primary key having 32 possible ordinates for =
each key element to the message, then it applies the modified key that =
is some remake of the primary key (shortened or lengthed to mask key =
length) which has been shifted as specified by the primary key attribute =
(LRC checksum.) This output is then whitened with a 1024 byte mask that =
has been encrypted with a key having 32 possible ordinates for each key =
element.
The result is that practical message security has been demonstrated in =
the in the same realm as DES 128 bit when using two 8 byte keys. The =
attacker has to be able to break the whitener key and then the =
CipherText message.
It is assumed that serious applications will require key exchanges to =
support 8 byte keys.=20
All CipherText output is compatible with the default HTTP transfer =
protocol.
Its possible that the algorithm will be implemeted soon in C++ for =
closer analysis.
-Charles Prichard
www.greentv.com
------------------------------
** 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
******************************
