Cryptography-Digest Digest #372, Volume #10 Thu, 7 Oct 99 15:13:03 EDT
Contents:
Re: simple algorithm for hardware device? (Volker Hetzer)
Re: Help: Mobility of the Private Key within PKI (Paul Rubin)
Re: Which encryption for jpeg compressed pictures? (Samuel Paik)
Re: Perfect Shuffle Algorithm? (Jean-Jacques Quisquater)
Re: Perfect Shuffle Algorithm? (Jean-Jacques Quisquater)
Re: Block encryption with variable keys (Mok-Kong Shen)
Re: There could be *some* truth to it (Thomas Pornin)
Re: There could be *some* truth to it ([EMAIL PROTECTED])
Re: Perfect Shuffle Algorithm? (Sundial Services)
Re: Twofish and Leapfrog (Bruce Schneier)
Re: Does anyone have more information? (Francois Grieu)
Re: Help: Mobility of the Private Key within PKI (Medical Electronics Lab)
Re: There could be *some* truth to it ([EMAIL PROTECTED])
Re: Which encryption for jpeg compressed pictures? (jerome)
----------------------------------------------------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: simple algorithm for hardware device?
Date: Thu, 30 Sep 1999 10:15:17 +0200
Luigi Funes wrote:
>
> Volker Hetzer ha scritto nel messaggio
> <[EMAIL PROTECTED]>...
> >If we knew more about your problem we could probably suggest
> >another solution instead of a poor algorithm.
>
> I hope to explain better my problem with some schematics...
> (please, read it with a non-proportional character type or
> you see garbage!)
> My encrypting device is placed between a computer
> sending data, and a network controller.
> Actually the system is bidirectional and very more
> complex, but for simplicity we think it only transmitting.
> +-----+ +-----+
> | | | |
> --------+ +-----+ +-----+
> | Din +-------------+ Dout +--------------+ | |
> | 0-15 | | 0-15 | Network | | |
> |=====>| Encryptor |=====>|
> |--->--------------- - - - - -
> | | | | Controller | |
> Computer | +-------------+ +--------------+ |
> | WR| PAC| | +-----+
> | | | | | |
> |===>==============================+ +-----+
> | control bus
> --------+
This is your problem. You encrypt the data but ignore the control signals.
As with any communication encryption you should put the control signals
into the FPGA too. In there they are delayed until encryption of any particular message
is completed. Basically, your FPGA should not only do encryption but should
look like a network controller (from the Computer's perspective) and
like Computer (from a network controllers perspective).
Then the time window you refer to below ceases to matter.
Greetings!
Volkder
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Help: Mobility of the Private Key within PKI
Date: 7 Oct 1999 04:10:18 GMT
In article <7tg3u9$6bm$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>How can I enable the users to be able to encrypt and sign the data from
>any workstation within the network where PKI infrastructure is
>installed?
>
>The user needs his private key in order to encrypt or sign the data.
>However, the private keys are normally stored on either workstation
>directly (encrypted with the hash of the password) or on a smartcard.
>The smart card is not an option.
>
>It would be nice if there was some kind of private key server.
This kind of defeats the purpose of the PKI, which is to get rid of
the need for a central key repository. If you can't use smart cards,
maybe you could just let the users carry their keys on floppy discs,
assuming the workstations have floppy drives.
Why would you want such a thing, though? If the keys aren't locked
down to a particular piece of hardware, but can be retrieved with a
login and password (using a copyable floppy disc helps only slightly),
you might as well just use login and password authentication.
------------------------------
From: Samuel Paik <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,comp.graphics.algorithms,comp.compression
Subject: Re: Which encryption for jpeg compressed pictures?
Date: Wed, 06 Oct 1999 22:10:58 -0700
[EMAIL PROTECTED] wrote:
> jerome wrote:
> > On Wed, 06 Oct 1999 07:53:40 -0700, Samuel Paik wrote:
> > >One of the public key systems is about to fall out of
> > >patent (in the US at least).
> >
> > which one ?
> > RSA patent will finish in sep 2000, no ?
> Yeah, I think he is refering to RSA...
I was thinking Diffie-Helmann, which now that I check, has already
expired. But RSA will also expire in 2000.
--
Samuel S. Paik | http://www.webnexus.com/users/paik/
3D and multimedia, architecture and implementation
Solyent Green is kitniyos!
------------------------------
From: Jean-Jacques Quisquater <[EMAIL PROTECTED]>
Crossposted-To: sci.stat.math,sci.math
Subject: Re: Perfect Shuffle Algorithm?
Date: Thu, 07 Oct 1999 07:26:18 +0200
Again see
"Magic tricks, card shuffling and dynamic computer memories"
by S. Brent Morris (NSA)
MAA, 1998.
see http://www.maa.org/pubs/books/cards.html
------------------------------
From: Jean-Jacques Quisquater <[EMAIL PROTECTED]>
Crossposted-To: sci.stat.math,sci.math
Subject: Re: Perfect Shuffle Algorithm?
Date: Thu, 07 Oct 1999 07:26:50 +0200
Again see
"Magic tricks, card shuffling and dynamic computer memories"
by S. Brent Morris (NSA)
MAA, 1998.
see http://www.maa.org/pubs/books/cards.html
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Block encryption with variable keys
Date: Thu, 07 Oct 1999 09:52:03 +0200
John Savard wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>
> >Why does DES (and similar block ciphers) keep the key constant
> >and not varying from block to block?
>
> Because doing so is inherent in the *definition* of a block cipher.
>
> Varying the key would be a good idea, but would require extra setup,
> and would mean, perhaps, that the key couldn't be locked inside a
> block-cipher chip, opening things up to certain attacks.
As I indicated, one can, for example, use a PRNG to drive DES.
I was not saying that one couldn't in principle use DES as a 'part'
of something bigger or that it's design is such that it would
exclude such use. (I am simply surprised that it apparently has not
been used that way to do encryptions.) The literature mentions CBC
etc. in the use of DES but, as far as I am aware, not modification
of the key, showing that people probably either never thought of
doing that or simply like to have something that is constant (for
whatever psychological reasons). I know very little of hardware,
but I surmise that one could do key modification, say, with
ciphertext just as easily as doing CBC, so I don't yet believe
your hardware argument. Anyway, for software, use of a PRNG to
drive DES seems to me to be a very natural way of doing things.
(Compare my WEAK3-EX.)
>
> >Would sophisticated attacks
> >like differential analysis still function when the key is
> >non-constant?
>
> Differential Cryptanalysis would indeed have problems; *more*
> sophisticated attacks would be required, based on how the key was
> varied.
To put my view point more drastically, such attacks will NOT work,
because there is now no material (cf. by the way the large quantity
of materials considered necessary for such attacks on DES as it
is used with constant keys) to be operated upon to determine the
particular bit(s) of a (constant) key with such theoretically
ingenious methods.
M. K. Shen
===============================
http://home.t-online.de/
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: There could be *some* truth to it
Date: 7 Oct 1999 08:47:28 GMT
According to <[EMAIL PROTECTED]>:
> What a quantum computer does better is that instead of just performing
> one calculation at a time, it can perform an - almost unlimited -
> number of similar calculations at the same time.
And there still is the problem of setting up the initial state for such
a computer. Somebody told me that there is no known way to actually
perform this setup in less than O(N) time if N parallel calculations
must pe performed (that means, 2^n for a n-bit exhaustive search -- even
if the actual search completes in 2^{n/2} time). Could someone confirm ?
--Thomas Pornin
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: There could be *some* truth to it
Date: Thu, 07 Oct 1999 12:35:12 GMT
>There may be other algorithms that have a logarithmic gain (ie,
>the QC time grows as the logarithm of the classic time).
May? What about fourier transform, don't quantum computers perform
that with "log gain". Shor used it for factoring numbers.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Thu, 07 Oct 1999 07:55:27 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: sci.stat.math,sci.math
Subject: Re: Perfect Shuffle Algorithm?
Jean-Jacques Quisquater wrote:
>
> Again see
>
> "Magic tricks, card shuffling and dynamic computer memories"
> by S. Brent Morris (NSA)
> MAA, 1998.
>
> see http://www.maa.org/pubs/books/cards.html
The classic card-shuffling algorithm that I've seen and used does not
replicate the human technique at all, but it produces a throughly
scrambled deck instantly. In Pascal:
for n := 52 downto 2 do SwapCards(n, Random(1,n));
where "SwapCards" exchanges the position of two specified cards, and
"Random(1,n)" produces a random number in the inclusive range [1..n].
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: Twofish and Leapfrog
Date: Thu, 07 Oct 1999 15:29:07 GMT
This is from Doug Whiting:
As a member of the Twofish design team, I (Doug Whiting) wanted to
respond to a recent postings on sci.crypt about similarities between
Twofish and "Leapfrog" (from JP of Patterson Programming). I am not
trying to comment at all on whether Leapfrog is a good or bad idea:
indeed, I have far too little information (or time) to make such a
determination. However, it did not have any influence on the design
of Twofish.
The Twofish design borrowed several ideas from previous ciphers. In
each case, where it was done consciously, we openly gave credit to
the previous inventors. Most advances in the field of cryptology
come by building on the previous work of others.
In fact, I was the one who came up with the 8-bit S-box construction
in Twofish. Bruce Schneier was an important part of the team, but he
had no influence in that part of the design. Until I saw learned of
the posting last week, I had never heard of Leapfrog nor seen any of
its design elements. Thus, while there may be similarities (and I
will show below that there are very significant differences) between
this Twofish element and the Leapfrog construction, they are totally
coincidental at most.
Last week, after seeing the sci.crypt posting, I queried Bruce about
the Leapfrog paper that was sent to him several years ago. He has no
recollection of it at all. Bruce routinely receives such unsolicited
cipher descriptions, and he almost always discards them unread. This
fact is not a criticism of Leapfrog, merely as a measure of how busy
Bruce is with "paying customers". Even if he had read it, he never
told me anything about it, so it could not have influenced my design.
Further, let's look at the elements in question. Here is the equation
for an 8-bit Twofish S-box, in the 128-bit key case:
y0 = q1[q0[q0[y[2,0]] Xor L[1,0]] Xor L[0,0]]
The L[i,j] values are key material bytes that DO NOT CHANGE for a
given key. Thus, this mapping from a single byte of y2 to y0 is an
8-bit to 8-bit nonlinear mapping (S-box), fixed for a given key. In
other words, this mapping can be precomputed as a small (256-byte)
lookup table for each key. This S-box precomputation is used to
speed up certain Twofish implementations.
Now, contrast this with the Leapfrog excerpts provided:
* get the T variables
T1 = A1(p1), T2 = A2(p2), T3 = A3(p3), T4 = A4(p4)
* note the T variable order
p5 = p5 Xor A1(A1(T2 Xor T3) Xor T4)
p6 = p6 Xor A2(A2(T1 Xor T4) Xor T3)
p7 = p7 Xor A3(A3(T4 Xor T2) Xor T1)
p8 = p8 Xor A4(A4(T3 Xor T1) Xor T2)
p5 = (p5 + T1) And FF
p6 = (p6 + T2) And FF
p7 = (p7 + T3) And FF
p8 = (p8 + T4) And FF
This is a Feistel-like structure, in which p1..p4 are used to modify
p5..p8. Note that the chained table lookup in question is data
dependent, not key dependent. This is an inference I draw from the
usage, since, if p1..p4 were instead fixed key material, the equation
reduces to a simple xor/add of a key-dependent constant. Thus, the
modification to p5..p8 cannot be precomputed in any reasonably sized
table (unless 16MBytes is reasonable). The change to p5..p8 is
very linear, as is common in Feistel structures.
In other words, Leapfrog apparently uses this construction as a
diffusion mechanism. This may be a very nice idea, but it is
dramatically different construction than Twofish, which uses the S-box
and the MDS matrix for diffusion. More abstractly, Twofish uses
chained S-boxes as follows:
y = f(x,Key) // x,y are 8 bits each
while Leapfrog does
y = y ^ F(p1,p2,p3,p4). // y, p1..p4 are 8 bits each
That f and F are somewhat similar is not surprising -- block ciphers
are almost always built out of running things through S-boxes and
then combining with xor or add. SAFER+ does something very similar,
as do E2 and LOKI97. In fact, looking across rounds (as opposed
to within a round), almost every block cipher looks something like
this, including DES.
The fact is that Twofish uses 8x8 key-dependent S-boxes. The Leapfrog
construction is nothing of the sort. Key-dependent S-boxes are a
crucial design element to add security to Twofish. Chaining a fixed
S-box with key material xors is a very simple way to achieve this,
although there may be other or better methods.
In any case, as noted in the sci.crypt posting, there is no patent
involved, so Twofish is still available as a public domain cipher.
Further, since I never had access to any information about Leapfrog,
there is no possible copyright issue either.
We are happy to give credit where credit is due, but it seems like
the inventor of Leapfrog has dramatically misinterpreted both Twofish
and its design team.
Sincerely,
Doug Whiting, CTO, Hi/fn
[EMAIL PROTECTED]
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Re: Does anyone have more information?
Date: Thu, 07 Oct 1999 18:55:15 +0200
The sunday-times article is a mess. As far as I understand it's
a mixup of three things:
- There are ongoing efforts to build quantum computer that could
do anything usefull. For now, a major research goal is to find
ways a quantum computer corrects a significant fraction of it's
own errors.
- Reputable professor Shamir from The Weizmann Institute of
Science (he is the S in RSA) has announced the theoretical
design of an optical device called Twinkle that could, if it was
built, help break a 512 bit RSA system in less time than was
possible before [but still nowhere near 1 second or 13 microseconds
at cited, first because Twinkle is not fast enough, second because
there is more to a solution than what the Twinkle device performs].
It should be noted that the Twinkle device is no more a quantum
computer than a candle is a fusion reactor. Also, one 512 bit
RSA key has already been broken by normal computers earlier
this year.
- A self-proclaimed "European Institute of Quantum Computing" has
opened a web site at <http://www.eiqc.org>. It is an obvious joke.
No member is listed, except "Dr Brian Oakley, EIQC Life President".
There is a "Brian Oakley" page at <http://quantum.phy.okstate.edu/>
greeting you with an anoying butthead sound; the guy is picturing
himself as a student at the "Oklahoma State University in Physics",
"interested in computer games, including Command & Conquer, Quake,
and the upcoming Red Alert and X-Wing vs. Tie Fighter."
I failed to find any scientific publication by Brian Oakley,
or even on quantum physic from the Oklahoma State University.
Liers, damned liers, and sunday-times journalists.
Francois Grieu
reference (two-liner)
<http://www.sunday-times.co.uk/news/pages/tim/99/09/29/timintint02001.html?1341861>
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Help: Mobility of the Private Key within PKI
Date: Thu, 07 Oct 1999 11:41:53 -0500
[EMAIL PROTECTED] wrote:
> It would be nice if there was some kind of private key server.
> The user would login through an application that runs on the
> workstation. The application would request user's private key from the
> server. The server would send that private key. Even though the private
> keys are stored on the server only the private key owner can utilize the
> key since the server store the keys in the encrypted fashion:
> TripleDes(hash(user_password),PrivateKey).
> Since only the key owner knows the password the key can only be used by
> the owner.
>
> Do such scenarios currently exist?
> If not then what are the common solutions to the situations where the
> enterprise has a PKI which does not restrict the users to their
> workstations?
Why do the private keys need to be stored anywhere but in
the users head? If you use the hash of a pass phrase as the
private key, then only the terminal the user has access to
needs to be secure. This is easily done using an elliptic
curve PK system since the private key can be anything.
The private key can be verified from the public key, so making
the public key non-changeable except under specific conditions
is the next level of security. And you need that for any
system like this.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: There could be *some* truth to it
Date: Thu, 07 Oct 1999 16:51:20 GMT
In article <7ti41j$j9r$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
>
> >There may be other algorithms that have a logarithmic gain (ie,
> >the QC time grows as the logarithm of the classic time).
> May? What about fourier transform, don't quantum computers perform
> that with "log gain". Shor used it for factoring numbers.
>
Light passing through an ordinary convex lense, prism or a pinhole
is Fourier transformed, which is "calculated" for a number
of photons (the beam intensity) that is not so powerful
as to burn out the optical components. Modern pulse lasers easily
burn through pinholes of spatial (optical parametric) filters.
One problem seems as someone else has already pointed out, to encode
a large number of initial states with a resolution that
justifies the expense, in a reasonable amount of
time, and with sufficient error checking. Computational holography
seems to give a good reference point for how involved that might be.
http://focus.aps.org/v4/st17.html
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (jerome)
Crossposted-To: comp.security.misc,comp.graphics.algorithms,comp.compression
Subject: Re: Which encryption for jpeg compressed pictures?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 07 Oct 1999 17:04:29 GMT
On Wed, 06 Oct 1999 14:46:38 GMT, John Savard wrote:
>
>>1. absolutely secure. If you have the original and the
>> encrypted file, it must be impossible to proof, if
>> one is the encrypted version of the other.
>
>I wonder why that particular criterion came to mind?
if you can proove that a given cypher text is the encrypted
version of a given plain text, you can, in theory, do a
brute force attack and find out the key. So if the key is
reused or not random, find out new plain text.
if you meet this requirement, i think you are 'absolutly secure'.
i know the only algorithm which meet it. it is One Time Pad.
but is it a requirement to reach 'absolute security' ? is it
possible to reach it without meeting this requirement ?
------------------------------
** 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
******************************
