Cryptography-Digest Digest #457, Volume #14 Sun, 27 May 01 13:13:01 EDT
Contents:
Euroean commision will recommend all citizens to use encryption in email next week,
because of echelon. (Jan Panteltje)
Re: A generic feistel cipher with hash and gf(257) mixers (Jim Steuert)
Re: A generic feistel cipher with hash and gf(257) mixers (Tom St Denis)
Re: A generic feistel cipher with hash and gf(257) mixers (Jim Steuert)
Re: A generic feistel cipher with hash and gf(257) mixers ("Tom St Denis")
Re: Help with 'P' in PKCS1V2.1 RSAES-OAEP (David Hopwood)
Re: taking your PC in for repair? WARNING: What will they (Frog2)
Re: Euroean commision will recommend all citizens to use encryption in email next
week, because of echelon. (John Savard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jan Panteltje)
Subject: Euroean commision will recommend all citizens to use encryption in email next
week, because of echelon.
Date: Sun, 27 May 2001 13:22:56 GMT
Sort of amazed me, this was leaked and I include the original message as
it reached me from NOS TV in teletext, with translation.
It seems Echelon is used by the US and GB for industrial espionage,
I suppose they (the commision) thinks that by everyone encrypting their
email Echelon will become rather useles.
Here is the message:
104 NOS-TT 104za 26 mei
(NOS teletext saturday may 26 page 104)
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
EP waarschuwt burgers voor Echelon
(European parliament warns citizens for Echelon).
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
BRUSSELBurgers en bedrijven die via
(Brussels: citizens and companies that)
e-mail of fax met elkaar communiceren,
(communicate via email or fax with each other)
moeten daarbij meer voorzichtigheid
(should do so more carefully)
betrachten.Zo kunnen ze hun berichten
(It is best for them to encrypt their messages)
het best versleutelen,om te voorkomen
(to prevent)
dat ze in handen vallen van Echelon,
(that these get into the hands of Echelon)
hetdoor de VS en Groot-Brittannie gerunde
(the secret network for industrial espionage)
geheime netwerk voor bedrijfsspionage.
(run by the US and the UK)
Dat zal de Echelon-onderzoekscommissie
(This is what the Echelon investigation committee)
van het Europees parlement binnenkort
(of the European parliament will shortly)
volgens PvdA-Europarlementarier
(recommend, according to PvdA political party member)
Wiersmaaanbevelen.Hij
(Wiersma, He)
is lid van de commissie.
(is a member of the commission).
Het is niet zo dat alles en iedereen
(It is not so that everything and everyone)
wordt afgeluisterd,zegt Wiersma."Maar
(is being monitored, says Wiersma, "But)
burgers moeten wel uitkijken met het
(citizens should really be careful in)
versturen van gevoelige informatie.
(exchanging sensitive information").
104
(page 104)
I cannot stand for the accuracty of this news report, especially as I think
encryption is not allowed in France, and GB is a member of the EEC.
So it may be a hoax.
We will have to wait and see....
One could also ask: Does Wiersma have shares in companies making encryption
software... or anyone in that committee...
or were they just testing if my keyword search program in teletext works?
hehehe
Regards
Jan
------------------------------
From: Jim Steuert <[EMAIL PROTECTED]>
Subject: Re: A generic feistel cipher with hash and gf(257) mixers
Date: Sun, 27 May 2001 09:48:32 -0400
As a matter of fact, Tom, I have. I have studied the structures of some
AES candidate ciphers, in particular, the MARS type-3 feistel structure,
and the CAST-256 algorithms. Both of these are great in that
they explain quite clearly their rationale. I've read:
"Analysis of Suitability for Pseudorandom BIST of the RC6 Cipher" by Erica
Mang
"The CAST-256 Encryption Algorithm" by Carlisle Adams
"Constructing Symmetric Ciphers Using the CAST Design Procedure" by Carlisle
Adams
"Practical S-box Design by Serge Mister and Carlisle Adams (and also your
stuff on sboxes, Tom)
"A Study on the Construction and Analysis of Substitution Boxes for Symmetric
Cryptosystems",
by Kwangjo KIM
"High Speed Mars Hardware" by Akashi Satoh, Nobuyuki Ooba, Kohji Takano,
Edward D'Avignon
Lecture Notes from QualComm: "Block Ciphers" by Greg Rose
and most importantly, the taxonomy paper:
"Unbalanced Feistel Networks and Block-Cipher Design" by Bruce Schneier and
John Kelsey
and the "how many rounds papers:"
"Comparison of Randomness Provided by Several Schemes for Block Ciphers"
by Shiho Moriai and Serge Vaudenay
In attempting to make sense of this, I have been trying to categorize these
papers into "principles",
not just features or specific implementations, but the whys. Based on that, I am
more confident
than ever that block cipher design is more a matter of glueing together these
existing principles
in creative ways. Please don't misunderstand: I am not trying to trivialize
these ideas, just to
understand them well enough to correctly apply them to additional designs. I am
still
learning. My simple cipher (why do you call it messy?) of this thread is one
example (broken at
first) of this "designers point of view". I know you've been there Tom, with
your designs. I am
more interested in the formulae or recipes, or principles of design, than in
specific designs (except
as examples of the principles).
I get most of these papers except the last. If someone could explain that in
terms I could
understand, I would be very grateful.
As for
Tom St Denis wrote:
> Jim Steuert wrote:
> >
> > Thanks David,
> >
> > I understand your proof. It is very clear. I now understand
> > meet-in-the-middle
> > attacks. I now ask whether one of these fixes is worthwhile:
> >
> > a) Use at least one more key part, and blend it in. The attack is thus
> > on =>(xor k1)=>H=>(xor k2)=>J=>(xor k3)=>K=>(xor k4)=>
> > The mitm attack would generate the set of k2(1 per k1) and
> > the set of k3(1 per k4). However, the set after J would
> > be of order k3(1 per (k1,k2)) or 2^48 And by breaking the key into
> >
> > more parts, the order could be made even higher.
> >
> > b) Re-use the parts of the key at the various stages, so that at each
> > stage i, the key itself (ki) is a 32-bit wide hash si of the
> > entire original key,
> > but xor'ed with only one of the 3 digest-width variables.
> > You had implied this in your statement "since you are only using
> > each part of the key once"... This should prevent intersections.
> >
> > While the original specification of my cipher was flawed, is there
> > anything fundamentally wrong with the methodology or recipe, given those
> > (important) fixes, to generate a reasonable cipher? I''ll rephrase the
> > methodology or recipe or class of ciphers as:
> >
> > A) Use multiple stages (at least 5) of invertible hashes H,J,K,L,M,...
> > B) Form at least 5 different derived keys d1,d2,d3,d4,d5, using
> > 5 "different" 32-bit-output compression hashes of the entire key.
> > C) After each stage, blend in a part of a derived key mixed in via
> > partial-width
> > xor (or some other invertible mixer) in. By partial width is
> > meant
> > xoring with only one out of three of the full digest
> > variable width (say, with just digest variable b out of (a,b,c)
> > ).
> > D) Shake, Stir and Serve (just kidding)
> >
> > My main point is that there can be simple recipes, this being one of the,
> > that if followed, will provide a reasonable cipher, and still provide lots
> >
> > of room for creativity. I certainly erred, and got corrected on some
> > of the recipe steps.
>
> Do you mind if I make a suggestion? Why not look at how efficient block
> ciphers are designed. You are just doing the muddle-security approach
> here. Oh you broke 3 rounds, I will add 5 more and swap this, and add
> that, and ...
>
> Even if you resist David's attack nobody will care because a) It's
> inefficient and b) It's too messy.
>
> If you read up papers say of the Rijndael or RC6 you will see how
> elegant designs are made.
>
> This is not to say you can't design your own cipher, by all means go
> ahead, but try to design a cipher you could imagine yourself actually
> using.
>
> Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: A generic feistel cipher with hash and gf(257) mixers
Date: Sun, 27 May 2001 14:09:57 GMT
Jim Steuert wrote:
>
> As a matter of fact, Tom, I have. I have studied the structures of some
> AES candidate ciphers, in particular, the MARS type-3 feistel structure,
> and the CAST-256 algorithms. Both of these are great in that
> they explain quite clearly their rationale. I've read:
>
> "Analysis of Suitability for Pseudorandom BIST of the RC6 Cipher" by Erica
> Mang
> "The CAST-256 Encryption Algorithm" by Carlisle Adams
> "Constructing Symmetric Ciphers Using the CAST Design Procedure" by Carlisle
> Adams
> "Practical S-box Design by Serge Mister and Carlisle Adams (and also your
> stuff on sboxes, Tom)
> "A Study on the Construction and Analysis of Substitution Boxes for Symmetric
> Cryptosystems",
> by Kwangjo KIM
> "High Speed Mars Hardware" by Akashi Satoh, Nobuyuki Ooba, Kohji Takano,
> Edward D'Avignon
> Lecture Notes from QualComm: "Block Ciphers" by Greg Rose
> and most importantly, the taxonomy paper:
> "Unbalanced Feistel Networks and Block-Cipher Design" by Bruce Schneier and
> John Kelsey
> and the "how many rounds papers:"
> "Comparison of Randomness Provided by Several Schemes for Block Ciphers"
> by Shiho Moriai and Serge Vaudenay
>
> In attempting to make sense of this, I have been trying to categorize these
> papers into "principles",
> not just features or specific implementations, but the whys. Based on that, I am
> more confident
> than ever that block cipher design is more a matter of glueing together these
> existing principles
> in creative ways. Please don't misunderstand: I am not trying to trivialize
> these ideas, just to
> understand them well enough to correctly apply them to additional designs. I am
> still
> learning. My simple cipher (why do you call it messy?) of this thread is one
> example (broken at
> first) of this "designers point of view". I know you've been there Tom, with
> your designs. I am
> more interested in the formulae or recipes, or principles of design, than in
> specific designs (except
> as examples of the principles).
Well some cipher designs are not particularly usefull. (not always).
MARS and CAST for example are clunky big and in the case of CAST-256
very slow. Most UFN designs are poor on desktop computers and need alot
of rounds and heterogenous structures to be secure. The only good UFN I
can think of is Skipjack because it's efficient on 8-bit cpus.
Most all-around good ciphers currently are based on BFN and SPNs. They
are relatively symmetric and hard to attack using low-diffusion based
attacks. Generally wide-trail designs seem to be the most practical and
secure. MISTY for example is a not a narrow-trail design and isn't
terribly efficient as compared to say AES. (Yes I know they are diff
block lengths).
There is more to designing a block cipher than just making it secure.
If you follow some of my designs you will see that. My earlier designs
were typically messy and vastly inefficient. Then I moved onto my newer
designs like MDFC and TC15a which were designed with speed and low
complexity in mind.
Why do I call your design messy? Well for starters you write multiple
statements per line which is typically not a good idea. Look at the
design of say RC6 and Twofish if you want simple designs.
If you want to design a new cipher either make faster more efficient
feistel bijective round functions or a new form of network completely
(i.e not feistel or spn). Just making "yet another cipher" isn't too
helpful *unless* you're intent is to break it.
Tom
------------------------------
From: Jim Steuert <[EMAIL PROTECTED]>
Subject: Re: A generic feistel cipher with hash and gf(257) mixers
Date: Sun, 27 May 2001 11:24:03 -0400
Thanks, Tom.
I'm certainly impressed by the amount of expertise you have. I too was
impressed by the elegance of RC6. I've been fairly busy and haven't looked
at your TC15a cipher, but I will now.
Perhaps you should write a paper (or book), which picks up where Scheier and
Kelsey's
paper leaves off, going more into explanations of your preferences. Like pictures to
explain
why wide-trail designs are the most practical. Or what features add security versus
slowness.
I always end up sketching the data flow (and sometimes bits) with pencil and paper
in order to help understand a cipher (William Stallings book has good diagrams,
although
it is not up to date with AES ideas). I especially liked the Erica Mang paper
"Analysis
of Suitability for Pseudorandom BIST of the RC6 Cipher" because of it's excellent
diagrams,
along with its proofs based on the diagrams. It would be great to see a book
where the basic ideas were explained diagrammatically.
Again, thanks for your help.
Tom St Denis wrote:
> Jim Steuert wrote:
> >
> > As a matter of fact, Tom, I have. I have studied the structures of some
> > AES candidate ciphers, in particular, the MARS type-3 feistel structure,
> > and the CAST-256 algorithms. Both of these are great in that
> > they explain quite clearly their rationale. I've read:
> >
> > "Analysis of Suitability for Pseudorandom BIST of the RC6 Cipher" by Erica
> > Mang
> > "The CAST-256 Encryption Algorithm" by Carlisle Adams
> > "Constructing Symmetric Ciphers Using the CAST Design Procedure" by Carlisle
> > Adams
> > "Practical S-box Design by Serge Mister and Carlisle Adams (and also your
> > stuff on sboxes, Tom)
> > "A Study on the Construction and Analysis of Substitution Boxes for Symmetric
> > Cryptosystems",
> > by Kwangjo KIM
> > "High Speed Mars Hardware" by Akashi Satoh, Nobuyuki Ooba, Kohji Takano,
> > Edward D'Avignon
> > Lecture Notes from QualComm: "Block Ciphers" by Greg Rose
> > and most importantly, the taxonomy paper:
> > "Unbalanced Feistel Networks and Block-Cipher Design" by Bruce Schneier and
> > John Kelsey
> > and the "how many rounds papers:"
> > "Comparison of Randomness Provided by Several Schemes for Block Ciphers"
> > by Shiho Moriai and Serge Vaudenay
> >
> > In attempting to make sense of this, I have been trying to categorize these
> > papers into "principles",
> > not just features or specific implementations, but the whys. Based on that, I am
> > more confident
> > than ever that block cipher design is more a matter of glueing together these
> > existing principles
> > in creative ways. Please don't misunderstand: I am not trying to trivialize
> > these ideas, just to
> > understand them well enough to correctly apply them to additional designs. I am
> > still
> > learning. My simple cipher (why do you call it messy?) of this thread is one
> > example (broken at
> > first) of this "designers point of view". I know you've been there Tom, with
> > your designs. I am
> > more interested in the formulae or recipes, or principles of design, than in
> > specific designs (except
> > as examples of the principles).
>
> Well some cipher designs are not particularly usefull. (not always).
> MARS and CAST for example are clunky big and in the case of CAST-256
> very slow. Most UFN designs are poor on desktop computers and need alot
> of rounds and heterogenous structures to be secure. The only good UFN I
> can think of is Skipjack because it's efficient on 8-bit cpus.
>
> Most all-around good ciphers currently are based on BFN and SPNs. They
> are relatively symmetric and hard to attack using low-diffusion based
> attacks. Generally wide-trail designs seem to be the most practical and
> secure. MISTY for example is a not a narrow-trail design and isn't
> terribly efficient as compared to say AES. (Yes I know they are diff
> block lengths).
>
> There is more to designing a block cipher than just making it secure.
> If you follow some of my designs you will see that. My earlier designs
> were typically messy and vastly inefficient. Then I moved onto my newer
> designs like MDFC and TC15a which were designed with speed and low
> complexity in mind.
>
> Why do I call your design messy? Well for starters you write multiple
> statements per line which is typically not a good idea. Look at the
> design of say RC6 and Twofish if you want simple designs.
>
> If you want to design a new cipher either make faster more efficient
> feistel bijective round functions or a new form of network completely
> (i.e not feistel or spn). Just making "yet another cipher" isn't too
> helpful *unless* you're intent is to break it.
>
> Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: A generic feistel cipher with hash and gf(257) mixers
Date: Sun, 27 May 2001 15:40:12 GMT
"Jim Steuert" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Thanks, Tom.
> I'm certainly impressed by the amount of expertise you have. I too was
> impressed by the elegance of RC6. I've been fairly busy and haven't looked
> at your TC15a cipher, but I will now.
"expertise"? Nah i've just read more and had more of my ciphers broken.
Fortunately I broke my last cipher (with pointers by some readers here) so I
am one step up the cryptography food-chain. :-)
> Perhaps you should write a paper (or book), which picks up where Scheier
and
> Kelsey's
> paper leaves off, going more into explanations of your preferences. Like
pictures to
> explain
> why wide-trail designs are the most practical. Or what features add
security versus
> slowness.
>
> I always end up sketching the data flow (and sometimes bits) with pencil
and paper
> in order to help understand a cipher (William Stallings book has good
diagrams,
> although
> it is not up to date with AES ideas). I especially liked the Erica Mang
paper
> "Analysis
> of Suitability for Pseudorandom BIST of the RC6 Cipher" because of it's
excellent
> diagrams,
> along with its proofs based on the diagrams. It would be great to see a
book
> where the basic ideas were explained diagrammatically.
>
> Again, thanks for your help.
No problem. I doubt I could write a book that would be deep enough
though.... Just ask questions here and we shall help :-)
Tom
------------------------------
Date: Sun, 27 May 2001 14:52:37 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Re: Help with 'P' in PKCS1V2.1 RSAES-OAEP
=====BEGIN PGP SIGNED MESSAGE=====
Sam wrote:
> Could somebody please tell me how to determine P required for
>
> PKCS1v2.1 RSAES-OAEP 9.1.1.1 Encoding operation
>
> DB=pHash||PS||01||M
P is the encoding parameters. The purpose of encoding parameters is to
associate some information with this encryption, in such a way that the
combination of the encoding parameters and plaintext is non-malleable
(see [1] if you're not familiar with the concept of non-malleability).
For example, suppose that you're using OAEP to encrypt cipher and MAC keys
in a hybrid system. The interpretation of the RSA-OAEP plaintext then depends
on which cipher and MAC algorithms are used, but the choice of those algorithms
is not secret (and it may be undesirable to encrypt them, depending on
the protocol). So, you could put an ID for those algorithms in the encoding
parameters. That would prevent some types of attack based on trying to
convince the receiver to use a different cipher or MAC than intended.
More generally, anything that is variable and affects the interpretation
of the plaintext, but is not part of the plaintext itself, is a candidate
for inclusion in the encoding parameters.
If you don't need encoding parameters, P can be the zero-length octet string.
[1] Victor Shoup,
"Why Chosen Ciphertext Security Matters,"
Research Report RZ 3076 (#93122), IBM Research, November 1998.
http://citeseer.nj.nec.com/shoup98why.html
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOxEGOzkCAxeYt5gVAQEdpAgAhspdMj2nAueL8pCu5hpK69Gidk99j4mI
DkfPYrNVVoScF4tjkjFOxpLws5PE+Lyow1CcCD25HV6hu+DfzYIGL7yicPUEl3Sz
BLEeb+2Na0tBzXavgztgeaBqOGzpaDEBgs9aew29wLRomg7tFoz3ZKoX4ybK3Nyn
8CDq6PqZ8ulaZaG3ZX6Lzi4cIIM4m7PvQLTh/SSa20tDMWnXfEcqpufzx7L9IdnX
PI4QXUtYIl5Nzkc1mOxGrsgLZejEVawuIOGZrQjetY2s5vngD8+2/3mQ94AFuebm
Hcmi8av8YJYrqNUuxkv9z/6WIfvfcATI0VNdj8w1KptQfKHbDLZrQw==
=9KFf
=====END PGP SIGNATURE=====
------------------------------
From: Frog2 <[EMAIL PROTECTED]>
Date: 27 May 2001 16:18:52 -0000
Subject: Re: taking your PC in for repair? WARNING: What will they
Crossposted-To: alt.privacy,alt.privacy.anon-server
On Sat, 26 May 2001 15:24, [EMAIL PROTECTED] (Eric Lee Green) wrote..
[snip]
>For speed, the only thing faster than C/C++ is assembly language. I
>don't think any of us are THAT masochistic!
Steve Gibson is likely to disagree ;)
The issue here is IMO not 'fastest', but 'safest'.
Could a TSR intercept I/O vectors and 'jam' a programs behaviour?
DrJohn.
--
Survival is insufficient!
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Euroean commision will recommend all citizens to use encryption in email
next week, because of echelon.
Date: Sun, 27 May 2001 16:31:16 GMT
On Sun, 27 May 2001 13:22:56 GMT, [EMAIL PROTECTED] (Jan
Panteltje) wrote, in part:
>It seems Echelon is used by the US and GB for industrial espionage,
>I suppose they (the commision) thinks that by everyone encrypting their
>email Echelon will become rather useles.
And yet there was a recent news item that said Holland was planning to
follow the same path as Britain with its R.I.P. bill.
John Savard
http://home.ecn.ab.ca/~jsavard/frhome.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
******************************
