Cryptography-Digest Digest #966, Volume #12 Fri, 20 Oct 00 22:13:01 EDT
Contents:
Hypercube structure / balanced block mixing (Benjamin Goldberg)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (jungle)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (jungle)
Re: How to post absolutely anything on the Internet anonymously (jungle)
Re: SDMI Successfully Hacked ("David C. Barber")
Re: Encrypting large blocks with Rijndael (Mok-Kong Shen)
Re: Encrypting large blocks with Rijndael (John Myre)
Re: Which "password" is best. (wtshaw)
Re: Encrypting large blocks with Rijndael (Mok-Kong Shen)
Re: Encrypting large blocks with Rijndael (John Myre)
Re: Encrypting large blocks with Rijndael (Mok-Kong Shen)
Re: Dense feedback polynomials for LFSR (Tim Tyler)
Re: What is meant by non-Linear... (Tim Tyler)
Re: On block encryption processing with intermediate permutations (Bryan Olson)
Re: Works the md5 hash also for large datafiles (4GB) ? (Bryan Olson)
Hash programs ("Archer")
Re: algo to generate permutations (Andreas Gunnarsson)
----------------------------------------------------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Hypercube structure / balanced block mixing
Date: Fri, 20 Oct 2000 19:56:41 GMT
The structure of edges in a hypercube, and the structure of mixing pairs
used in balanced block mixing are identical. I wanted to create a
cipher which used a hypercube like structure, when I noticed the
similarity, and then decided to look up ciphers which used balanced
block mixing. The one I found, TC2, uses a global static array to
specify pairs of indices. Does anyone know how to use ordinary loops
(no global data) to list the edges of an arbitrary sized hypercube?
I've tried myself (using 3 nested loops) but I can't seem to get it
right. I suspect it will require 4 nested loops, but I'm not sure how.
It might be only doable with a recusive function; I hope not.
The reason for my asking is that my expanded key is 512 bytes, and I
want to use an order-10 hypercube to do balanced block mixing in the key
schedule, and I *don't* want to have a global array containing 10*512
integer values.
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
Date: Fri, 20 Oct 2000 16:14:36 -0400
Seeker wrote:
>
> > Many modern motherboards use flash, and the battery trick doesn't work.
>
> In that case a BIOS decryptor with a boot disk could work.
could work ?
when the is no floppy drive ?
> Either way, I
> think the point is that relying on a BIOS password is far from the most
> secure solution.
why ?
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
Date: Fri, 20 Oct 2000 16:18:54 -0400
how this trick works ?
by intercepting calls to bios from o/s ?
Jonathan wrote:
>
> How about strong encrypt the whole system drive with something like safeboot
> www.controlbreak.nl or safeguard http://www.utimaco.com . With these
> utilities you can't get acces to the drive period. (even if you try ntfsdos
> or bios tricks.)
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: How to post absolutely anything on the Internet anonymously
Date: Fri, 20 Oct 2000 16:26:13 -0400
how this is better then old remailer method ?
they are asking to use proxy ...
Anthony Stephen Szopa wrote:
>
> How to post absolutely anything on the Internet anonymously
>
> http://www.sciam.com/2000/1000issue/1000techbus2.html
------------------------------
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Re: SDMI Successfully Hacked
Date: Fri, 20 Oct 2000 13:24:45 -0700
"Mack" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Officially - SDMI is alive and well
> and may remain that way.
>
> Unofficially - It didn't have a prayer.
> SDMI is deader than roadkill on the 610
> loop in Houston, TX.
> Mack
> Remove njunk123 from name to reply by e-mail
Maybe if all 450 cracks get posted here, SDMI will really die.
*David Barber*
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Encrypting large blocks with Rijndael
Date: Fri, 20 Oct 2000 22:46:07 +0200
John Myre wrote:
>
> Mok-Kong Shen wrote:
> <snip>
> > If I remember a previous discussion correctly, the larger
> > block size of Rijndael with more rounds is meant to be
> > used by people desiring higher security and hence opting
> > to use a large key.
> <snip>
>
> Rijndael allows for larger blocks without requiring a
> larger key. I'm asking, under what circumstances would
> it be a good idea to use that option.
The larger block size offers a higher 'potential' for
achieving a better security in general, because you have
a mapping of 2^n --> 2^n which is larger for larger n,
provided that the block size remains in appropriate, i.e.
not radically extreme, relation to key size, I suppose.
BTW, in another context, block chaining is in my view an
attempt to reap some benefit of processing a very large
block, namely the whole message. See also the thread
'On block encryption processing with intermediate
permutations' (yet under debate).
M. K. Shen
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Encrypting large blocks with Rijndael
Date: Fri, 20 Oct 2000 15:03:15 -0600
After I said:
> > Rijndael allows for larger blocks without requiring a
> > larger key. I'm asking, under what circumstances would
> > it be a good idea to use that option.
Mok-Kong Shen replied, in part:
> The larger block size offers a higher 'potential' for
> achieving a better security in general, because you have
> a mapping of 2^n --> 2^n which is larger for larger n,
> provided that the block size remains in appropriate, i.e.
> not radically extreme, relation to key size, I suppose.
To which I now say, so what? That's not what I asked,
"potential" security is not relevant here, and your
supposition is baseless. I don't want a lecture on
general abstractions; I want opinions on the actual
question I'm asking (read it above).
JM
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Which "password" is best.
Date: Fri, 20 Oct 2000 15:00:40 -0600
In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
> On the plus side, deliberately trying for a pangram could
> be an excellent way to avoid too-simple phrases, and allowing
> yourself a missing letter or two could also help.
>
Near pangrams do work. In writing them, a letter or two usually defies
easy inclusion; just stick it at the end of the string.
I am throughly convinced that almost anything can be said well in
pangrams, given the spread of meaning in our language. It is true that
given a few weird unassigned letters, one is apt to see overworked words
like vex, quick, and jive. Accordingly, not suprizing that q is often
followed by the singleton u, so use an earlier word having a u.
As a reversible hash, an abstracted pangram has an increasing difficulty
like shoot the moon, the first word are two easily identified, those
following filled out only with prior letters.
--
52) *Part of job is making whimsical, zippy, and vexing key sequences.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Encrypting large blocks with Rijndael
Date: Fri, 20 Oct 2000 23:56:40 +0200
John Myre wrote:
>
> After I said:
>
> > > Rijndael allows for larger blocks without requiring a
> > > larger key. I'm asking, under what circumstances would
> > > it be a good idea to use that option.
>
> Mok-Kong Shen replied, in part:
>
> > The larger block size offers a higher 'potential' for
> > achieving a better security in general, because you have
> > a mapping of 2^n --> 2^n which is larger for larger n,
> > provided that the block size remains in appropriate, i.e.
> > not radically extreme, relation to key size, I suppose.
>
> To which I now say, so what? That's not what I asked,
> "potential" security is not relevant here, and your
> supposition is baseless. I don't want a lecture on
> general abstractions; I want opinions on the actual
> question I'm asking (read it above).
Oh, I am sorry to be ignorant of how much stronger
exactly for Rijndael of a larger block size compared to
the smaller block size but with the same key size. That
depends on the skill of the its authors of doing it
right. But assuming that it is the case, then, since
presumably they have made use of the said 'potential',
the larger block one is stronger. So, under the
circumstance that one needs a higher security, using
the large block is a good idea. Does that answer
your original question?
M. K. Shen
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Encrypting large blocks with Rijndael
Date: Fri, 20 Oct 2000 16:05:57 -0600
Mok-Kong Shen wrote:
<snip>
> So, under the
> circumstance that one needs a higher security, using
> the large block is a good idea. Does that answer
> your original question?
>
> M. K. Shen
No.
Under what circumstances would one need higher
security than 128-bit key with 128-bit blocks?
(Note the subject line.)
JM
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Encrypting large blocks with Rijndael
Date: Sat, 21 Oct 2000 00:48:04 +0200
John Myre wrote:
>
> Mok-Kong Shen wrote:
> <snip>
> > So, under the
> > circumstance that one needs a higher security, using
> > the large block is a good idea. Does that answer
> > your original question?
> >
> > M. K. Shen
>
> No.
>
> Under what circumstances would one need higher
> security than 128-bit key with 128-bit blocks?
>
> (Note the subject line.)
Under the circumstance that one considers the security
of the smaller block is not sufficient and with the
assumption that Rijndael with the larger block is
indeed stronger. Why does one need that very high
security? There could be many reasons. For one, the
person is paranoid. There could be other reasons
conceivable.
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Dense feedback polynomials for LFSR
Reply-To: [EMAIL PROTECTED]
Date: Fri, 20 Oct 2000 22:37:21 GMT
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Joaquim Southby <[EMAIL PROTECTED]> wrote:
:> : In article <8sg0h7$a1b$[EMAIL PROTECTED]> Tim Tyler, [EMAIL PROTECTED] writes:
:> :>The question then becomes: how do you have the faintest idea what the
:> :>period of the LFSR is without looking at the corresponding polynomial's
:> :>properties, and checking to see whether it is primitive.
:> :>
:> :>Without performing such a procedure, I don't see how you can claim that
:> :>99% of the state spece is covered from a given position - unless you
:> :>perform an exhaustive search - something which becomes impractical as
:> :>the size of the register grows.
[snip exhaustive search]
:> : With a maximal-length LFSR, the key is any number between zero and 2^n.
:> : Advantage: very easy to choose a suitable key. With a sub-maximal LFSR,
:> : the known init vector is seeded to the LFSR, then the LFSR is clocked a
:> : number of times equal to the key value before using the stream output.
:> : Advantage: key can be larger than 2^n since the clock count will
:> : effectively be the key moduloed by the size of the state space.
:>
:> You call discarding much of the information in your key an "advantage"?
: Let's see, we load the initial (known) state and clock a number of
: times equal to the 256 bit key value before using the stream output.
: Strange as it seems this actually works. [snip tongue in cheek analysis
: based on large time taken]
: Even for a 64-bit key this is probably true ( ... pi seconds is a nanocentury
: ... so the first message takes a couple millennia if the LFSR can be
: clocked at 100 MHz.
You seem to think it takes a long time to calculate the result of an
LFSR stepping forwards a large number of steps.
This is not so - you can clock an LFSR forwards 2^100 steps in the blink
of an eye, bu exploiting the fact that it's a linear operation, and
multiple applications of it produce linear operations (all of which can be
represented concisely by matrix operations).
The original idea makes no sense, but execution time does not appear to be
a problem with it.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: What is meant by non-Linear...
Reply-To: [EMAIL PROTECTED]
Date: Fri, 20 Oct 2000 22:43:32 GMT
Stephen M. Gardner <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> "I can plot "straight lines" through the points in the finite field.
:>
:> The "straight lines" curve on the surface of the cylinder - but they have a
:> fixed local gradient with respect to the {theta,x} co-ordinate system,
:> and don't "jump around".
: I notice that you didn't answer this part:
: y = 2x + 1 defined on GF(3) gives the following set of ordered pairs
: {(0,1), (1,0), (2,2)}. Draw that on a cylinder if you want but
: how does it lie on a line or line segment?
: how do you figure that this set of points lies on a line (or a line wrapped
: on a cylinder)? The y-coordinate goes 1->0->2 (down to zero, up to 2).
: Finite fields "hop around" or they wouldn't be very good in Cryptography.
Like this (on a torus).
2 . . .
1. . .
0 . . .
2 . . .
1. . .
0 . . .
2 . . .
1. . .
0 . . .
+0 1 2 0 1 2 0 1 2 -> x
I'm sure you can make out the straight line yourself.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Fri, 20 Oct 2000 23:30:56 GMT
Mok-Kong Shen wrote:
>
> Bryan Olson wrote:
> >
> > Mok-Kong Shen wrote:
> >
> > > To better illustrate my difficulty of undestanding your
> > > stuff and hence (indirectly) my doubt of applicability of
> > > the attack you invented, I like to formulate my point a
> > > bit formally:
> > >
> > > Let there be a cipher that is DES-like with a block
> > > consiting of two words and has four rounds, i.e. two cycles,
> > > and one intermediate permutation. Let there be four blocks
> > > each with input (u,u).
> >
> > Well, there's your problem. That's not the chosen plaintext
> > that the attack uses. First I use a single block (two word)
> > message, call it (u, v), and then a two-block message. As I
> > wrote:
> >
> > | Again we use
> > | the same message many times, but this time the message is
> > | two blocks (four words) long. The two blocks are the same
> > | as each other, and the same as our one-block plaintext for
> > | which we got the 64 possible outcomes. If the one-block
> > | message we used was (u, v) then the two-block message is
> > | (u, v, u, v).
>
> It is very strange. For on 15th Oct you wrote:
>
> The content of the block does not matter. Note that (u, v)
> is not a special form; it just labels the first word 'u' and
> the second 'v'. There is no need to use a block of the form
> (u, u), but it will not impede the attack either.
>
> Could you explain that in connection with what you just
> wrote?
What's to explain? It's perfectly consistent. As the attack
stated "a block is two words". When writing of a one-block
plaintext, I wrote:
| First I'll encrypt the same single-block message a few
| hundred times. Call the plaintext (u, v), where u and v are
| the two words of the block.
In all my quotes above I continue to denote blocks using one
variable per word. The form (u, u) means one block in which
the two words hold the same value. There is no reason to use
this special form for the one-block message. I do use the
two-block special form (x, y, x, y).
> > What follows explains how to find the sibling pairs.
> >
> > Of course in your two-cycle case finding a sibling pair using
> > just the one-block plaintext is vacuously easy.
>
> Fine. Please kindly write your equations with respect to
> what I denoted in the previous post which is repeated below.
> (I assume that you don't retract what you wrote about
> (u,u) previously. Actually using (u,v) would take more
> space in the post only, for the principle is the same.)
>
> Input of first cycle:
> (u,u) (u,u) (u,u) (u,u)
If you insist on four-block messages while my chosen plaintext
attack calls for one-block and two-block messages, then any
equations you need are up to you.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Works the md5 hash also for large datafiles (4GB) ?
Date: Sat, 21 Oct 2000 00:20:59 GMT
John Myre wrote:
> Actually, isn't the algorithm well defined even for zero input?
> I think any number of bits works, up to 2^64 - 1.
Actually it's any non-negative, integral number of bits.
>From RFC 1321, "The MD5 Message-Digest Algorithm":
In the unlikely event that b is greater than 2^64, then only
the low-order 64 bits of b are used.
Hmmm, I guess that points out a (trivial) bug in the spec,
since technically it leaves out the case of an input that is
exactly 2^64 bits long.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Archer" <[EMAIL PROTECTED]>
Subject: Hash programs
Date: Fri, 20 Oct 2000 21:11:32 -0400
Hello all. I have an idea for a program and want to know if something like
it already exists. If so, where can I find it.
Ok, here it goes. Be able to select a file or folder and generate a hash for
it using a variety of hash algorithms. Then have this hash saved to a file
that is encrypted. Then, you could come back later and select the same
folder/file, and see if it has been altered. I know this is the basis of an
integrity checker program (or intrusion detection). However, what I am
seeking is something that is much easier to use and have the ability to
select one single file or an entire partition.
Does this make sense?
I am running Win2k. I know Win2k will audit specific files/folders, this
would just be another layer of defense.
If something like this does not already exist, would anyone here be
interested in programming for hire to do it?
Archer
------------------------------
From: Andreas Gunnarsson <[EMAIL PROTECTED]>
Subject: Re: algo to generate permutations
Date: Sat, 21 Oct 2000 03:39:05 +0200
On Wed, 18 Oct 2000 [EMAIL PROTECTED] wrote:
> Your code is 2x faster than mine, and half the size, and it does
> lexicographic order, and it avoids recursion. Very good!
>
> - Bob Jenkins
Since so many people have shown interest for the algorithm I want to
mention that it now is another 2-2.5 times faster (depending on the input)
thanks to Bob Jenkins. I've also cleaned up the code a little. The new
version has replaced the old one at ftp://ftp.zzlevo.net/pub/src/perm.c
Andreas
--
Andreas Gunnarsson <[EMAIL PROTECTED]>
Carlstedt Research & Technology
Phone: +46 31 7014268
Mobile: +46 70 4262889
Fax: +46 31 101987
------------------------------
** 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
******************************
