Cryptography-Digest Digest #506, Volume #13 Sat, 20 Jan 01 11:13:01 EST
Contents:
Re: AES sbox generating code. ("Brian Gladman")
Re: Kooks (was: NSA and Linux Security) (Richard Heathfield)
Re: Differential Analysis (Tom St Denis)
Re: File Transfer with Rijndael (Tom St Denis)
Re: try this out, it looks cool (Tom St Denis)
Re: 32768-bit cryptography (Paul Schlyter)
Re: brute force and Moore's law (was Re: 32768-bit cryptography) (Paul Schlyter)
Re: 32768-bit cryptography (Tom St Denis)
Re: Differential Analysis (Richard Heathfield)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: 32768-bit cryptography (Richard John Cavell)
Re: using AES finalists in series? ("Gary Watson")
Re: Kooks (was: NSA and Linux Security) (digiboy | marcus)
Re: brute force and Moore's law (was Re: 32768-bit cryptography) (digiboy | marcus)
Re: 32768-bit cryptography (digiboy | marcus)
----------------------------------------------------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: AES sbox generating code.
Date: Sat, 20 Jan 2001 11:57:52 -0000
"Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Ok, I now fixed that:
>
>
> unsigned char AES_sbox[256], AES_sibox[256];
>
> void AES_setup() {
> unsigned char pow[256], log[256];
> unsigned char i = 0, j = 1;
> do { log[pow[i] = j] = i;
> // The above line does pow[i] = 3**i % 0x11b
> // and of course it's inverse.
> j ^= (j << 1) ^ ((j & 0x80) ? 0x11b : 0);
> // The above line does j = j * 3 % 0x11b
> } while( ++i );
> do { unsigned char k;
> j = i ? pow[255 - log[i]] : 0;
> // j is now 3**(-i) % 0x11b
> k = ((j >> 7) | (j << 1)) ^ ((j >> 6) | (j << 2));
> j ^= 0x63 ^ k ^ ((k >> 6) | (k << 2));
> // j now is an affine transform of what it was.
> AES_sibox[AES_sbox[i] = j] = i;
> } while( ++i );
> }
>
> I'm especially proud of the do {} while(++i) construct, with i being an
> 8 bit value.
In fact there is a hack in my code that requires the first loop to terminate
after element 255 but this loop should really terminate one iteration
earlier. This might cause problems in some uses of the tables since it sets
log[1] = 255, which is correct, but a 0 value might be expected in some
code.
This is one of several aspects of this subroutine that I should really
change to make the code less obscure. I might get round to this in the next
update.
Brian Gladman
------------------------------
Date: Sat, 20 Jan 2001 13:11:44 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Kooks (was: NSA and Linux Security)
Greggy wrote:
>
> In article <[EMAIL PROTECTED]>,
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > Greggy wrote:
> >
> > > - I rely on God for help.
> >
> > Perhaps you missed the sci. part of sci.crypt.
> > God help you.
>
> He does all the time.
>
> He healed my broken foot one day - within seconds.
>
> He healed my wife's body so she could carry our son to term.
>
> He healed my daughter.
>
> He healed my son's lungs of fluid in a matter of seconds.
>
> And the list is nearly endless...
>
> The power of God is real and working in my life. Far be it from me to
> try to convince you of him through wise speech. I prefer that the
> power of God demonstrate for all to see and hear about. That is the
> best testimony, for those that want help will be drawn like a magnet
> and will eventually find the help they seek. Those that don't want
> help, no one can help, not even God.
On behalf of intelligent Christians all over Usenet, I would like to
point out that an idea should not be held responsible for the people who
believe in it.
Can we get back to discussing cryptology, please? This thread is getting
Pythonesquely silly.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Differential Analysis
Date: Sat, 20 Jan 2001 13:10:13 GMT
In article <[EMAIL PROTECTED]>,
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> I consider the fact that I can write a short function to generate it to
> be of greater importance. Remember how, when DES came out, people
> asked, where the heck do these sboxes come from? I don't want this.
> Even if I say, they came from this here sboxgen program, people might be
> inclined to disbelieve me, because they won't be able to produce those
> exact sboxes from sboxgen, since they were, after all, randomly
> produced.
Actually this is a lie. If you save your prng.dat before starting (sboxgen
saves it when it exits) others can exactly reproduce what you did.
Stop lying! Liar!!!
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: File Transfer with Rijndael
Date: Sat, 20 Jan 2001 13:12:17 GMT
In article <94arei$eq1$[EMAIL PROTECTED]>,
"Marcin" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'm working on a way to securely transfer files over on insecure medium.
> One of the ways I'm considering is to pass the file through a stream that
> would create an encrypted file like so:
>
> 1st - 4th byte : total number of blocks (16 bytes each)
> 5th byte : number of bytes used in the last block
> 6th - 21st byte : message digest MD5
> 22nd - X : the file data
> X - Y : random padding to make Y equally divisible by 16
> Then symetrically encrypt each block with Rijndael in CBC mode, both sides
> already share the encryption key. This resulting encrypted 'file' can be
> streamed to the recipient.
>
> The number of blocks is for convenience to make the protocol simpler, so
> when a bunch of data is coming, it knows right away how much more to expect.
> The message digest is purely for error detection, and the random padding is
> only used to make the data fit into integral number of cipher blocks. Can
> anyone see a problem with this method? I'm easily exposing the first 5
> source bytes of the encrypted block, but with Rijndael, knowing the source
> bytes doesn't help the potential attacker. Am I right here?
>
> Thanks,
> Marcin
>
> ps. Thanks Benjamin for suggesting SHA256, is there a free Java source
> available somewhere?
I have free C source if that helps... probably not.
BTW are you using a TCP or UDP protocol? Because if packets are received out
of order you may not want to use a CBC mode of encryption. Personally I
would use a binary counter method where the binary counter is derived from
the packet number. Much simpler and just as secure.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: try this out, it looks cool
Date: Sat, 20 Jan 2001 13:13:42 GMT
In article <3D1a6.403$[EMAIL PROTECTED]>,
"John Wang" <[EMAIL PROTECTED]> wrote:
> Hi, folks,
>
> I just downloaded a new email encryption/decryption software called
> Ensuredmail. It has plug-ins for Outlook, Outlookexpress, AOL and be-based
> mails. 3DES is used. However, hex digit is not used. It works perfectly for
> me.
> Try it out, http://www.ensuredmail.com/download.asp?p=5
Thanks for the SPAM loser boy. Let's quote the page.
---
Prevents -- recipients from forwarding your sensitive information
---
And how on earth can it do that?
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: 32768-bit cryptography
Date: 20 Jan 2001 13:26:38 +0100
In article <[EMAIL PROTECTED]>,
> On Fri, 19 Jan 2001, Paul Pires wrote:
>
>> 1024 bit cryptography (If you are talking symmetric) will never be broken
>
> Pfffft!
>
> Computing power doubles every 18 months or so. Brute force is all you
> need if you have enough power. Within your lifetime, 3xDES will be
> completely crackable.
Lemme see here -- 1xDES is barely crackable now (it can be done on
custom-built hardware for perhaps $100,000 which is allowed to run
for a few days on each brute-force key search). If computing power
doubles every 18 months, then 3xDES will be equally crackable in
56*18/12 = 84 years. I'm 51 years now, so by then I'll be 135
years... <g>
Someone who now is 16 years now will be 100 years in 84 years. Not
very many people live until they are 100 years.... <double g>
And anyone younger than 16 years probably don't know much about
encryption at all....
Finally: is it reasonable to assume computing power will continue to
double every 18 months also for the next 84 years? We are fast
approaching the physical limits of microelectronics, so unless there
will be a breakthough in e.g. quantum computing, Moore's law won't
hold that long.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: brute force and Moore's law (was Re: 32768-bit cryptography)
Date: 20 Jan 2001 13:27:13 +0100
In article <[EMAIL PROTECTED]>,
Eric Smith <[EMAIL PROTECTED]> wrote:
> Richard John Cavell <[EMAIL PROTECTED]> writes:
> > Computing power doubles every 18 months or so. Brute force is all you
> > need if you have enough power. Within your lifetime, 3xDES will be
> > completely crackable.
>
> Assuming that:
>
> 1) your "doubles every 18 months or so" holds true for more than another
> century
Not quite -- it need only hold true for another 84 years: 56*18/12 = 84
> 2) 56-bit DES is brute-force crackable now
It is -- on custom-built hardware for perhaps $100,000 a DES key can
be brute-force searched in a few days or so.
> One can conclude that 168-bit triple DES will be brute-force crackable
> in about 168 years (112 more bits x 18 months / 12 months/year).
Most 3DES implementations use only 112-bit keys so there are only 56
more bits. There are good reasons for this: a 168-bit 3DES key isn't
that much more secure than a 112-bit 3DES key, so if you're
using a 168-bit 3DES key, the key length can be reduced before you
have to resort to brute-force search of the key.
> Perhaps more than 56 bits can reasonably be brute-forced today. If
> it's 80 bits today, 168 bits will only take another 132 years.
>
> Much though I like to be optimistic, I don't think it likely that I'll
> be around that much longer.
>
> I'm doubtful that doubling every 18 months can continue for more than
> another century. Ray Kurzweil in _The Age of Spiritual Machines_
> demonstrates that Moore's Law can actually be extrapolated back to
> mechanical computing devices reasonably well, and he claims that the
> approaching limits of semiconductor lithography are unlikely to have
> much effect on it for quite a few years. However, unless we discover
> ways to take advantage of sub-quantum effects or some other *really*
> amazing breakthrough (not just your run-of-the mill breakthroughs), it
> doesn't look like there can *possibly* be 26 orders of magnitude of
> improvement (for equivalent cost or size).
I fully agree with you here. It's too easy to extrapolate
optimistically from the current situation. In the 1970'ies, too many
people were convinced that nowadays tourist trips to the Moon would
be common.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: 32768-bit cryptography
Date: Sat, 20 Jan 2001 13:20:46 GMT
In article <94aqn0$qrs$[EMAIL PROTECTED]>,
"lemaymd" <[EMAIL PROTECTED]> wrote:
> 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!
Wow you suck big time.
1. Slow algorithm. My ASM copy of RC5 encrypted at 89 cycles per block on
my 800mhz Athlon **or** about 68MB/sec. Even with file io overhead it's
faster. 2. Unpublised algorithm. You made it up, are you a academic
cryptographer? 3. Section 3 of your description. And I quote "Encryption
using the Bermuda Triangle Extra Strength 1.0 algorithm consists of four
simple steps involving three key mutations.� 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."
However, the diagram to the left shows "8-bit plaintext". You never work on
the entire block at once. You just perform file i/o in 32768-bit chunks.
That's not the same thing.
Also what makes you think xor-rotate-add-xor is a complicated chain to break?
It's very linear, weak to differential cryptanalysis and generally not that
secure.
On an 8-bit block you must perform an xor-rotate chain 11.79 times to make it
secure against differential attacks.
Not only is it pure snake oil, but the algorithm isn't secure either. BTW
For a file crypto util if it's over 10kb in size it's too big.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Sat, 20 Jan 2001 13:26:04 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Differential Analysis
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> > I consider the fact that I can write a short function to generate it to
> > be of greater importance. Remember how, when DES came out, people
> > asked, where the heck do these sboxes come from? I don't want this.
> > Even if I say, they came from this here sboxgen program, people might be
> > inclined to disbelieve me, because they won't be able to produce those
> > exact sboxes from sboxgen, since they were, after all, randomly
> > produced.
>
> Actually this is a lie.
It can only be a lie if Benjamin deliberately gave false information. He
might genuinely dispute the facts, or he might have made a mistake, and
in neither case can he legitimately be called a liar.
> If you save your prng.dat before starting (sboxgen
> saves it when it exits) others can exactly reproduce what you did.
>
> Stop lying! Liar!!!
I never thought I'd have to do this, Tom, but...
*PLONK*
Perhaps I'll let you out of my killfile in a month or two, when you've
calmed down a bit.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sat, 20 Jan 2001 13:31:09 GMT
On Sat, 20 Jan 2001 07:01:28 GMT, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote, in part:
>Where'd this name come from? That's not me. And I don't see how my
>name, "Benjamin" could be mispelled or confused with "Emmanual," which
>probably doesn't even belong to any poster here on sci.crypt.
Sorry, a Freudian slip.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Richard John Cavell <[EMAIL PROTECTED]>
Subject: Re: 32768-bit cryptography
Date: Sun, 21 Jan 2001 00:51:10 +1100
On 20 Jan 2001, Paul Schlyter wrote:
> Finally: is it reasonable to assume computing power will continue to
> double every 18 months also for the next 84 years?
Yeah, I think so. The technology researchers will probably come up with
new stuff at the same rate, but the industry itself is expanding evermore.
There will be more people working on processors each year, not the same
number.
Optical transmission of information is already standard on domestic
electronics, and Playstation 2's bus bandwidths, etc, are a mile in front
of the PC. There's plenty of next-generation technology still in its
infancy.
And if you can't get any more out of a serial processor, simply employ
parallelism. That's how they beat Kasparov.
=============================================================
Richard Cavell - [EMAIL PROTECTED]
Newsgroups - Please keep any discussion on the group, and copy your
replies to me via email. (Server problems). Sending me bulk email
guarantees a nasty response.
Judge Thomas Penfield Jackson on Bill Gates: "He has a Napoleonic concept
of himself and his company, an arrogance that derives from power"
=============================================================
------------------------------
From: "Gary Watson" <[EMAIL PROTECTED]>
Subject: Re: using AES finalists in series?
Date: Sat, 20 Jan 2001 15:11:14 -0000
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Bryan Olson wrote:
> > Yes, the series of all five finalists together should be at
> > least as secure as any one. Yes, it probably has a lower risk
> > of cryptologic failure. A five hundred cipher chain should be
> > safer still.
>
> It should be noted that according to Kerchhoff's principle,
> no matter how many components are chained together the
> enemy should be assumed to know all about that. As usual,
> all the keying material together constitutes the message
> key. If you want to use a particular number of key bits,
> e.g. 128, then the question you ought to be asking is what
> is the most effective way to use them? Dividing them
> among several factor stages is certainly not it.
======= Hypothetical Example ============
Let's say that I am Director of Information Services for Islamic Jihad, and
the head mullah has assigned me to set up a secure videoconferencing link
from our headquarters in Damascus, to our field commands in Beirut and
Bagdad, and to our terrorist cells in Tel Aviv, New York, Tokyo and the city
where Tom St. D lives. We have access to lots of money, computer
scientists, and electronic engineers, but don't necessarily have a crippie
we can trust. After following AES for the last two years, we assess the
possibility that the proposers of each algorithm are shills for NSA at about
5%, and 10% for Rijndael since it was actually chosen by NIST. We assess
the liklihood that NSA can break one of these algorithms if it was developed
in good faith at 0% as long as we are careful about keying data and Tempest
attacks. The main threats to our cryptonet are NSA, Mossad, GCHQ, the
French, and to a lesser extent host countries like Syria, Iraq, and Saudi
Arabia. These are serious people but they can't brute force a 256 bit
keyspace. We have to assume that our TCP/IP traffic will be intercepted by
all major spy agencies. So what are the Chosen Faithful to do?
If we decide to use Rijndael there is, by our rekoning, a 10% chance that
one night we are going to be captured and spirited away to a Mossad torture
cell and subjected to very very loud Boyzone music for the rest of our days.
Though it's only one chance in ten, such a gruesome fate is simply
unthinkable.
On the other hand, using a pair of high-end Xilinx FPGAs, it's possible to
put all five AES finalists in series, pipelining them such that there is no
loss of throughput in a streaming video application. The Great Satan has
thoughtfully published the VHDL for all five finalists, so the R&D cycle
would be negligible. Using a static RAM based FPGA has the advantage that
it can be quickly zeroized if capture seems imminent or it could even
zeroize itself after a set period of time.
So, if the above guesstimates of the liklihood of the candidates being
deliberately and covertly weakened are accurate, and assuming that separate
randomly generated keying data were used for each cipher, the probablility
that all five systems are compromised and thus of the eternal Boyzone
torture, is the product of the probabilities or 1 in 1.6 million, which
frightening though it is, is within reason.
(I know that I'm glossing over whether these probabilities are independent,
but this could cut both ways and besides maybe I'm hoping to be promoted to
head mullah before anyone notices.)
============ End of Hypothetical Example ============
You people are the real experts in this topic, not I, but isn't this a
reasonable way to look at the strength of the ciphers? If only one of the
five ciphers is secure, then the product of the five is necessarily secure
given separate random keying data, right? Even if it turned out that one
cipher was the inverse of the other, as one previous poster had suggested as
a counterexample, using separate random keying data would negate this
weakness, would it not?
Assuming all of the above is correct, another question I'm not competent to
answer is how strong this cipher chain would be -- with each cipher at 256
bits, is it on the order of (2^256)^5, or is it closer to (2^256) * 5 ?
As you point out, dividing the 1280 keying bits* into convenient "factor
stages" is bound to make an attack simpler, but is the resulting simplicity
of any practical value to the analyist? Is this like telling someone their
life is easier since they merely have to count the grains of sand on Malibu
beach instead of all of the beaches in the world?
I guess what I'm trying to say is that chaining these five unrelated ciphers
is one way to guard against an undiscovered or deliberate weakness coming to
light in one or more of them. Even if all of them have some sort of
weakness, wouldn't simply being buried in the middle of a cipher chain make
the weaknesses harder to exploit?
I know the above topics can be counter-intuitive, as I still haven't come to
grips with why double DES is only worth about 58 bits or whatever instead of
112 bits. Several people have tried to explain this to me with no
success...
* that's five times 256. I couldn't do it in my head, either.
--
Gary Watson
[EMAIL PROTECTED] (you should leave off the digit two for email)
Speaking only for myself and not the company.
------------------------------
From: digiboy | marcus <[EMAIL PROTECTED]>
Subject: Re: Kooks (was: NSA and Linux Security)
Date: Sat, 20 Jan 2001 15:11:35 GMT
In article <94al62$eh9$[EMAIL PROTECTED]>,
Greggy <[EMAIL PROTECTED]> wrote:
> What have you done?
For one minor aspect, on this thread, pointed out quite a few times that
your arguements are hypocritical. How can you cite US law as supporting
evidence when you claim the government is not to be trusted?
--
[ marcus ] [ http://www.cybergoth.cjb.net ]
[ ---- http://www.ninjakitten.net/digiboy ]
Sent via Deja.com
http://www.deja.com/
------------------------------
From: digiboy | marcus <[EMAIL PROTECTED]>
Subject: Re: brute force and Moore's law (was Re: 32768-bit cryptography)
Date: Sat, 20 Jan 2001 15:15:40 GMT
In article <94c071$fi7$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Schlyter) wrote:
> I fully agree with you here. It's too easy to extrapolate
> optimistically from the current situation. In the 1970'ies, too many
> people were convinced that nowadays tourist trips to the Moon would
> be common.
Ah, but how many people in, say, the 1940s would think getting to the
moon was possible at all?
--
[ marcus ] [ http://www.cybergoth.cjb.net ]
[ ---- http://www.ninjakitten.net/digiboy ]
Sent via Deja.com
http://www.deja.com/
------------------------------
From: digiboy | marcus <[EMAIL PROTECTED]>
Subject: Re: 32768-bit cryptography
Date: Sat, 20 Jan 2001 15:17:55 GMT
In article <[EMAIL PROTECTED]>,
"Paul Pires" <[EMAIL PROTECTED]> wrote:
> 1024 bit cryptography (If you are talking symmetric) will never be
> broken by any little green man that any offspring of yours might meet,
> no matter how far into the future you speculate.
Well perhaps not by any green men... ;p
--
[ marcus ] [ http://www.cybergoth.cjb.net ]
[ ---- http://www.ninjakitten.net/digiboy ]
Sent via Deja.com
http://www.deja.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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
