Cryptography-Digest Digest #240, Volume #12      Mon, 17 Jul 00 20:13:00 EDT

Contents:
  Re: DOS vs DOS (was Re: SECURITY CLEAN...) _long_ (Future Beacon)
  Re: Bit Shuffling (Mark Wooding)
  Re: Question Regarding Encrypting CD-ROM -RW Disks (Steve Rush)
  Crypto analyze tool. ([EMAIL PROTECTED])
  Re: Question Regarding Encrypting CD-ROM -RW Disks ("Joseph Ashwood")
  Re: DOS vs DOS (was Re: SECURITY CLEAN...) _long_ (Dave Martel)
  Re: DOS vs DOS (was Re: SECURITY CLEAN...) _long_ (Dave Martel)
  Re: DOS vs DOS (was Re: SECURITY CLEAN...) _long_ (Future Beacon)
  Re: Crypto analyze tool. ("Joseph Ashwood")
  Re: RC4-- repetition length? (Rex Stewart)

----------------------------------------------------------------------------

From: Future Beacon <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: DOS vs DOS (was Re: SECURITY CLEAN...) _long_
Date: Mon, 17 Jul 2000 17:06:26 -0400



On Saturday, July 8, 2000 The New York Times on page A1 in a story
called "Fearing Control by Microsoft, China Backs the Linux System"
reported that secret back doors in Microsoft operating systems
prompt them to make national policy in favor of the Linux operating
system.  The article quoted the People's Liberation Army Daily:
"Without information security there is no national security in
politics, economics, and military affairs."

Our best efforts to design encryption algorithms come to nothing if
the operating system is not secure.  All of the convenience features
in the world would not entice me to use Windows.


Jim Trek
Future Beacon Technology
http://eznet.net/~progress
[EMAIL PROTECTED]



In sci.crypt Rick Braddam <[EMAIL PROTECTED]> wrote:

> Well, if Linux was every bit as capable as Win98, then I wouldn't have had
> any problems writing CDs with my CD-RW drive after installing Red Hat 6.0
> on my machine. I guess I didn't really have a problem... all I had to do
> was shut down Linux and use LILO to reboot under Win98, then double-click
> on the Easy CD Creator icon. Then I could write CDs all day long. Why did
> I have to do that? No Linux program or driver was available for my CD-RW
> drive, from anywhere. Why didn't I write my own driver or program to run
> my CD-RW drive? Why should I, I already had a commercial quality program
> that could "get things done", just one of tens of thousands of
> applications which run on the PC platform under Windows.


------------------------------

From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Bit Shuffling
Date: 17 Jul 2000 21:16:09 GMT

Jayant Shukla <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Mark Wooding) writes:
> 
> >The main problem with bit permutations is that they can do nothing
> >with single active bits except move them around.  Thus, the best
> >differential or linear hull for a cipher may take in only a single
> >active S-box per round.
> 
> You are assuming that there is only one round and a single operation
> (bit shuffle) used in the cipher. I'll grant that your conclusions are
> correct in that case. How many ciphers you know have only one round
> and use only one mathematical operation in each round? Can you support
> your arguement if this function is used with a data dependent
> non-linear operation and the cipher has more than one round?

No.  You've failed to understand.  Characteristics such as are exploited
by differential and linear cryptanalysis have probabilities similar to
the products of the characteristics in the active components.  If the
diffusion between your nonlinear elements is entirely based on bit
permutations then, unless you're phenomenally careful, that can be
easily reduced to one nonlinear element per round.  (And see below for
why being careful might not help.)

> >Constructing ciphers which are based around bit permutations as the
> >main diffusion element is extremely hard, requiring a great deal of
> >care in the design of the permutations and nonlinear elements and the
> >way in
> 
> Constructing ciphers based on bit-permutation is inefficient.
> Designing any cipher is hard and requires a great deal of care. The
> main point was to introduce a way to shuffle bits that is efficient
> and does not take up a lot of clock cycles or silicon area.

But bit permutations in current ciphers are free in software already!
See below.

> >which they interact.  MDS matrices and PHT networks (e.g., in Rijndael
> >and SAFER) are both more effective in increasing the number of active
>                     ^^^^^^
> >components per round and easier to use in new designs.
> 
> How do you know that? Any references? I have looked up the papers on
> Rijndael, TwoFish, and SAFER, and the authors do not claim any such
> thing.

Analysis!  (And fairly simple analysis at that).  Daemen and Rijmen
claim (and prove) that any two-round differential or linear trail in
Square or Rijndael has at least five active S-boxes and any four-round
trail has 25 active S-boxes.  I believe that SAFER's PHT layer has
similar properties, though I've not seen a proof of this (I daresay it's
not hard to show).

Consider two rounds of a standard SP network, e.g., the DES F-function,
Feistel's design published in his SciAm article, or Tom St Denis's TC1.
The input is divided into chunks to be acted upon in parallel by the
nonlinear substitution layer, and then the output bits are permuted
before being divided again into chunks for the substitution.  [There may
be key mixing steps between the nonlinear substitution and linear
permutation steps; this doesn't matter for the analysis.  If the final
permutation is unkeyed, we can neglect it.]

Let d_0 -> d_1 be any differential characteristic through the
substitution layer such that d_1 has Hamming weight 1.  The bit-
permutation layer *must* by its nature preserve the Hamming weight of
any input difference in its output difference.  Then we have an input
difference of Hamming-weight 1 into the second substitution layer.

It can be easily seen that any n-round cipher, whose diffusion is
provided by bit-permutations and where the lowest-probability
differential characteristic has probability p, must have an n-round
characteristic with probability p^n.  Contrast this with the case of
Square and Rijndael, based as they are on MDS codes, which guarantee
that even a four-round differential trail must have 25 active S-boxes,
and hence the best differential characteristic has probability p^{25}.
The structure of Twofish is more difficult to analyse, as the authors
mention, but still the number of (key-dependent) S-boxes in any two-
round characteristic is considerably greater than can be achieved using
a bit permuation.

If you were following carefully, you'll have noticed that I cheated
above: I changed the meaning of `p'.  In the first case, it was the
lowest-probability characteristic, and in the second it was the highest.
Without very careful S-box design, this difference is irrelevant:
there's a factor of p^{20} in it!  It *is* possible to construct S-boxes
which defeat low-Hamming-weight characteristics simply by ensuring that
they happen with sufficiently low probability (or, possibly never at
all).  I suspect that this is a really bad idea, though: it puts the
S-box into a particularly small subspace of possible permutations and
could quite conceivably be used as the basis of an attack itself.

> >This is beside the fact that the usual way to implement bit
> >permutations is to combine them with S-boxes in big tables, making
> >the permutation free.
> 
> Words fail me here! The whole point of using this shuffle is that you
> not have to rely on look up tables. Look up tables are expensive.  If
> you implement 128 bit shuffle using look up table, you are toast.

Do remember that most current block ciphers are based around table
lookups anyway!  The usual construction is a substitution (done by table
lookup) followed by a linear diffusion layer.  In the case of bit
permutations and MDS matrices, the linear diffusion can be combined with
the nonlinear S-box in one table lookup.  The diffusion is then achieved
with the same cost as simply recombining the outputs of the S-boxes
(possibly by XOR rather than OR, in the case of an MDS code).

See any efficient implementation of DES, Square, Rijndael, Twofish, ...
I'll admit that SAFER's PHT isn't free, although it's still a hell of a
lot better than a bit permuatation.

> Please do read the previous thread started by Mok-Kong to get
> a better picture of why this might be important.

Please read the long thread between myself and Tom St Denis about why
bit permutations in ciphers are a bad idea, including differential
cryptanalysis of TC1 by both myself and Matthew Fisher.


P.S.  Have you considered that the INTERCAL [Woods and Lyon, 1972]
      `select' operator might be prior art in this field?

-- [mdw]

------------------------------

From: [EMAIL PROTECTED] (Steve Rush)
Date: 17 Jul 2000 21:31:23 GMT
Subject: Re: Question Regarding Encrypting CD-ROM -RW Disks

>I have been using Puffer and Crypta-Pix, both of which use 160 bit
>Blowfish to encrypt, as well as  PGP to encrypt text and binary files
>residing on either my hard drive, floppy diskettes or Zip diskettes.
>
>I've now purchased an HP CD "burner" to use to store the same
>materials in CD format.  I use both read only CDs and the rewriteable
>kind that can be used in much the same way that diskettes can be used,
>that is to write, erase, rewrite, move data around, etc.
>
>My question is, given the nature of CDs, which, I understand, is not a
>magnetic medium, can these encryption programmes be used with them in
>the same way that they can be with diskettes, etc?  Are there any
>problems in using these forms of encryption with CDs that are
>different than with the older media?  Is there anything different
>about wiping these CDs with the above-mentioned, or other programmes?

To paraphrase a silly fast-food commercial,  bits is bits.  The physical
storage mechanism isn't even visible above the level of the device drivers.  As
for secure wiping of any removable disk, I wouldn't fiddle with overwriting
schemes when an incinerator is perfectly secure (I don't think even the NSA's
labs can reconstruct smoke) and probably faster.

Note that just shredding the disk is less secure.  Chopped-up floppies have
been reconstructed, and a chopped CD-ROM is just a larger (but not impossible)
puzzle.

==========================================================================
==============
If it's spam, it's a scam.  Don't do business with Net abusers.


------------------------------

From: [EMAIL PROTECTED]
Subject: Crypto analyze tool.
Date: Mon, 17 Jul 2000 21:31:02 GMT

Hi tekkies.

I'm just wondering if there is a tool for working with symmetric
ciphers on the web. If you have any knowledge of one please mail me.

The reason i ask is that I have an idea about building a 'studio' tool
for analyzing different symmetric ciphers. You could have some API to
make it possible for users to develop ciphers as external modules and
also make analyze methods like external modules.

This is just in the idea stage but please mail me if you have any ideas
of what functions would be desired in such a tool.

/ foo


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Question Regarding Encrypting CD-ROM -RW Disks
Date: Mon, 17 Jul 2000 15:11:09 -0700

Well, wiping a CD of any form is a very different prospect from wiping a
hard drive, but the old standby of destruction by fire is a very viable
option, and works quite well on CDs. I'm not sure why you're bothering with
3 different programs that perform essentially the same operations,
personally I'd just choose one of them (probably PGP) and lose the others.
For wiping, if your files are all encrypted the wiping is simply an extra
precaution, what I would recommend is repeatedly over writing the disk with
encrypted randomly generated files, even a simple rand() call should be
sufficient if the programs used choose numbers strongly (which I'm sure PGP
can do, but I think the others rely on your password).

I'd recommend that you lose Puffer and Crypta-Pix, and simply go with PGP,
it's not any weaker, and may be a little stronger, since you still have the
option of using your chosen algorithm with a password you choose, or
encrypting it for a specific person. You should also grab something like
ScramDisk (http://www.scramdisk.clara.net) and use it to cryptographically
protect your files more conveniently in pseudo-disks.
                    Joe

"omit these words com" <Barrister9@aol.> wrote in message
news:[EMAIL PROTECTED]...
> I have been using Puffer and Crypta-Pix, both of which use 160 bit
> Blowfish to encrypt, as well as  PGP to encrypt text and binary files
> residing on either my hard drive, floppy diskettes or Zip diskettes.
>
> I've now purchased an HP CD "burner" to use to store the same
> materials in CD format.  I use both read only CDs and the rewriteable
> kind that can be used in much the same way that diskettes can be used,
> that is to write, erase, rewrite, move data around, etc.
>
> My question is, given the nature of CDs, which, I understand, is not a
> magnetic medium, can these encryption programmes be used with them in
> the same way that they can be with diskettes, etc?  Are there any
> problems in using these forms of encryption with CDs that are
> different than with the older media?  Is there anything different
> about wiping these CDs with the above-mentioned, or other programmes?
> Are there other issues with trying to retrieve wiped data than their
> are with the magnetic media.
>
> Thank you for your assistance.
>
> Larry



------------------------------

From: Dave Martel <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: DOS vs DOS (was Re: SECURITY CLEAN...) _long_
Date: Mon, 17 Jul 2000 17:12:29 -0500

On Mon, 17 Jul 2000 20:26:20 GMT, [EMAIL PROTECTED] wrote:

>Just for the record, Windows doesn't support EIDE CD-RWs either. The
>ASPI layer is an Adaptec product, and requires that you own either an
>adaptec host adaptor or software product to upgrade it.

ASPI v1.0 comes standard with Windows. To upgrade it without Adaptec
hardware or software, go to Control Panel, Add Hardware, and add a
basic Adaptec SCSI adapter (even though you don't have one installed).
Then go ahead and run Adaptec's ASPI installation program and you're
upgraded.

>It's not
>uncommon for drives to not work under various Windows versions, if the
>user doesn't own Easy CD Creator.

My EIDE burner's a Plextor. It works under Win98SE. I don't have any
Adaptec hardware or apps installed.


------------------------------

From: Dave Martel <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: DOS vs DOS (was Re: SECURITY CLEAN...) _long_
Date: Mon, 17 Jul 2000 17:19:20 -0500

On Mon, 17 Jul 2000 17:06:26 -0400, Future Beacon <[EMAIL PROTECTED]>
wrote:

>Our best efforts to design encryption algorithms come to nothing if
>the operating system is not secure.  All of the convenience features
>in the world would not entice me to use Windows.

On the other hand, an OS that's a mile over the user's head is also
not very secure. In its current form the average computer doesn't
stand a snowball's chance in hell of making linux secure and keeping
it that way. 

The average computer user also doesn't need ultra security. A firewall
like AtGuard running under Win98 isn't the greatest but it's
sufficient for most people and doesn't take a whole lot of expertise
to install and use. It would take me six months to learn enough about
linux to make a linux system equally as secure. It would take another
six months to learn to make it _truly_ secure. I have better things to
do.


------------------------------

From: Future Beacon <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: DOS vs DOS (was Re: SECURITY CLEAN...) _long_
Date: Mon, 17 Jul 2000 19:39:47 -0400



On Mon, 17 Jul 2000, Dave Martel wrote:

> On Mon, 17 Jul 2000 17:06:26 -0400, Future Beacon <[EMAIL PROTECTED]>
> wrote:
> 
> >Our best efforts to design encryption algorithms come to nothing if
> >the operating system is not secure.  All of the convenience features
> >in the world would not entice me to use Windows.
> 
> On the other hand, an OS that's a mile over the user's head is also
> not very secure. In its current form the average computer doesn't
> stand a snowball's chance in hell of making linux secure and keeping
> it that way.


The average user would surely find Linux hard to learn.  To make
things worse, the Linux community is interested in Linux remaining
large and somewhat standardized.  The PC needs a truly open
operating system that can be modified by programmers for such
purposes as user-friendly secure Internet access.  FreeBSD is
currently the best hope for that because it license agreement
merely assures you that you can use it any way you like.

The problem you point out with Linux could possibly be solved with
help or great effort, but nothing can make Windows secure.


> The average computer user also doesn't need ultra security.


Every user deserves absolute e-mail privacy.  They can't know when
they will really need it.


> A firewall
> like AtGuard running under Win98 isn't the greatest but it's
> sufficient for most people and doesn't take a whole lot of expertise
> to install and use. It would take me six months to learn enough about
> linux to make a linux system equally as secure. It would take another
> six months to learn to make it _truly_ secure. I have better things to
> do.
> 
> 


Jim Trek
Future Beacon Technology
http://eznet.net/~progress
[EMAIL PROTECTED]


------------------------------

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Crypto analyze tool.
Date: Mon, 17 Jul 2000 16:44:24 -0700

Right now that idea isn't doable effectively. What you want to do is
effectively equivalent to "Review this artwork for me" this is due to the
fact that cryptography isn't a true science yet, we haven't even proven
whether or not you can actually have a secure cipher whose key is smaller
than the document it's protecting.

As for what fucntions should be in a tool, how about a function called
howBadIsMySnakeOil(encryptFunc, decryptFunc, KeySize, minInputValue,
maxInputValue, minOutputValue, maxOutputValue), because the likelihood that
someone who has to use a tool of modern knowledge to analyze their cipher is
severely unlikely to find anything anywhere near secure. Just to give you
some idea of the complexities of analysis of ciphers, judging them on rounds
doesn't work (RSA is secure with 1 round, DES takes several), you can't
judge them on size (a Vigenere cipher can be gigabytes in size and still be
weak, 3DES operates on 64-bit blocks with a 168-bit key), you can't judge
them on type of round (Feistels can be as weak as a home brew, homebrews can
actually be strong round types), on resistance against attacks (each attack
has to be custom tailored), on brute-forcability (the gigabyte+ Vigenere
would certainly not be bruteforcable), on the final operation (RC4 uses XOR
on the output of the pRNG, so does a vigenere). There are actually many of
us working on just this problem, what constitutes a secure cipher, I'm
hoping that sometime within the next decade I can find a qualification that
was not previously known, but my odds aren't that great. Once we know all
the qualities that go into making a cipher strong, we'll be able to build
such a program, until then there's no point in even trying.
                Joe

<[EMAIL PROTECTED]> wrote in message
news:8kvtun$dkg$[EMAIL PROTECTED]...
> Hi tekkies.
>
> I'm just wondering if there is a tool for working with symmetric
> ciphers on the web. If you have any knowledge of one please mail me.
>
> The reason i ask is that I have an idea about building a 'studio' tool
> for analyzing different symmetric ciphers. You could have some API to
> make it possible for users to develop ciphers as external modules and
> also make analyze methods like external modules.
>
> This is just in the idea stage but please mail me if you have any ideas
> of what functions would be desired in such a tool.
>
> / foo
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.



------------------------------

From: Rex Stewart <[EMAIL PROTECTED]>
Subject: Re: RC4-- repetition length?
Date: Mon, 17 Jul 2000 23:38:40 GMT

While I appreciate the pointers into the Ciphersabre description
and analysis pages, and also the excerpt which obviously was
intended to save me the work of looking it up - it still does
not really answer my question.  Let me try to be clearer.

There appears to be two potentially weak key problems with RC4
(or ARC4). One is keys which leave zeroes in certain locations
causing the output to leak key bits. And another which causes
short cycles.

The paper http://burtleburtle.net/bob/rand/isaac.html describes
conditions leading to short cycles, but then says the keying
method prevents this from occurring.

The analysis of Ciphersabre indicates the weak keys causing
leakage of key bits could be a problem in Ciphersabre 2 (and
remedies for this have been discussed at length) but does not
address the problem of keys resulting in short cycles.

The paper on ISSAAC says keying RC4 the standard way will not
result in short cycles, but if I understand the situation
correctly keying it through repeated cycles naively could
result in achieving a condition resulting in a short cycle.

In article <8ktgt8$[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (Guy Macon) wrote:
> Rex Stewart wrote:
> >
> >
> >In article <8kj04a$bd4$[EMAIL PROTECTED]>,
> >  [EMAIL PROTECTED] wrote:
> >> In article <[EMAIL PROTECTED]>,
> >>   John Myre <[EMAIL PROTECTED]> wrote:
> >> > Bill Unruh wrote:
> >> > <snip>
> >> > >
> ><<cut>>
> >>
> >> I did some analysis a few years ago because RC4 resembled a
> >> generator I had developed independently.  Here's the analysis:
> >>
> >>   http://burtleburtle.net/bob/rand/isaac.html
> >>
> ><<cut>>
> >>
> >> - Bob Jenkins
> >
> >As I was looking at the above paper, I realised it said the
> >method of keying prevented landing in a short cycle. I was
> >wandering if the keying method in Ciphersabre 2 might be
> >problematic since it uses the same keying method, but does
> >not stop in the same place.
>
> Source: http://ciphersaber.gurus.com/cryptanalysis.html
>
> A Cryptanalysis of CipherSaber-1
> is explained more fully at http://ciphersaber.gurus.com.
>
<<cut long excerpt from the ciphersaber pages>>
>
> Source: http://ciphersaber.gurus.com/cryptanalysis.html
>
>

--
Rex Stewart
PGP Print 9526288F3D0C292D  783D3AB640C2416A


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------


** 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
******************************

Reply via email to