Cryptography-Digest Digest #316, Volume #14 Tue, 8 May 01 17:13:01 EDT
Contents:
Re: A Question Regarding Backdoors (bob)
Are Boschloos creatures of GOD? (Fight Boschloo)
Are Boschloos creatures of GOD? (Fight Boschloo)
Do Boschloos have a SOUL? (Kill a Boschloo)
Re: Question about randomness and OTPs (Jim D)
Bleaming strock cipher ("Paul Pires")
Re: Random and not random (James Felling)
Re: free en/decryption library ("Tom St Denis")
Re: A simple encryption algorithm based on OTP ("Tom St Denis")
Re: Best, Strongest Algorithm ("Tom St Denis")
Re: GF(2^W) sboxes timings ("Tom St Denis")
Re: Best encrypting algoritme ("Tom St Denis")
Re: ECC question ("Tom St Denis")
Optimizing AES throughput (Harshal Chhaya)
Re: Optimizing AES throughput ("Tom St Denis")
----------------------------------------------------------------------------
Subject: Re: A Question Regarding Backdoors
From: [EMAIL PROTECTED] (bob)
Date: Tue, 08 May 2001 18:21:55 GMT
Hi all,
I am the original poster who started this thread with my question regarding
the absolute need for backdoors in US cipher systems that are meant for
domestic and international consumption. I never dreamed that this thread
would take on a life of its own and spark great discussions and thoughtful
analysis of the topic. I have enjoyed every minute of it. Thank you :)
------------------------------
Date: 8 May 2001 18:31:01 -0000
From: [EMAIL PROTECTED] (Fight Boschloo)
Subject: Are Boschloos creatures of GOD?
Crossposted-To: alt.privacy.anon-server,alt.security-pgp
Just wondering
------------------------------
Date: 8 May 2001 18:31:00 -0000
From: [EMAIL PROTECTED] (Fight Boschloo)
Subject: Are Boschloos creatures of GOD?
Crossposted-To: alt.privacy.anon-server,alt.security-pgp
Just wondering
------------------------------
Date: Tue, 8 May 2001 14:52:25 -0400
Subject: Do Boschloos have a SOUL?
Crossposted-To: alt.privacy.anon-server,alt.security-pgp
From: Kill a Boschloo <[EMAIL PROTECTED]>
NOTICE: This message may not have been sent by the Sender Name
above. Always use cryptographic digital signatures to verify
the identity of the sender of any usenet post or e-mail.
Do they have brains, in the first place?
------------------------------
From: [EMAIL PROTECTED] (Jim D)
Subject: Re: Question about randomness and OTPs
Date: Tue, 08 May 2001 19:03:20 GMT
Reply-To: Jim D
On Tue, 8 May 2001 11:19:59 +0200, [EMAIL PROTECTED] (Joe H Acker) wrote:
>Hi!
>
>There's still one thing I don't understand about OTPs. Maybe someone can
>point in the right direction. Here's my question:
>
>If I XOR the random data with my plaintext, the resulting ciphertext
>will have the same (maximum) entropy than the random data. Is that
>correct?
>
>If that's correct, then I don't understand why I cannot use the
>ciphertext to encrypt another plaintext with it, and so on.
OhmyGod no....!!!!
The ciphertext in the first enciphering may well have the same
entropy as the key, but you just can't use that ciphertext as
key for a second encryption....if you've transmitted the first
message, the key for the second is available to the enemy;
in the public domain. You must be able to see why that isn't
a Good Idea. And of course your system is longer an OTP.
--
______________________________________________
Posted by Jim D.
Nole me vocari, ego te vocabo.
jim @sideband.fsnet.co.uk
dynastic @cwcom.net
______________________________________________
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Bleaming strock cipher
Date: Tue, 8 May 2001 12:27:21 -0700
The following is a cipher concept I have been working on.
This material is very similar to the last concept I posted, the
one that Scott Fluhrer and Brian Olson euthanized on contact.
The idea is a stream cipher that processes it's output in large
blocks. The goal is to have a cipher that is:
1, relatively simple.
2, very fast.
3, internally obscure, one that does not reveal it's internal state
so easily for a chosen or known plaintext attack and one that
is safe against bit-flipping.
This cipher is simple (in code) and runs at 8.3 clocks per byte
Note: No file I/O.
The basic idea is to use two different sets of internal tables.
One table, "A", is dynamically changing and its values are used
only as location arguments for retriveing and storing values
from the plaintext, ciphertext and the other table, "B". Both
tables, A&B are split in two and handled seperately as A0,A1, B0,B1.
Each cycle, the operations performed on these table halves
alternate. Pointers are assigned to these table halves (A_old, A_new
& B_old, B_new) and to alternate, the pointers are just re-assigned
(swapped) for each cycle. So, here are the pieces:
"A0" and "A1" together comprise table "A" and are 64 element tables, each containing
the
values 0-63 initialized in a key dependent way. (unsigned char[75])
Note: 11 bits from the front of the array are duplicated at the end.
"B0" and "B1" together comprise table "B" and are each 64 element tables. Each element
is 32
bits wide and are also initialized in a key dependent way. (unsigned int[64]) .
"A_new" and "A_old" are pointers that can be set and reset to the A tables. (unsigned
char*)
"A_new_32" is a 32 bit wide pointer which is always set to the new "A" address.
(unsigned int*)
"B_new" and "B_old" are pointers that can be set and reset to the B tables. (unsigned
int*)
After every text block is processed (cycle) the pointers are re-set so that what
once was an old table becomes the new table and its values are then updated,
First "B" then "A". Cyphertext and plaintext are handled as 32-bit units and
are processed as blocks of the same length as a "B" table (64 elements).
To process a block:
Encrypt:
for (i=0, i<64, i++)
{
C[A_old[A_new[i]]] = B_old[A_new[i]] ^ B_new[A_old[i]] ^ P[i];
}
(Decrypt would be:
P[i] = B_old[A_new[i]] ^ B_new[A_old[i]] ^ C[A_old[A_new[i]]] ;)
Reset B pointers alternately. (odd is just the last bit of the cycle counter "x")
B_new = (odd) ? (unsigned int*) &B0 : (unsigned int*) &B1;
B_old = (odd) ? (unsigned int*) &B1 : (unsigned int*) &B0;
Update the Old (now named new) State B table. B1 in the case where the
cycle count "x" is even:
unsigned int wrapper = x ^ (B_new[0]<<27);
for (i=0, j = 1, k = 63; i<63; i++, j++, k--)
{
B_new[i] = (B_new[i]>>5) ^ P[i] ^ C[A_new[k]] ^ (B_new[j]<<27);
}
B_new[63] = (B_new[63]>>5) ^ P[63] ^ C[A_new[0]] ^ wrapper;
As before, find an "A" change argument (Tsel) from A vrs B
and smoosh it down to a 6 bit (0-63) value.
unsigned int Tsel = B_new[A_new[x & 0x3F]];
for (i=1; i<6; i++) Tsel ^= Tsel>>(i*6);
Tsel &= 0x3F;
Reset the A pointers alternately and set up the Byte shift according to Tsel:
A_new_32 = (odd) ? (unsigned int*) &A1[Tsel>>4] : (unsigned int*) &A0[Tsel>>4];
A_new = (odd) ? &A1[Tsel>>4] : (unsigned int*) &A0[Tsel>>4];
A_old = (odd) ? &A0[4] : &A1[4];
Update the Old (now new) A table. "Trans" is a table of 16
different relative permutations that could be inflicted on the
elements of A_new_32 by relocating four values (32 bit chunks)
at a time. One of the 16 transpositions will be selected and used
by the lower 4 bits of Tsel. The upper two bits of Tsel are used to
shift the pointer assignment (above) to one of four different byte
alignments. So, there are 64 different, relative element relocations,
for all 64 elements, one of which will be chosen by Tsel and used
to permute the values in the A_new table.
Tsel &= 0x0F;
for (i=0, j=1; i<16; i++, j++)
{
A_new_32 [Trans[Tsel][i]] = A_new_32 [Trans[Tsel][j]];
}
unsigned int swap = A_new_32 [0]>>24;
A_new_32 [0] = (A_new_32 [0]<<8) | swap;
A_new_32 [16] = A_new_32 [0]; A_new_32 [17] = A_new_32 [1];
One "block" cycle done, increment x and proceed until P or C is done.
Of course, there is no mention of how these tables are initialized in a key
dependent fasion, IV or salt usage or how the blocks are padded out
at the end of a message. A full description with simple and complete
versions of the source code is availiable. I'll have it up on a web site
for download soon but I'd be happy to E-mail to anyone who
wants it. PDF file ~250Kb.
If I have done this right, All an adversary gets from a known plaintext
is the knowledge that 64 pieces of each ciphertext relate to 64 pieces
of the plaintext in each corresponding block. He does not know the
mapping. Even if he did, he can extract the 64 pieces of internal state
that were XORed but these are composits of 128 pieces, constantly
changing and relocating dynamically and in a key and message
dependent way.
Now let's see if I've built another garage door and handed Pancho the
remote opener.
Paul
All rights are preserved. Some or all of this material may be
covered by patents held or filed for by the author or unknown
others. No presentment is made that the methodology contained
herein is suitable, safe or unencumbered for commercial use.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Tue, 08 May 2001 15:17:48 -0500
Mok-Kong Shen wrote:
> I continue to think that the claim 'there is no best
> or worst permutation to choose' logically implies
> 'any choice is equivalent to the other' and hence the
> choice is entirely free, much like e.g. when deciding
> to buy a certain book in a store I can pick at my will
> any one copy of the same book on the shelf. (I might
> habitually try to always pick the 3rd copy, if there
> are at least three copies, because, for example, the
> number 3 has something to do with my birthday, but
> does it really matter?)
>
> M. K. Shen
An analogy by way of explanation.
I need to lock a box.( and I may neeed to lock many others in the future).
So I go to the lock store and buy their entire stock of Brand X padlocks.
Now I have a pile of padlocks. Which ever lock I choose for a given box
makes no difference, as all of the locks are the same. . So long as my
choice of padlock is fixed or independent of the combination of the locks(
i.e. I always pick the first one I touch, or I roll a die and take the Nth
lock out of the box where n is the number on the die.) then I am as secure
as possible. However, if I use some method of picking a lock based upon the
combination of an arbitrary lock-- it does not matter what that method is
just that it is a known method -- then somewhere down the line, when I have
used a large portion of my locks, it may be possible( especially if a some
of the combinations become known), for the safe cracker to have a better
than random chance of guessing the combination of the lock on a given safe.
Yes, in most cases this will not help, but there will be a certian number of
cases where the knowlegde that the locks were chosen in manner x, and
knowlege of what choices were made when exists, then it will be possible to
eliminate possible combinations for the lock being picked, and thus weaken
that particular lock.
Thus in this case three things happen.
1) It does not matter which lock I pick for which box.
2) Choosing not to permute is a perfectly valid method( first lock I touch
is fine), or choosing to roll a die and pick from an ordered set is also
fine, but exactly equivalent to picking the first lock I touch.( so why roll
the die in the first place)
or
3) chosing a lock in a manner based upon the combination of one( or all )
locks, will lead to a potential weakness down the line.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: free en/decryption library
Date: Tue, 08 May 2001 20:39:06 GMT
"yomgui" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> if you can't recognise a xor everything must be homebrew for you anyway
I don't want to start a flame war, but your cipher is a homebrew. Until you
get more formal and have others analyze it you should consider it very
unsecure.
Tom
>
> Tom St Denis wrote:
> >
> > "yomgui" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > free, small, cross platform, safe, simple, fast, open source,
> > > symmetric stream and file encryption
> > >
> > > http://bigfoot.com/~kryptyomic
> >
> > Link doesn't work. Aren't you that guy that made a homebrew system
anyways?
> >
> > BAAAAAAD
> >
> > Tom
>
> --
> ¥øµgüí
> oim 3d - surface viewer - http://i.am/oim
> kryptyomic - encryption scheme - http://bigfoot.com/~kryptyomic
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: A simple encryption algorithm based on OTP
Date: Tue, 08 May 2001 20:40:08 GMT
(********8don't post in HTML btw....******)
Your system is very weak. Consider one known plaintext block.
Tom
"Siva Prasad Gummadi [T]" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
Hi,
Following is a simple algo. based on OTP which occurred to me just
a while ago.
Let's suppose we have N bits of plain text. Choose some k-bit key.
This is a secret key and thus needs to be transmitted to the other end
securely. Choose an appropriate value for k, in context of brute force
attacks. Now the procedure is to divide the plain text into blocks of
each k-bit length and encrypt (XOR) the first block with the key, second
block with the first block of plain text, and simly., every other block with
the previous plain text block.
Since this is basically OTP I think it should be a good algorithm. As
per
my observation, these are the issues with the algorithm:
1. Private Key system , thus lacks some attractive properties of a public
key encryption system
2. Since there are no complex operations involved, you can increase the
key
size as required to make brute force attacks impractical, but you
don't need
such a large key as in case of actual OTP
3. It should be easily broken if the same key is used again, as in case of
OTP.
But can some one explain how exactly an OTP becomes venerable when a
key is repeated?
Thanks,
Siva
--
************************************************************
Siva Prasad Gummadi
Motorola India Electronics Ltd.
No 33A, Ulsoor Road,
Bangalore - 560042
Phone No: 5598615-4007
email id: [EMAIL PROTECTED]
************************************************************
[x] General Information
[ ] Motorola Internal Use only
[ ] Motorola Confidential Proprietary
************************************************************
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm
Date: Tue, 08 May 2001 20:44:06 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Joseph Ashwood) wrote in <envXT2m0AHA.274@cpmsnbbsa07>:
>
> >There are no known usable flaws in Rijndael/AES. The NSA did not choose
> >Rijndael to be AES, NIST did. This is an important distintion because
> >NIST is in charge of setting requirements for government agencies, NSA
> >is in charge of brutalizing the security of all other countries and
>
> Actually when it comes to crypto the NSA has the final word.
What basis do you have for this claim?
> >supplying ciphers to us (meaning the US) that are not subject to
> >brutality. The relatively short key in Rijndael is also not an issue,
> >simply do the math.
>
> The ciphers the NSA uses for the government are not open for
> us to view. There is no reason to believe that Rijndael is any
> where close to the secret ciphers the NSA uses. Rijndael will
> only be implimented in modes the NSA can safely break. If it was
> otherwise the NSA has failed its main job. And that is to keep
> tabs on everything.
Again what is your basis for this claim too?
> >You have in front of you a machine that can do certainly no more than 2
> >billion additions per second. Let's say that it only takes one addition
> >to encrypt with Rijndael (which it doesn't it actually takes much more),
> >that means that 32-bit crypto can be broken in 2 seconds, 64-bit in 8
> >billion seconds. But even with 1 billion billion of these machine
> >working 24 hours a day it would take 20,000 years to break 128-bit
> >cryptography. To break 256-bit cryptography with 1 billiob billion
> >billion billion of those machines would take 400,000,000 years. I don't
> >believe the short key is a major issue.
> >
>
> Again you use the approach that the NSA are fools. Even versions of
> the Naval Engima had far more then 256 bit key. Hell by your defination
> a ceaser cipher of the ascii character set is safe since the number
> of keys 256! much much longer than your punny AES of 256 bits.
Yes a 1683 bit key is much longer then a 256-bit one. You're missing the
key (excuse the pun) point here. Brute forcing a 256-bit keyspace is not
even possible with currently existing computers (not enough energy in the
universe plays a big role in this inability).
> The point is be limiting it to 256 bits you limit the complexity
> of the resultion encryption.
That is meaningless. Resolution refers to accuracy of sampling. How can
you resolve data in a block cipher?
> However that said I think one can foil the NSA by at least not
> using weak modes and by using fully bijective versions of Rijndael
> such as Matts BICOM. Instead of versions that will help the NSA
> breaking system. One should never have a sytem where is possible that
> one key is the only one that works. In Matts system at least all of
> the keys point to a potinally file.
Again what is your basis for this either? You have posted this BICOM stuff
about 1000 times and have yet to actually prove any of your claims. You
will most likely just insult me for this post. But each time I respond to
your posts there is a lower chance anyone will take you seriously. It's a
proactive killfile mechanism.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: GF(2^W) sboxes timings
Date: Tue, 08 May 2001 20:45:28 GMT
"Phil Carmody" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tim Olson wrote:
> > On deeply-pipelined processors like Athlon and Pentium-III, the
> > if-then-else tests in the middle of the loop are going to cause a lot of
> > branch mispredictions with large mispredict penalties. You might be
able
> > to speed up the loop quite a bit if you do the following trick to get
rid
> > of the conditional branches:
> >
> > unsigned long gf_mul(unsigned long a, unsigned long b)
> > {
> > unsigned long result = 0;
> > long signB, lsbA;
> >
> > while (a) {
> > lsbA = ((long)a << 31) >> 31;
> > result ^= (b & lsbA);
> > a >>= 1;
> > signB = (long)b >> 31;
> > b = (b << 1) ^ (0xd59c382dul & signB);
> > }
> > }
>
> Beware the barrel shift problem that some processors have (e.g. P4)
> lsbA = ((long)a << 31) >> 31;
> can become
> lsbA = ~((a&1)-1);
>
> The '&' extracts the lowest bit, the -1 gives you all ones, or all
> zeros, but the wrong way round, hence the ~.
>
> Some processors have a ANDNOT, which would mean that you can ditch the
> '~' above and just do
> result ^= (b &~ not_lsbA);
>
> However, some processors have conditional moves and
> maybeB = (a&1) : b : 0;
> result ^= maybeB;
> could be in fact fastest.
>
> On x86 family (PPro and beyond) the conditional move will need to be
> prefixed with a test of the lowest bit of a. However, on the Alpha
> family (and maybe others) there's a conditional move on 'oddness'.
>
> If you know you're on a modern processor, and your compiler can handle
> it, I'd go for the conditional move. However, this is simply gut feel.
> Tom, please report back any findings if you try this out.
Sure in fact this is very insightful. I never really thought about it this
way. I know the original reply sped it up by quite a bit.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best encrypting algoritme
Date: Tue, 08 May 2001 20:46:37 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Mark Wooding) wrote in
<[EMAIL PROTECTED]>:
>
> >wtshaw <[EMAIL PROTECTED]> wrote:
> >
> >> When Rijndael is combined with a chaining mode, it is no longer
> >> Rijndael. To measure the strength of an algorithm means no window
> >> dressing should be fudged into the process.
> >
> >But we know how to measure the strength of a chaining mode relative to
> >the strength of the underlying block cipher. See, for example, `A
> >Concrete Security Treatment of Symmetric Encryption: Analysis of the DES
> >Modes of Operation', by Bellare, Desay, Jokipii and Rogaway.
>
> Actually we don't even now how to measure the strength of the
> underlying algorithm without the chaining.
> One can make assumptions about changes in strength but one can
> never be sure. In most encryption modes you can undo the chainning
> so that you end up with a set of singly encrypted blocks. The number
> of such blocks could depend on the type of message being encrypted.
> One would want to minimized repeated blocks. With most chainging or
> compression before encryption you make the chance of repeated blocks
> less. The hope is either you hide the underlying blocks all together
> something seldom done. Or you make it so the underlying blocks appear
> to be random. Then one hopes that the attacker doesn't use the information
> in such a way that a few sets of blocks provide a complete break.
> For things like Rijndeal you may only need 256 pairs of plaintext
> cipher text blocks to calulate a break. How one calulates is not something
> I know how to do. But from the number of unknows it seems quite possible.
> Since moslty likely only one such key would map all 256 pairs. again you
> may need a few more. As when solving normal algebric equations. N
equations
> n unknows. IF they are all independent. If not grab a few more. The point
> is the infor to break is in a small number of blocks. That is why
> if you want to hide the blocks as much as possible.
>
> If I was to use Rijndael and wanted to hide the blocks
> using 3AES as means of doing it I would use three passes of BICOM
> reversing file before and after middle pass. The ouput would
> be bijective "all or nothing encryption". And I don't see
> how an attacker can get any input out blocks of data to plug
> in to an NSA computer that may spit out the key.
I could write a program to brute force this. (ignoring time complexities)
It makes sense to be warry. Assume the NSA can break it,
> even it they can't. How can one hide all data pairs so that
> a few can't be graped and put in such a machine. They may even
> be able to crack it if they can know relationship between the
> blocks. Such weak forms of counter modes. In the game of crypto
> its always best to assume the enemy is slightly smaerter than
> you are.
You're a loon.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: ECC question
Date: Tue, 08 May 2001 20:47:52 GMT
"Mike Rosing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> > I started reading the ECC section in Koblitz's book. It's a bit
complicated
> > for a light read... I saw he mentions different curves for different
chars
> > (p=2,3,>3) is that because they wouldn't exist or because they are weak?
>
> It's more complicated than that. There's a thing called the "j-invariant"
which
> can be computed for every curve. It's got a factor of 12^3 = 2^6*3^3. If
you
> don't change the form of the curve for characteristics 2 and 3, that'd
leave
> you a zero j-invariant for all curves ('cause of the mod operation). By
changing
> the form of the curve, you eliminate the 2's and 3's so you can get back
to
> a reasonable equation.
>
> Keep reading :-)
>
Ack my brain exploded!!!!
BTW why is it called the "j" invariant?
Tom
------------------------------
From: [EMAIL PROTECTED] (Harshal Chhaya)
Subject: Optimizing AES throughput
Date: Tue, 08 May 2001 20:48:03 GMT
Hello,
The Rijndael document mentions a throughput of 70 Mbps on a 200 MHz
Pentium Pro. This was using Brian Gladman's implementation in C.
BTW, thanks Brian for the code.
I would assume that an optimized assembly implementation might result
in higher throughput. Am I correct here?
Does anyone have throughput numbers on a hardware implementation of
AES?
Thanks,
Harshal
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Optimizing AES throughput
Date: Tue, 08 May 2001 20:53:07 GMT
"Harshal Chhaya" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Hello,
>
> The Rijndael document mentions a throughput of 70 Mbps on a 200 MHz
> Pentium Pro. This was using Brian Gladman's implementation in C.
>
> BTW, thanks Brian for the code.
Yeah Brian is a cool dude.
> I would assume that an optimized assembly implementation might result
> in higher throughput. Am I correct here?
Probably a little faster.
> Does anyone have throughput numbers on a hardware implementation of
> AES?
No offense.... but USE A BLOODY SEARCH ENGINE.
Look up "+nist +aes +rijndael" in yahoo.
Tom
------------------------------
** 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
******************************
