Cryptography-Digest Digest #975, Volume #13 Thu, 22 Mar 01 20:13:01 EST
Contents:
Re: DEA standard S-tables beginner question. (Gregory G Rose)
Re: RC4 test vectors after gigabyte output?. (Gregory G Rose)
Re: Question about coding (David Formosa (aka ? the Platypus))
Verisign and Microsoft - oops (Mathew Hendry)
Re: Verisign and Microsoft - oops ("Tom St Denis")
Re: Multiple encryption, more secure ciphers (David Wagner)
Re: Multiple encryption, more secure ciphers (David Wagner)
Re: Multiple encryption, more secure ciphers ("Tom St Denis")
Re: Potential of machine translation techniques? ("Henrick Hellström")
Re: cryptography using the method of elliptic curve. ("Carpe Diem")
Re: Fill-in-the-blank codes (similar to Error-correcting codes) (Bob Harris)
Re: Pike stream cipher (Gregory G Rose)
Re: Pike stream cipher ("Tom St Denis")
Re: Multiple encryption, more secure ciphers (John Savard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: DEA standard S-tables beginner question.
Date: 22 Mar 2001 15:17:38 -0800
In article <gznu6.105481$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>> Tom, I tried looking for "boolean decomposition", but came with nothing
>> worthy. I also tried looking for "bitsliced DES" and came with nothing. Is
>> DEA a "bitsliced DES"?
I remember that Biham did the first bitslice DES
proposal, and others have since optimised the
function (particularly Matt Kwan).
I went to google, tried "biham s-box bitslice" and
the top hit was www.darkside.com.au/bitslice/ .
Start there.
Interestingly, I initially left the hyphen '-' out
of s-box, and saw no hits except Serpent related
ones.
Greg.
--
Greg Rose INTERNET: [EMAIL PROTECTED]
Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199
Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/
Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: RC4 test vectors after gigabyte output?.
Date: 22 Mar 2001 15:28:02 -0800
RC4 is a keystream generator -- that is, it
returns psuedorandom output bytes which you use to
(en|de)crypt by XORing them with the data. What
I've given below is what RC4 with the given key
will return. Yes, if you XOR that into a data
buffer that was initially all zeros, it will also
be the encrypted output.
Greg.
In article <3aba1211$[EMAIL PROTECTED]>, ajd <[EMAIL PROTECTED]> wrote:
<What are the input bytes that go with this? All zeroes?
<ajd
<
<"Gregory G Rose" <[EMAIL PROTECTED]> wrote in message
<news:99c2pg$[EMAIL PROTECTED]...
<> In article <u5C3OpCcF7b2VNiAEyPmh3csFGJy@wingate>,
<> Luis Yanes <[EMAIL PROTECTED]> wrote:
<> >There is any RC4 test vectors after gigabyte output?.
<>
<> Well, not a gigabyte.
<>
<> Initialise RC4 (or equivalent) with the 8 byte key
<> "test key". Then the first 44 output bytes are:
<>
<> unsigned char expected[] = {
<> 0xbd, 0xe9, 0x5c, 0xb5, 0x2b, 0x8d, 0xf8, 0xfb,
<> 0xf2, 0xb7, 0x51, 0xf6, 0x5b, 0xe1, 0xdf, 0x3e,
<> 0xd7, 0x4b, 0x45, 0x7a, 0xe9, 0x76, 0x4d, 0x26,
<> 0x2f, 0x43, 0xa4, 0x70, 0x9a, 0x2a, 0xc9, 0x4e,
<> 0x11, 0x23, 0x89, 0x7b, 0x02, 0x2a, 0x4f, 0x07,
<> 0x80, 0x98, 0xa1, 0xa0,
<> };
<>
<> With the same initialisation, throw away 1MB (that
<> is, 1048576 bytes) and the next 44 are:
<>
<> unsigned char meg_expected[] = {
<> 0x6b, 0x10, 0xd6, 0x79, 0xc8, 0x87, 0xa1, 0x26,
<> 0xee, 0x2d, 0x7b, 0xd6, 0xbe, 0x04, 0xbe, 0x0c,
<> 0x8f, 0x7a, 0xb3, 0xf0, 0xe0, 0xb8, 0xbd, 0xb5,
<> 0x0f, 0x0c, 0x52, 0x33, 0xae, 0x62, 0xdd, 0x9e,
<> 0x38, 0x4d, 0x03, 0xdd, 0xaf, 0x56, 0xcd, 0x07,
<> 0xb1, 0x89, 0x0c, 0x13,
<> };
<>
<>
<> As someone else pointed out, this is indeed a
<> meaningful test. An even better test (but I don't
<> have a test vector for it) is to generate some
<> output, and use that output to rekey the cipher,
<> and iterate this process a large number of times
<> (say 1000000).
<>
<> Greg.
<> --
<> Greg Rose INTERNET: [EMAIL PROTECTED]
<> Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199
<> Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/
<> Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
<
<
--
Greg Rose INTERNET: [EMAIL PROTECTED]
Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199
Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/
Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
------------------------------
From: [EMAIL PROTECTED] (David Formosa (aka ? the Platypus))
Subject: Re: Question about coding
Reply-To: [EMAIL PROTECTED]
Date: Thu, 22 Mar 2001 23:35:25 GMT
On Thu, 22 Mar 2001 17:18:11 -0400, amateur <[EMAIL PROTECTED]> wrote:
>Sample
>
>Suppose I want to encrypt
>"Iwanttoencrypt"
>I replace I by 25
> w by 26
> a by 27
> n by 28
> t by 29 etc...
>
>Every Char (i) is replaced by specific number.
>Not every kind of character
How does the system know what number corrasponds to what character?
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
------------------------------
From: Mathew Hendry <[EMAIL PROTECTED]>
Subject: Verisign and Microsoft - oops
Date: Thu, 22 Mar 2001 23:41:19 +0000
From
http://www.microsoft.com/technet/security/bulletin/MS01-017.asp
| ...
| Technical description:
| VeriSign, Inc., recently advised Microsoft that on January 29 and 30, 2001,
| it issued two VeriSign Class 3 code-signing digital certificates to an
| individual who fraudulently claimed to be a Microsoft employee. The common
| name assigned to both certificates is “Microsoft Corporation”. The ability to
| sign executable content using keys that purport to belong to Microsoft would
| clearly be advantageous to an attacker who wished to convince users to allow
| the content to run.
| ...
-- Mat.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Verisign and Microsoft - oops
Date: Thu, 22 Mar 2001 23:49:46 GMT
"Mathew Hendry" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> From
>
> http://www.microsoft.com/technet/security/bulletin/MS01-017.asp
>
> | ...
> | Technical description:
> | VeriSign, Inc., recently advised Microsoft that on January 29 and 30,
2001,
> | it issued two VeriSign Class 3 code-signing digital certificates to an
> | individual who fraudulently claimed to be a Microsoft employee. The
common
> | name assigned to both certificates is "Microsoft Corporation". The
ability to
> | sign executable content using keys that purport to belong to Microsoft
would
> | clearly be advantageous to an attacker who wished to convince users to
allow
> | the content to run.
> | ...
Can we say "duh". Which is why CA doesn't work.
Tom
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Multiple encryption, more secure ciphers
Date: 23 Mar 2001 00:11:47 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Joe H. Acker wrote:
>I've read numerous times on this group that there are enough secure
>ciphers that are relatively slow. Often, many-round Feistel ciphers are
>mentioned. But I haven't seen any references to specific descriptions of
>such ciphers.
How about Triple-DES?
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Multiple encryption, more secure ciphers
Date: 23 Mar 2001 00:13:47 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Joe H. Acker wrote:
>And in general: What would you do to create a stronger encryption when
>you have Rijndael and the final chained cipher can be around 10 times
>slower, and you may only use *one* key (but have a hash function)?
Look at Knudsen's TEMK construction.
Basically: If K is the one key you've got, let k_i = AES_K(i)
for i=1,2,..10, then encrypt your plaintext with
C = AES_{k_10}(AES_{k_9}(AES_{k_8}(...AES_{k_1}(P)...)))
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Multiple encryption, more secure ciphers
Date: Fri, 23 Mar 2001 00:25:15 GMT
"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:99e4fr$5vv$[EMAIL PROTECTED]...
> Joe H. Acker wrote:
> >And in general: What would you do to create a stronger encryption when
> >you have Rijndael and the final chained cipher can be around 10 times
> >slower, and you may only use *one* key (but have a hash function)?
>
> Look at Knudsen's TEMK construction.
>
> Basically: If K is the one key you've got, let k_i = AES_K(i)
> for i=1,2,..10, then encrypt your plaintext with
> C = AES_{k_10}(AES_{k_9}(AES_{k_8}(...AES_{k_1}(P)...)))
Isn't K[i] an example of the CTR block mode in use?
Tom
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Potential of machine translation techniques?
Date: Fri, 23 Mar 2001 01:35:07 +0100
"Richard Herring" <[EMAIL PROTECTED]> skrev i meddelandet
news:99cup3$72m$[EMAIL PROTECTED]...
> In article <98tros$rnm$[EMAIL PROTECTED]>, Henrick Hellström
([EMAIL PROTECTED]) wrote:
> > "Richard Herring" <[EMAIL PROTECTED]> skrev i meddelandet
> > news:98qruc$a96$[EMAIL PROTECTED]...
> > > EU languages form a very restricted subset of all natural
> > > languages. Apart from Finnish they are all either Germanic or
> > > Romance.
>
> > The Gaelic languages, spoken on Ireland (were Irish is an official
> > language),
>
> One of two. Does Ireland actually use Irish for any official EU business?
Yes, I certainly think so, at least in written documents, but perhaps not
during live sessions.
> > Isle of Man and in Scotland, are Celtic languages.
>
> Don't forget Welsh.
Welsh is indeed a Celtic, but AFAIK not a Gaelic language.
[snip]
> > As far as I know all documents are also translated to the languages of
the
> > two remaining EES countries (Norway and Iceland, Germanic languages), as
> > well as to the languages of the candidate countries, e.g. Estonia
(related
> > to Finnish), Poland, the Czeck Republic, Slovenia (Slavic languages),
> > Hungary (remotely related to Finnish) and Cyprus (Greek and Turkish, the
> > latter yet another non Indo European languange).
>
> And are all these languages included in the machine-translation project?
If these countries where to become members, their official languages ought
to be included. Isn't the purpose of the machine-translation project in fact
to deal with the prospect of that many languages? But I don't know for
sure...
> --
> Richard Herring | <[EMAIL PROTECTED]>
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Carpe Diem" <[EMAIL PROTECTED]>
Subject: Re: cryptography using the method of elliptic curve.
Date: Thu, 22 Mar 2001 18:37:22 -0600
Well, you can not say that it is boring. ECC has behind a wonderful
mathematical theory. The theory of elliptic curves is truly fascinating. I
can not understand on what basis you say it is boring.
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:hDsu6.108299$[EMAIL PROTECTED]...
>
> "Mauro" <[EMAIL PROTECTED]> wrote in message
> news:99dk95$ps3$[EMAIL PROTECTED]...
> > How can i find information about cryptography using the method of
elliptic
> > curve.
>
> hmm...Mike rosings book "Implementing ECC" is cool (a bit touchy though).
>
> Certicom host some tutorials...
>
> ECC is neat, efficient but very boring stuff. RSA is much simpler easier
to
> see how it works but less efficient... (DH is more secure and even less
> efficient)
>
> Tom
>
>
------------------------------
From: Bob Harris <[EMAIL PROTECTED]>
Crossposted-To: sci.math,comp.dsp
Subject: Re: Fill-in-the-blank codes (similar to Error-correcting codes)
Date: Thu, 22 Mar 2001 19:41:33 -0500
Jerry Avins wrote:
> Look at the techniques used with RAID disk arrays. These distribute data
> over several disks and can reconstruct it if one (or more) disks fail.
> Of course, _which_ fails is known. Most RAID systems can rebuild only
> one disk at a time, but the technique is extensible.
Yes, that is it exactly. The receiver knows, before it starts to decode,
which two bits are missing.
In fact, once I began searching the literature for "erasures" (as Brian
McKeever and Jyrki Lahtonen suggested), I found an abundance of exactly what
I'm looking for. For example, see the paper "EVENODD: An Optimal Scheme for
Tolerating Double Disk Failures in RAID Architectures", by Blaum, Brady,
Bruck, and Menon, 1994 or 1995 (same title seems to have been published
twice). This scheme is adaptable to my need. As are some of the others I
found.
Thanks to all who took the time to help.
Bob
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: Pike stream cipher
Date: 22 Mar 2001 16:43:24 -0800
In article <z7uu6.109284$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>"Public <Anonymous_Account>" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Does anyone have any references (or thoughts of their own they can
>> offer) concerning the security of Ross Anderson's "Pike" stream
>> cipher?
>
>AFAIK that's the one he proposed after breaking FISH right?
In other words, you don't know what the algorithm
is.
>There are simpler (more portable) stream ciphers. Consider Knuth's
>Algorithm M.
But you still claim that something else is better
and more portable?
Sigh, Tom. You are a very effective troll.
Please note that neither Knuth nor anyone else
reputable has ever claimed that Algorithm M is a
good stream cipher. There are reasons to believe
it might not be. It generates good psuedo-random
numbers though.
As for FISH, it's structure is related to A5 (the
stream cipher used in GSM phones). It has a huge
state... hundreds of 32-bit words (55+57+58 == 170
words), 5440 bits.
In case anyone is interested, here's how it works:
You have three lagged fibonacci regisers (additive
feedback registers) of mutually-coprime lengths,
updated by very simple, primitive, feedback trinomials.
The output is the mod-2^32 sum of the lead
register values. The trick is that you don't
always update all three of the registers... when
you calculate the new terms, you remember the
carry outputs, and only update the registers that
agree with the majority function of the three
carries. So at each stage, at least two, and
sometimes all three, get updated. (You can encode
this state update in two bits, with equiprobable
occurrence.)
If the key is (as Anderson states) the initial
state of the three registers, it's quite clear
that it isn't that strong. With somewhat more
than 170 words of known output, and 2^340 matrix
inversions, you can solve for the unknown state
variables and check the output to verify the
guesses. You do this by guessing the 2-bit
"state update" function, based on the majority of
the carry bits from updating the lagged fibonacci
registers, for each output word. When you have
170 linear equations in 170 unknowns, you solve
them. You'll get the wrong answer if you guessed
the update pattern wrong. Repeat until headache
goes away.
Its cycle length is also much less than that,
being a small (approximate) multiple of the cycle
of the longest register, which is 2^31(2^58 - 1)
or approximately 2^89 output words (extrapolated
from results on A5).
Lastly, lagged fibonacci registers are terribly
slow to update their state, so related key
cryptanalysis would, I think, blow it away, but
that isn't a very practical attack. This could be
solved by, for example, initialising its state
from a chained hash calculation from the real
input key.
So, it's less secure than the amount of state
information... this is true of almost all stream
ciphers. Keying it properly is no fun. I'm not
aware of a stronger attack than that above, but
I'd be surprised if there isn't at least a slight
improvement available. I don't think it's been
studied enough to be sure of its security. Once
it's running, it's very quick.
Greg.
--
Greg Rose INTERNET: [EMAIL PROTECTED]
Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199
Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/
Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Pike stream cipher
Date: Fri, 23 Mar 2001 00:58:01 GMT
"Gregory G Rose" <[EMAIL PROTECTED]> wrote in message
news:99e67c$[EMAIL PROTECTED]...
> In article <z7uu6.109284$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> >"Public <Anonymous_Account>" <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> Does anyone have any references (or thoughts of their own they can
> >> offer) concerning the security of Ross Anderson's "Pike" stream
> >> cipher?
> >
> >AFAIK that's the one he proposed after breaking FISH right?
>
> In other words, you don't know what the algorithm
> is.
Was I right or not? I don't have my applied crypto at home.
> >There are simpler (more portable) stream ciphers. Consider Knuth's
> >Algorithm M.
>
> But you still claim that something else is better
> and more portable?
>
> Sigh, Tom. You are a very effective troll.
Blow me Goat boy.
> Please note that neither Knuth nor anyone else
> reputable has ever claimed that Algorithm M is a
> good stream cipher. There are reasons to believe
> it might not be. It generates good psuedo-random
> numbers though.
Yes, but Algorithm M does randomize the order of the outputs making linear
attacks very hard. If you use two LFG's it should be ok assuming you have a
large enough delay.
Tom
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Multiple encryption, more secure ciphers
Date: Fri, 23 Mar 2001 00:49:40 GMT
On Thu, 22 Mar 2001 11:34:21 +0100, [EMAIL PROTECTED] (Joe H. Acker)
wrote, in part:
>And in general: What would you do to create a stronger encryption when
>you have Rijndael and the final chained cipher can be around 10 times
>slower, and you may only use *one* key (but have a hash function)?
One way to do it would be this:
Concatenate the key with "01", and then hash it ten times, to make
KHA1, KHA2, KHA3 ... KHA10.
Concatenate the original key with "02" instead, now, and hash it ten
times again, to make KHB1, KHB2, KHB3 ... KHB10.
Use as your 10 keys for doing Rijndael 10 times in a row:
KHA1 xor KHB10
KHA2 xor KHB9
...
KHA10 xor KHB1
Since it's easy to find hash(A) from A, but hard to find A from
hash(A), this kind of arrangement should mean that there is no way to
find any of the ten keys from any of the other ones.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
