Cryptography-Digest Digest #358, Volume #12 Fri, 4 Aug 00 13:13:01 EDT
Contents:
Re: What is the word on TC5? (stanislav shalunov)
Re: Encrypting a String to another String containing only certain (Tom Anderson)
Applications for One-Way Function? ("Ed Suominen")
Re: Square/Rijndael/Crypton S-box question (Mark Wooding)
Re: What is the word on TC5? (Mark Wooding)
Re: Digital Certificates and Key Lengths (Mark Wooding)
Re: New block cipher for the contest ("Martin 'SirDystic' Wolters")
Re: New block cipher for the contest (David A. Wagner)
Re: Seeking simple, free crypto app (Pegwit?) (Kerry L. Bonin)
Re: Square/Rijndael/Crypton S-box question (David A. Wagner)
Re: counter as IV? (David A. Wagner)
Re: Encrypting a String to another String containing only certain (Mok-Kong Shen)
Re: Cracking RC4-40 in FPGA hardware ([EMAIL PROTECTED])
Basic Question concerning digital certificates and Microsoft Outlook ("Harmonics")
Re: Applications for One-Way Function? (John Myre)
----------------------------------------------------------------------------
From: stanislav shalunov <[EMAIL PROTECTED]>
Subject: Re: What is the word on TC5?
Date: 04 Aug 2000 12:11:02 -0400
[EMAIL PROTECTED] (David A. Wagner) writes:
> Remember, each round of a Feistel function is defined by
> (L',R') := (R + F(K_i, L), L).
> The function F(K_i, .) : {0,1}^n -> {0,1}^n can be either
> bijective or non-bijective.
I wasn't fixing the subkey, thus my question. I usually view F as
F: K \times H -> H, where K is keyspace, and H is "space of halves".
Miscommunication.
--
Stanislav Shalunov Internet2
"In the future, if everyone doesn't die. Wouldn't the world blow up? Good
question." --Alex Chiu
http://www.alexchiu.com/affiliates/clickthru.cgi?id=shalunov
------------------------------
From: Tom Anderson <[EMAIL PROTECTED]>
Subject: Re: Encrypting a String to another String containing only certain
Date: Fri, 4 Aug 2000 17:14:33 +0100
On Thu, 3 Aug 2000, Dara Naraghi wrote:
> [EMAIL PROTECTED] (wtshaw) wrote:
> >
> >Be more specific as to numbers of input and output characters,
> and I will
> >check the data base of some possibles. This is more common a
> problem than
> >many realize. Fear not to give your desired best to worst
> requirements.
>
> Hmmm, funny you should mention that this is a common problem since I'm
> looking for the same thing! Here's what I'm trying to do:
>
> Input: alphanumeric string, around 12-15 characters long
>
> Desired Output: encrypted alphanumeric string which excludes
> some characters than can be easily confused (e.g. exclude
> letters S and I since they can be confused with numbers 5 and
> 1), preferable not much longer than the input string
>
> Any help or pointers to resources would be appreciated.
as has been said, the way to do this is to figure out the base of your
input, pick a base for your output and convert between them. this is
exactly how the base64 and base85 encoding schemes work; the former is,
IMHO, simpler to implement, but expands binary data by 1/3, the latter
expands by only 1/4, but is slightly trickier; it's also less well
specified. base64 is specified in RFC2045, section 6.8; see:
http://www.faqs.org/rfcs/rfc2045.html
base85 is specified in the postscript and PDF specs, and in RFC1924:
http://www.faqs.org/rfcs/rfc1924.html
the two use different codebooks (the RFCs is arguably better), the former
describes an extra compression clause and the latter does not deal with
padding or termination. if someone can find me a better reference, that
would be great!
in any case, you could use one of these but substitute your own codebooks
so that the characters in the output are as you want (ie not '5' and 'S').
if you can't find enough good characters, pick a smaller base - the info
in the base85 specs should help you figure out how to do the coding.
as for input ... if your input is characters from a restricted set, rather
than bytes, you can use the base85 decoding procedure (modified to a
suitable base) to get it into a form suitable for coding
tom
------------------------------
From: "Ed Suominen" <[EMAIL PROTECTED]>
Subject: Applications for One-Way Function?
Date: Fri, 4 Aug 2000 09:17:16 -0700
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Assume the existence of a one-way function with the following
properties:
1. For any input value in the space {0,2^N}, there is a unique but
unpredictable output value in the same space, {0,2^N}.
2. Each output value corresponds to only one possible input value (no
collisions possible).
3. It is very easy (and very fast) to compute an output value from an
input value, but computationally infeasable (e.g., 2^128
possibilities) to compute an input value from an output value.
What sort of crypto applications are there for such a function,
besides storing transformed passwords for verification against input
passwords?
Ed Suominen
Registered Patent Agent
Web Site: http://eepatents.com
PGP Public Key: http://eepatents.com/key
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.5.3
iQA/AwUBOYrsP6mKuMvNCWDGEQJQmQCfZ3LaJedvVdrLc99I2xbDi3MRJ2oAn0c9
q7oHhKUpN7HIXlve8ebUvPYm
=Q86l
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Square/Rijndael/Crypton S-box question
Date: 4 Aug 2000 16:19:38 GMT
John Myre <[EMAIL PROTECTED]> wrote:
> Mark Wooding wrote:
> [descriptions of Square and Rijndael S-boxes]
>
> Why are they different?
I've never met or talked to the designers, so this is just my personal
take on the design process. The Rijndael polynomial is sparser, which
should make implementation in hardware slightly cheaper. Also, the
affine transform has a much simpler structure.
There are a lot of slightly strange bits of Square which Rijndael fixes.
For example, in Square, you have to apply the column transform to the
round keys for *encryption*, except in the last round, which is really
rather odd. Rijndael is much more sensible in this regard.
> The Rijndael paper does have some rationale for the cipher's various
> parts. But I couldn't get from there to an answer of the question
> above. Actually, I got the impression that the choices were somewhat
> arbitrary, and therefore Rijndael and Square are different because to
> do otherwise would be boring.
I think there's rather more thought involved than that. But, yes, the
Rijndael paper does comment that, if anyone's suspicious of the S-box
(and it's sort of hard to see where you can hide a backdoor in the
current S-box spec) it can be replaced by more or less any other S-box
with reasonable differential and linear properties. It doesn't even
have to be an especially good S-box, due to the wide trail left by the
row and column transformations.
> (I wonder if I will ever get to where I can spell Rijndael
> without looking it up first. I've given up on touch-typing
> it.)
If you implement it, you start being able to type `rijndael_foo' quite
easily. (In fact, for some bizarre reason, it was the easiest thing in
this paragraph to type.) ;-)
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: What is the word on TC5?
Date: 4 Aug 2000 16:20:29 GMT
stanislav shalunov <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Mark Wooding) writes:
>
> > In a four-round Feistel network with a bijective F-function, [...]
>
> How could a function from a set of 2^{2n} elements into a set of 2^n
> elements be bijective?
That is, bijective for a given fixed key. I thought that was obvious,
but perhaps I was remiss in not stating it explicitly.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Digital Certificates and Key Lengths
Date: 4 Aug 2000 16:23:04 GMT
Kashif Hassan <[EMAIL PROTECTED]> wrote:
> Does it make sense to have a 512 CA issue 1024 certs?
Not really. It means that the 1024-bit key can be replaced by a dummy
one for the cost of factoring a 512-bit number, which is (just about)
within the realms of possibility. Once that's done, CA certs can be
forged, so the adversary can set up a man-in-the-middle attack with his
spangly new certificate.
-- [mdw]
------------------------------
From: "Martin 'SirDystic' Wolters" <[EMAIL PROTECTED]>
Subject: Re: New block cipher for the contest
Date: Fri, 4 Aug 2000 18:19:46 +0200
Could somebody tell me the URL with
the ciphers submitted to this contest?
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: New block cipher for the contest
Date: 4 Aug 2000 09:24:25 -0700
=?iso-8859-1?Q?Fierabr=E1s?= <[EMAIL PROTECTED]> wrote:
> Well, I must get deeply into your attack; as a quick overview, I'm not sure
> it is so easy find 2N+1 {u,c} pairs that provide the 2N+1 linearly
> independent equations in GF(2) needed to get out a, b, and m_0.
If you do the calculation, I think you find that a square matrix
with randomly-chosen entries has a good chance of being full rank.
But even if it isn't, you can always gather 2N+20 known texts to
obtain 2N+20 equations in 2N+1 unknowns, and _that_ system will
almost always be sufficient to recover all the information you need.
> Moreover, if such 2N+1 {u,c} pairs are found to play with the '0'-bit, do
> those pairs yield 2N+1 linearly independent equations for the '1'-bit and so
> forth?
I don't see any reason why not, but hey, even if for some obscure
reason you couldn't re-use the pairs, the data complexity only goes
up to something like N*(2N+1) ~ 2^15 known texts, which for a modern
cipher is tiny.
------------------------------
From: [EMAIL PROTECTED] (Kerry L. Bonin)
Crossposted-To: alt.security.pgp
Subject: Re: Seeking simple, free crypto app (Pegwit?)
Date: Fri, 04 Aug 2000 16:44:16 GMT
On 4 Aug 2000 07:29:16 GMT, [EMAIL PROTECTED] (Paul Rubin) wrote:
>In article <[EMAIL PROTECTED]>,
>Kerry L. Bonin <[EMAIL PROTECTED]> wrote:
>>
>>If you are building an application and are interested in secure point
>>to point communications, and Java is acceptable, I've recently
>>released a cryptographic protocol package into open source you may be
>>interested in.
>>
>>I call it [V]SPS, for VScape Secure Packet Stream, and it could best
>>be viewed as a streamlined SSL with a fixed, but strong cyphersuite.
>
>This sounds cool, but why not just use SSL? There's no requirement in
>SSL to support multiple ciphers. What concrete advantages does VSPS have?
Very valid questions.
I had originally intended to use SSL, but was unable to locate
unencumbered source in Java. I looked at available source, and while
OpenSSL is interesting and works, the source code is, uh, far from
ideal? I then looked at implementing my own, and discovered the
protocol was WAY too complicated for what was being accomplished. I
develop secure protocols for proprietary apps for a living (Cisco), so
I do feel qualified to make that determination. Schneier covered this
issue recently as well.
Since my app was proprietary, I decided to develop my own equivelant
to SSL, but simplified as much as possible. This has several
implications - simpler protocol means simpler implementation, which
means less possibility of security problems.
>And how confident are you that VSPS has no protocol errors? Remember
>that SSL 3.0 exists because SSL 2.0 had security bugs, and SSL 2.0
>existed because SSL 1.0 had security bugs, and *all* of them had been
>designed by experts and put through a peer review process before being
>released into the world. Making mistakes is very easy, and departing
>from a mature standard without a solid good reason seems like asking
>for trouble. I've only looked at your URL for about 2 minutes, but I
>don't find any of the stated reasons convincing (i.e. you make SSL sound
>worse than it is), and that the signatures on key exchange components
>are *optional* scares me.
I've given SPS to a number of people, and made it public, for review
in the hopes that anything I missed will be found fast. Since the
protocol can be roughly described in a paragraph, and spec'd out in
complete detail in a page or two, I'm pretty confident its strong.
The implementation is simple and highly documented, so reviewing that
should be easy as well.
Most of SSL's problems came from the unnecessary complexity of the
protocol and remaining ambiguities in the spec - I consider it a
classic example of "design by committe".
As for optional zero signatures, I agree. :) I've been considering
removing that option completely, it'll be disabled permanantly in the
next release. The system currently allows each side to define the
minimum number of signatures needed to allow a connection, the default
is one.
>I also believe the 36k class file is not that much smaller than, for
>example, the Cryptix Java SSL implementation, though I'm not sure
>whether that uses JCE. It certainly doesn't need to though.
Cryptix SSL does indeed require the Cryptix JCE, which means >1M of
additional code. I once produced a "stripped down" version of the JCE
for just this purpose, but it still was ~200k. Additionally, in Java
the requirement of a JCE means a very technical installl for the end
user if you want to use it in a browser, and if often does not work at
all. WIth VSPS, the 36k class file and no JCE gives you the same
features with a footprint small enough to use in applets.
>VSPS does look like a nice piece of work. I'm just not convinced
>that it's needed.
In an ideal world, I agree that SSL already fills this niche. I'm
releasing SPS primarily because I feel that it provides an alternative
that is just as secure, is small enough to be used anywhere over
nothing more than a base JRE, has the portability advantages of Java,
and releasing as open source let me take advantage of 15 CFR part 734
to loophole out of export control laws everywhere I use it, including
at work. That was good enough reason for me.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Square/Rijndael/Crypton S-box question
Date: 4 Aug 2000 09:42:22 -0700
Mark Wooding <[EMAIL PROTECTED]> wrote:
> The S-box in Rijndael is inversion in the field GF(2^8) represented as
> GF(2)[x]/(x^8 + x^4 + x^3 + x + 1), followed by the affine
> transformation
>
> [ 1 1 1 1 1 0 0 0 ] [ x_7 ] [ 0 ]
> [ 0 1 1 1 1 1 0 0 ] [ x_6 ] [ 1 ]
> [ 0 0 1 1 1 1 1 0 ] [ x_5 ] [ 1 ]
> [ 0 0 0 1 1 1 1 1 ] [ x_4 ] [ 0 ]
> [ 1 0 0 0 1 1 1 1 ] [ x_3 ] + [ 0 ]
> [ 1 1 0 0 0 1 1 1 ] [ x_2 ] [ 0 ]
> [ 1 1 1 0 0 0 1 1 ] [ x_1 ] [ 1 ]
> [ 1 1 1 1 0 0 0 1 ] [ x_0 ] [ 1 ]
>
> over GF(2).
Fascinating. You know, I'd never noticed this before, but staring at
what you posted, there seems to be a lot of regularity in that affine
transformation, doesn't there?
Example. Let M be the above matrix, * represent GF(2^8)-multiplication,
and 2 represent the element 0x02 of GF(2^8) (i.e., the polynomial "x").
Then the relation M(2*x) = 2*(Mx) holds with probability 1/4.
Does anyone else find this example a bit disconcerting? The main role
of the matrix M is to destroy the GF(2^8) structure; yet the example shows
that, due to the regularity in the matrix M, the affine transformation
leaves some considerable remnants of the GF(2^8) structure intact.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: counter as IV?
Date: 4 Aug 2000 09:45:06 -0700
Bodo Moeller <[EMAIL PROTECTED]> wrote:
> David A. Wagner <[EMAIL PROTECTED]>:
> > Using a truly random IV eliminates this vulnerability. That's why I
> > recommend to use an unpredictable, random IV, and not, e.g., a counter.
>
> Does it really have to be a *truly* random, *unpredictable* IV?
> What about applying a publicly known PRF to counter values?
Sorry for the imprecision. You are quite right to suggest that using
a PRF is just as good. There is no need for IVs to be truly random;
unpredictability suffices. I apologize for that error.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Encrypting a String to another String containing only certain
Date: Fri, 04 Aug 2000 19:05:14 +0200
Martin Claviez wrote:
>
> Can I encrypt any string to another string that is containing only certain
> characters ?
You can e.g. have a target 4-elment alphabet 'ACGT'. If you
use a group of 3 of these, you get a code of 4^3=64, i.e.
you can code 64 source alphabet symbols. If you have less
than 64, you could even have some one-to-many correspondences,
i.e. homophones. That's monoalphabetical substitution. Employing
a number of different mappings, you can have polyalphabetical
substitutions according to a key you choose. Now your ciphertext
consists all of ACGT's. If you pretend to be a biochemist and
declare that string to be a section of DNA of something (with
a weird Latin name) that you have determined, maybe it could
even escape the notice of some three lettered agencies.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cracking RC4-40 in FPGA hardware
Date: Fri, 04 Aug 2000 16:48:27 GMT
In article <WPmi5.815$[EMAIL PROTECTED]>,
"CMan" <[EMAIL PROTECTED]> wrote:
> OOPS!!!!
> I forgot to mention...while the Word Document key is truly 40 bits
> (actually 48 bits because there is some re-keying in an easy to
> guess way), but the problem is the RC4 key is actually 128 bits.
> You see, Word first takes the 40 bit (48) bit document key and
> computes a hash of this document key and uses that to schedule RC4.
>
> I believe SSL also uses an MD4/5 hash also so this same difficulty
> arises there.
>
> I don't think MD4/5 is easy to implement in hardware. (I could be
> wrong on this point!!)
It adds some more complexity but it's not fatal to the scheme.
Looking at MD5, as in http://www.freesoft.org/CIE/RFC/1321/md5c.c
each round consists of a magic constant lookup + some bit mangling
on a 32 bit subset of the 128 bit result. The initial padding
looks constant, and at the end we have 4 additions. There are
64 magic constants of 32 bits each so they can be looked up in
one cycle using a 256x16 dual port block RAM. So the basic
cycle time looks comparable and 80 cycles should be plenty.
So in hardware the hash should go at least 10 times as fast as the
RC4 step. So assuming your limiting resource is block memories
you need to devote 1/10 of your hardware to computing hashes, and
9/10 to RC4 trials.
>
> Unless the RC4 hardware and the MD4/5 hash computation run at
> approximately the same speed, the process sort of falls apart.
> The hardware will just sit there waiting for new hashes to load.
>
True, but as shown above computing hashes looks faster than RC4ing,
again assuming I didn't slip a decimal point and understand MD5
correctly.
Lou Scheffer
Lou Scheffer
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Harmonics" <[EMAIL PROTECTED]>
Subject: Basic Question concerning digital certificates and Microsoft Outlook
Date: Fri, 04 Aug 2000 17:00:25 GMT
Simple Question.
Microsoft Outlook can import a Digital Certificate and use it to encrypt or
digitally sign any emails I send, and I can get one of these certs from
Verisign, but what if I want to create a simple certificate myself? Can it
be done? How?
This is only for an experiment, I would like to use it to send and receive a
few encrypted messages, and do not need it to be a legally binding cert or
signature.
I am proficient in C/VC++/VB, any pointers on where to look for a
certificate file format? or explanation on these PKCS #7 documents, would be
much appreciated.
Thanks!
<Harmonics>
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Applications for One-Way Function?
Date: Fri, 04 Aug 2000 11:01:25 -0600
Ed Suominen wrote:
<snip>
> 1. For any input value in the space {0,2^N}, there is a unique but
> unpredictable output value in the same space, {0,2^N}.
> 2. Each output value corresponds to only one possible input value (no
> collisions possible).
> 3. It is very easy (and very fast) to compute an output value from an
> input value, but computationally infeasable (e.g., 2^128
> possibilities) to compute an input value from an output value.
<snip>
Is this what is called in the literature a "random permutation"?
JM
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
