Cryptography-Digest Digest #564, Volume #13 Fri, 26 Jan 01 21:13:00 EST
Contents:
Last revision ("lemaymd")
Re: solving simultaneous equations in modulo arithmetic ("Matt Timmermans")
Re: RSA Source code ("Adam Smith")
Re: Decode Algorythim ("Yeah")
Re: Steak Stream Cipher (Bryan Olson)
Random Number Generator ([EMAIL PROTECTED])
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Paranoia ("Douglas A. Gwyn")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Random Number Generator ("Douglas A. Gwyn")
Re: Dynamic Transposition Revisited (long) ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: "lemaymd" <[EMAIL PROTECTED]>
Subject: Last revision
Date: Fri, 26 Jan 2001 18:31:18 -0600
Thanks for those final pieces of advice! I've modified my algorithm for
hopefully the last time using your suggestion and Joseph Ashwood's. He said
as I understand it that having eight encryption rounds doesn't do much
except slow my algorithm down. So without further ado, here it is: (an
excerpt from my documentation)
3. Description of algorithm
a. Key mutation
Encryption using the Bermuda Triangle 2.1 algorithm consists of several
steps consisting of XOR, rotate and addition operations, involving three key
derived values. It operates with 32768-bit plaintext and ciphertext blocks
controlled by a 32768-bit key, referred to as K0. The principal advantage
of this algorithm is the requirement that the entire key be known before any
decipherment can take place. This is insured by two key mutations,
described here.
The first key derivative is created by loading the first byte of K0, storing
it in a register and to memory, loading the next byte and XORing it against
the register containing the first byte, storing the register contents to the
next memory location and loading each subsequent byte in this manner, XORing
it against this register and storing it to memory. This key derivative is
referred to as K1. The original key, once again, is referred to as K0.
To form the second key derivative the entire key is loaded one byte at a
time from the end of the key to its beginning, stored to a register, XORed
and stored to a memory location as for K1. Note: the last byte in this
memory area will always equal the original key data. This key is referred
to as K2. These keys are now ready to be used in the encryption and
decryption processes.
b. Encryption
The actual encryption process involves one round of twelve XOR, addition and
bitwise rotation operations involving the three key mutations described
earlier and the original plaintext. The identification tag described in
section 2 is placed in the first twelve bytes of this file.
The steps involved are illustrated in this pseudocode segment:
Variables:
C Ciphertext
Kx Key "x"
P Plaintext
X Current byte position
Y Current key offset
Z General purpose register
C[x] = ( ( ( ( ( ( ( ( ( ( ( (
^ K2[y] ) + K1[y] ) >>> K0[y] )
^ K1[y] ) + K2[y] ) >>> K1[y] )
P[x] ^ Z ) + Z ) <<< Z{5lsbits} )
^ K0[y] ) + K0[y] ) >>> K2[y] )
Z = (Z^P[x])
Legend:
^ XOR
+ addition
<<< rotate left
>>> rotate right
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:94lo0p$j71$[EMAIL PROTECTED]...
>
> lemaymd <[EMAIL PROTECTED]> wrote in message
> news:94l9ds$k2m$[EMAIL PROTECTED]...
> > Poncho,
> > From what you've written, it's looks as though simplicity is not
this
> > cipher's weakness. What path would you suggest to strengthen it? I
> don't
> > truly understand how you would retrieve a completely random key (which
of
> > course it's not, but for simplicity let's say it is) when you have only
> the
> > ciphertext. Theoretically, as is the case with the true stream cipher,
> one
> > XOR operation between the key and data should be sufficient to make an
> > entirely impossible to crack piece of ciphertext. Because of the huge
> size
> > of the key utilized by this algorithm, it almost qualifies as a stream
> > cipher itself. Thanks for your valuable input! : - )
> If an attacker had only one block of unknown plaintext, that would likely
be
> the case. It would appear to be difficult to retrieve either the key or
the
> plaintext, and it would obviously be totally impossible for an XOR
> operation. However, if the attacker has multiple blocks encrypted under
the
> same key, that changes radically. If you look at my suggested attack, you
> use one block to guess key bits, and another block (or more likely,
several
> blocks) to verify the guess.
>
> As for what this cipher's weakness, it would appear to me caused by
several
> things:
>
> - Lack of diffusion between plaintext bits -- the value of one byte never
> affects the value of another byte. This means (for example) if the
attacker
> leaves that a plaintext "W" at offset 27 encrypts into the byte 0xf3, then
> he knows that, for any other block, a ciphertext byte 0xf3 at offset 27
> implies that the plaintext had a "W" there as well
>
> - Lack of diffusion between key bits. You at least made an attempt during
> your "key mutation" step, but it really doesn't help much -- knowing (for
> example, if a < b) K1[a] through K1[b], K2[a] and K3[b], you also know
K2[a]
> through K2[b] and K3[a] through K3[b], and that totally defines the
> transform for bytes a through b of the plaintext.
>
> >
> > "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
> > news:94j39m$map$[EMAIL PROTECTED]...
> > >
> > > lemaymd <[EMAIL PROTECTED]> wrote in message
> > > news:94i87e$d0e$[EMAIL PROTECTED]...
> > > > Poncho,
> > > > How does this algorithm look? Eight identical rounds are
> performed
> > on
> > > > each byte and each key value is rotated to the left one position
after
> > > each
> > > > round.
> > > >
> > > > C[I] =
> > > >
> > >
> >
>
(((((((((K1[I]^P[I])+K2[I])>>>K3[I])^K2[I])+K1[I])>>>K2[I])^K3[I])+K3[I])>>>
> > > > K1[I])
> > > >
> > > > K1, K2 and K3 are key derived values and the symbols use the
> conventions
> > > you
> > > > listed in your post.
> > > This looks almost as vulnerable to my attack. This attack is based on
> the
> > > following observations/assumptions:
> > >
> > > - In transforming N consecutive bytes of plaintext into ciphertext
(that
> > is,
> > > 8*N bits), the transform can be fully described by specifying 8*N+11
> bits
> > of
> > > internal keying data (based partially on how K1, K2, K3 are
> interrelated).
> > > The revised cipher increases that to 8*N+16 bits.
> > >
> > > - Given an arbitrary N byte plaintext section and N byte ciphertext
> > section,
> > > there are (at least reasonably often) approximately 2**11 values of
the
> > > above internal keying data that transforms that plaintext to that
> > > ciphertext. This is the fishiest part of the attack, which is true if
> we
> > > model the actual cipher as a random function, which it is not. With
the
> > > revised cipher, this increases to approximately 2**16 values, but this
> > > assumption also becomes rather more plausible.
> > >
> > > - Using dynamic programming, it is possible to explicitly derive the
> > > approximately 2**11 internal keying values corresponding to a
particular
> > > plaintext/ciphertext pair. The revised cipher makes finding the
values
> > > somewhat more expensive, but not prohibitively so.
> > >
> > > - Given a potential setting of internal keying data, we can check it
by
> > > using it to decrypt the corresponding range of bytes in the ciphertext
> of
> > > other blocks, and seeing if it decrypts to plausible plaintext.
> > >
> > > - We can use "crib-dragging" to find plausible plaintext/ciphertext
> > > sequences.
> > >
> > > That should be enough for you to draw in the dots to get the full
> attack.
> > >
> > > >
> > > > In the rotation operations the 5 lsbits of the key values are used.
> > > Ummm, if we're talking about rotating 8 bit bytes, we need only
specify
> 3
> > > bits
> > >
> > > >
> > > > "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
> > > > news:94b3hv$gda$[EMAIL PROTECTED]...
> > > > >
> > > > > lemaymd <[EMAIL PROTECTED]> wrote in message
> > > > > news:94aqn0$qrs$[EMAIL PROTECTED]...
> > > > > > To all interested:
> > > > > > Bermuda Triangle 2001 is an extremely fast, easy-to-use and
> > secure
> > > > > > cryptography engine. It is based on a new, 32768-bit algorithm
of
> > the
> > > > > same
> > > > > > name. Algorithm details can be found at my site as well as a
> > software
> > > > > > product that uses the algorithm, Bermuda Triangle 2001 Golden
> > Edition.
> > > > I
> > > > > > also have a free cryptography engine that uses a similar (but
> > > > > incompatible)
> > > > > > algorithm available for download. Visit the site at:
> > > > > > http://www.bermudatriangle.f2s.com/
> > > > > > These software packages are written entirely in 32-bit, win32
> > assembly
> > > > > > language and I can encrypt or decrypt an 8.4MB file on my
> Pentium(R)
> > > 166
> > > > > in
> > > > > > 8 seconds. Please give me your feedback!
> > > > > This should be pretty easy to break given several encrypted blocks
> > with
> > > > > known plaintext (either several short messages encrypted with the
> same
> > > key
> > > > > or one long one). As I understand it, your encryption algorithm
is
> > > > > essentially:
> > > > >
> > > > > C[i] = ((P[i] ^ x[i]) <<< y[i]) + z[i]
> > > > >
> > > > > where:
> > > > >
> > > > > P[i] is a byte of plaintext
> > > > > C[i] is a byte of ciphertext
> > > > > x[i], y[i], z[i] are key dependent values, and which are
repeated
>
> > > every
> > > > > 4096 bytes (and are interrelated)
> > > > > ^ is xor, <<< is bitwise rotate, and + is addition mod 256
> > > > >
> > > > > Because x[i], y[i], z[i] repeat every 4096 bytes, this repetition
> > length
> > > > is
> > > > > called a block.
> > > > >
> > > > > Here's how to rederive a good portion of the keying data: for each
> > byte
> > > > > within a block, locate two plaintexts that differ in that byte by
> one
> > > bit.
> > > > > If you have at least 16 plaintexts, and the plaintexts are random,
> you
> > > > have
> > > > > a good chance of having such a pair. Then, examine the
> corresponding
> > > > > ciphertexts, and see the lsbit where they differ. The rotate that
> > moves
> > > > the
> > > > > plaintext bit that differs to that lsbit ciphertext bit that
differs
> > > must
> > > > be
> > > > > correct, thus giving you the 3 lsbits of y[i]. A similar trick
can
> > work
> > > > if
> > > > > you don't have a single pair that differs by precisely one bit,
but
> > you
> > > > have
> > > > > several pairs with low-hamming weight difference.
> > > > >
> > > > > Once you have most of the y[i] values, you can use the
> > > interrelationships
> > > > to
> > > > > derive the 3 lsbits of x[i] and z[i]. Once you have that,
> > > reconstruction
> > > > > the rest of the x[i], z[i] values should be straight-forward.
> > > > >
> > > > > --
> > > > > poncho
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: solving simultaneous equations in modulo arithmetic
Date: Fri, 26 Jan 2001 19:04:22 -0500
Reply-To: "Matt Timmermans" <[EMAIL PROTECTED]>
You calculate their individual contributions and add them up, like so:
// make a polynomial that is 0 at x=3 and x=5
P2(x) = (x-3)(x-5)
// adjust it so that it satisfies D2 at 2, and take its value at 0
Q2(x)=P2(x)*(D2/P2(2))
S2 = Q2(0) mod 11 = 8
// this is a faster way
P3(x) = (x-2)(x-5)
S3 = P3(0)*(D2/P2(2)) mod 11 = 0
// faster still - you don't actually need to calculate the polynomial
NUM5 = D5*(-2)*(-3) mod 11
DEN5 = (5-2)*(5-3) mod 11
S5 = NUM5/DEN5 mod 11 = 7
// finally
S=S2+S3+S5 mod 11 = 4
This works because each Qi(x) is zero at the other points, but equals Di at
i, so the sum of those polynomials must be your original quadratic.
<G. Ralph Kuntz>; MD <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I am trying to implement Adi Shamir's "How to share a secret" key-
> splitting algorithm. For example, I want to share the secret "4" among
> 5 people so that any 3 can retrieve it. I pick a set of random
> coefficients a1 = 2, a2 = 5, and p = 11. My equations become:
>
> q(x) = (4 + (2 * x) + (5 * x ^ 2)) mod 11
>
> D1 = (4 + 2 + 5) mod 11 = 0
> D2 = (4 + 4 + 20) mod 11 = 6
> D3 = (4 + 6 + 45) mod 11 = 0
> D4 = (4 + 8 + 80) mod 11 = 4
> D5 = (4 + 10 + 125) mod 11 = 7
>
> Now D2, D3, and D5 get together to retrieve the secret "S". Their
> equations become:
>
> D2: 6 = (S + (2 * a1) + (4 * a2)) mod 11
> D3: 0 = (S + (3 * a1) + (9 * a2)) mod 11
> D5: 7 = (S + (5 * a1) + (25 * a2)) mod 11
>
> Unfortunately, the neuron(s) in my brain that knew how to solve this set
> of equations (in modulo arithmetic) have long since died as a result of
> certain liquids consumed in college.
>
> Any help on how to do it in an algorithm (so that I can implement it in
> Java or C)?
>
> Thanks, Ralph
------------------------------
From: "Adam Smith" <[EMAIL PROTECTED]>
Subject: Re: RSA Source code
Date: Sat, 27 Jan 2001 00:58:11 GMT
Wouldn't happen to know where I can get a bignum package for VB, would you?
: )
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:#rVPod$hAHA.340@cpmsnbbsa09...
> "Adam Smith" <[EMAIL PROTECTED]> wrote in message
> news:Cooc6.2631$[EMAIL PROTECTED]...
> > I'm looking for RSA source code in C/C++/MFC...anyone know where I can
> find
> > it? I need at least 512 bits...DH/DSS would work also...
> Well you could go to www.openssl.org, and download it. Or you could get a
> bignum package and write your own.
>
> RSA is:
> p = prime
> q = prime
> e = prime
> (three different primes)
> d = e^-1 mod (p-1)(q-1)
>
> Encryption:
> X = M^e mod pq
>
> decryption
> M = X^d mod pq
>
> signing and verification
> depends vastly on what signature type you do
>
> DH is even easier.
> Joe
>
>
------------------------------
From: "Yeah" <[EMAIL PROTECTED]>
Subject: Re: Decode Algorythim
Date: Fri, 26 Jan 2001 11:57:25 +1100
Yeah ill score some BIG points for 'comming up' with an almost unbreakable
encrytion algorythim 'on my own' ha ha ha
RSA was what i was looking for thanks
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:ed5Gn#8hAHA.327@cpmsnbbsa09...
> I also assume this is homework for some class.
>
> > Message^13(Mod C)=Encrypted
>
> > C bind the key
>
> > Only problem is that I have lost my notes as to what the decryption
> > algorytim is and ideas??
>
> 13d = 1 mod phi(C)
>
> Message = Encrypted^d mod C
>
> It's called RSA.
> Joe
>
>
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Steak Stream Cipher
Date: Sat, 27 Jan 2001 00:58:46 GMT
Henrick Hellstr�m wrote:
> My company has decided to publish the source code
> and a brief documentation of our most recent
> crypto project - a two way error propagating
> stream cipher we pretentiously call Steak
> (because it is both rare and well-done).
It looks like the idea is to rely on error propagation for
authentication. That's bad. Authentication mechanisms should
detect attempted forgery, not just pass garbage as if it were
plaintext.
For secure FTP, why would you not use TLS (updated SSL)?
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Random Number Generator
Date: Sat, 27 Jan 2001 01:12:36 GMT
Greetings,
Is it possible to write a program that would retrieve the number from
the pc.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sat, 27 Jan 2001 01:20:23 GMT
On Fri, 26 Jan 2001 23:30:36 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>On Fri, 26 Jan 2001 21:48:40 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
>in part:
>
>>The DES keyspace is 56 bits, a value 2 bits long.
>
>>Let's see: A value 10**21 bits long compared to a value 2 bits long.
>>Yeah, I'd say "some" were impossible to reach.
>
>Actually, 56 is a 6-bit-long binary number. And DES doesn't have 56
>different keys, it has 2^56 different keys, as noted below.
No, it's time to clear this up. I'm sorry I screwed up, because as
soon as one does that, the remaining total of one's work is just cast
aside. So let's go through it again:
DES has a 64-bit block.
DES has 2**64 unique data values.
DES represents a substitution table with 2**64 entries.
There are (2**64)! such tables.
2**64 is 18446744073709552000.
18446744073709552000! is some number with about 1.15397859e+21 bits.
SO, DES has a potential keyspace of about 10**21 bits, of which a
keyspace of 56 bits is actually implemented. We can compare the two
by subtracting 56 from 10**21 which gives us, naturally, 10**21. This
is how much larger the actual keyspace is (in bits) than the
implemented keyspace.
Alternately, one might say that DES has a potential keyspace of
2**(10**21) keys, of which 2**56 keys are actually selectable.
The log base 2 (bit-length) comparison between 10**21 and 56 is
correct.
>>The DES keyspace is such a tiny fragment of the potential keyspace
>>that there is no assurance at all that it retains the smooth
>>theoretical properties of distribution for which we might hope.
>
>quoting me:
>>>Well, by shuffling, I can't reach a total overall pairing of bit
>>>balanced inputs to bit balanced outputs such that
>>>
>>>0000000011111111 -> 1111111100000000
>>>
>>>and
>>>
>>>0000001010111111 -> 0000000011111111
>>
>>Why not? What does that mean? Are you criticizing the balancing
>>algorithm? Fine, use another.
>
>This has nothing to do with the balancing algorithm.
>
>This is about Dynamic Transposition itself.
>
>All possible N! transpositions of an N-bit block may be effected.
>
>However, 16! is also a tiny fraction of 12870!, just as 2^56 (not 56)
>is a tiny fraction of (2^64)!.
First, where does 12870! come from?
Absent balancing, Dynamic Transposition is just permutations. When we
have N elements, the number of permutations of those is N!. Here we
permute bits, and you present 16 of them, so we have 16!, which is
exactly 20922789888000, a number about 45 bits long.
Where is this 12870! coming from?
>If our PRTG - pseudorandom transposition generator - generates the
>transposition
>
>9 12 14 16 15 11 10 13 3 5 1 2 7 6 4 8
>
>then if the plaintext was
>
>0000000011111111
>
>the ciphertext will be
>
>111111110000000
>
>and if the plaintext was
>
>0000001010111111
>
>the ciphertext would be instead
>
>1111110100001000
>
>note that just as we have switched two bits in our plaintext, we have
>switched two bits in our ciphertext.
>
>A substitution cannot be reached by means of any transposition that
>will at the same time take
>
>0000000011111111
>
>to
>
>1111111100000000
>
>and take
>
>0000001010111111
>
>to
>
>0000000011111111
>
>since we are inverting a different number of bits in the plaintext and
>the ciphertext.
No. As far as I can tell, that has no relationship to Dynamic
Transposition at all, where a permutation is produced at random, and
then used once. The opponents do not get to explore the permutation
with different data values. DES, of course, is specifically designed
to be re-used without re-keying on every block. But I think you are
not discussing DES, but instead some sort of Dynamic DES which does
change keys on each block.
And that is fine, but there is no hope of being able to cover the
entire block-cipher keyspace with that keying either.
>Thus, as with DES, some total overall mappings, considering the whole
>ensemble of (plaintext, ciphertext) pairs generated at a single point
>in the process, are unreachable.
>
>This is not so much a criticism of Dynamic Transposition itself as of
>your claim that it is vastly superior to DES with
>stream-cipher-generated subkeys.
Dynamic Transposition can reach every possible permutation. With the
16-bit block you gave, every one of 16! (and NOT (2**16)!) or
20922789888000 possible permutations can be selected.
If you meant to use a 64-bit block, then the number of possible
permutations is "just" 64!, some number with about 296 bits.
If you meant my suggested 4096-bit block, then the number of possible
permutations is just 4096!, some number with about 43,251 bits.
But DES with a 64-bit block does not have 64 things to permute;
instead it has a substitution "table" with 2**64 entries. The number
of such tables (2**64)!, a number having 10**21 bits. That is the
keyspace. DES supplies 56 bits out of 10**21.
There is simply no hope of being able to reach every possible
conventional block cipher substitution "table" in the same way that
Dynamic Transposition can reach every possible permutation.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Paranoia
Date: Sat, 27 Jan 2001 01:22:31 GMT
Simon Jenkins wrote:
> Ellis' parting comment has him saying to Diffie,
> "You did more with it than we did."
> As an Englishman, this is an interesting phrase -
> it implies that GCHQ don't bother with RSA any more.
Not at all. It means that GCHQ and NSA didn't exploit the idea
to nearly the extent that the open researchers (RSA, DH) did,
at least not at the time. There are many reasons for that,
perhaps the main one being that they already had sufficiently
good cryptosystems and procedures in place for their main
customers.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sat, 27 Jan 2001 01:31:31 GMT
On Fri, 26 Jan 2001 15:37:09 -0800, in
<[EMAIL PROTECTED]>, in sci.crypt "Paul Pires"
<[EMAIL PROTECTED]> wrote:
>Terry Ritter <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
>>
>> On Fri, 26 Jan 2001 09:07:03 -0800, in
>> <[EMAIL PROTECTED]>, in sci.crypt "Paul Pires"
>> <[EMAIL PROTECTED]> wrote:
>>
>> >[...]
>> >I also am not clear on the goal. Yes there needs to be bit balancing so that
>> >a bias in the input is not recognizable in the output but by doing this
>> >hiding,
>> >don't you sacrafice another valuable property? Seems like the output would
>> >fail a taylored randomness test. You are going to get data that has a
>> >prefect
>> >distribution of zero's and ones within a block and something else if the
>> >block
>> >reference is displaced. Right?
>>
>> It is not necessary for strength or security that a cipher to produce
>> random-like output. Most ciphers do so, but such is not necessary.
>> Here I think the possible output codes do appear with equal
>> probability.
>>
>> This is a characteristic which represents the inefficiency of balanced
>> coding. But since that is a plaintext coding, and is known by both
>> designer and opponent, it does not seem particularly worrisome.
>
>Oh, I wasn't saying I found a breach, just that it seems to have an identifiable
>appearance & therefore offset from a thoretical ideal. More in the way of
>making a note than pointing at a practical fault.
And I was trying to point out that having random ciphertext is not a
theoretical strength ideal per se for this cipher. It may support
identifying this class of cipher, which is too bad, but it is simply
not -- by itself -- a strength issue. Maybe it could become one, but
I don't see it.
>My main comment was in response to suggestions made By John Savard on a way
>to fix it. First you need to find out if it's broke and if the fix is better than the
>break. As I said before, I think there are ways to avoid the bit balancing
>altogether. The interesting part of this is your clear statement of the security
>premis and that seems to be "transposition by random direction". I took the bit
>balancing part to be "One way you could do it" as a way to enable the
>other discussion.
Well, if the plaintext is not bit-balanced, it is going to leak
information. If we are satisfied that we have almost bit-balanced
data, maybe we could accept that.
But the fundamental security of the system would seem to be that any
possible plaintext block may have produced any particular ciphertext.
To even try to approach this goal, I think needs bit-balancing.
In practice, of course, we could almost certainly get by with just
having a few "different" bits in each block.
>> >Seems like what you'd want would be a method where the transposition
>> >works on a pile that is "Probably" balanced but where the deviation from
>> >perfect is not correlated to the input or output. I could be screwy here.
>>
>> I have mentioned the possibility of a statistical or "almost" balance,
>> which could be very effective. But it seems like that analysis would
>> be much more complicated. We would have to talk about the
>> distribution of balance, and how strength changes accordingly, which
>> seems beyond what can now be done.
>
>I don't know about that. I think it can be done. But that opinion and
>$2.79 might by a cup of coffee.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator
Date: Sat, 27 Jan 2001 01:39:31 GMT
[EMAIL PROTECTED] wrote:
> Is it possible to write a program that would retrieve the number
> from the pc.
Sure. What number?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sat, 27 Jan 2001 01:46:48 GMT
Terry Ritter wrote:
> SO, DES has a potential keyspace of about 10**21 bits, of which a
> keyspace of 56 bits is actually implemented.
That's an utterly pointless exercise, since it says nothing
about the very real differences in cryptosystems. *DES* does
*not* have a "potential keyspace" of yadayada; what has that
space is the class of *all possible transformations* from 64
bits to 64 bits. An actual cryptographic transformation is
divided into two parts: a general system that constrains the
class of transformations to just those having a certain
structure, and a key that is used to select the particular
member from that constrained class. There are obvious
practical reasons for predividing the space in that way.
------------------------------
** 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
******************************
