Cryptography-Digest Digest #225, Volume #12      Fri, 14 Jul 00 14:13:01 EDT

Contents:
  Re: New Idea - Cipher on a Disk (Wim Lewis)
  WSJ Article on Mexico / Encryption (Nomen Nescio)
  Re: Is there any bright mind who have 5 seconds to spare? (John Savard)
  Re: multiplier ("Hans Husman")
  Re: New Idea - Cipher on a Disk ("Trevor L. Jackson, III")
  Re: New Idea - Cipher on a Disk ("Trevor L. Jackson, III")
  Re: Steganographic encryption system (Phil Britton)
  Re: Steganographic encryption system ("Joseph Ashwood")
  Re: Cryptographic Camouflage (John Myre)
  Re: Proposal of some processor instructions for cryptographical  ("Eric C. Fromm")
  Re: New Idea - Cipher on a Disk (Chris T)
  Re: General Question on cryptography (Mok-Kong Shen)
  Re: Cryptographic Camouflage ("Joseph Ashwood")
  Re: Idea for CFB-like cipher (Mack)
  Re: Steganographic encryption system ("Bob Billing (AKA Uncle Bob)")
  Re: Cryptographic Camouflage (John Myre)
  Win2000 Encryption (Greg)

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

From: [EMAIL PROTECTED] (Wim Lewis)
Subject: Re: New Idea - Cipher on a Disk
Date: 14 Jul 2000 09:22:58 GMT

In article <8km7mv$mmc$[EMAIL PROTECTED]>, Greg  <[EMAIL PROTECTED]> wrote:
>it.  Then the next step is building some type of on board encryption
>onto every network card or replacing the entire TCP/IP with TCP/SIP
>(secured internet protocol) - a network protocol based upon encrypted
>traffic.

IPsec is out there today, if you want it. There have been other IP-level
encryption techniques available for some platforms for years. 

-- 
             Wim Lewis * [EMAIL PROTECTED] * Seattle, WA, USA
"If you torture the data enough, nature will always confess." (R H Coase)

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

From: Nomen Nescio <[EMAIL PROTECTED]>
Subject: WSJ Article on Mexico / Encryption
Date: Fri, 14 Jul 2000 12:30:03 +0200 (CEST)

Did anyone catch the front page of the Wall Street Journal
yesterday (7-13-2000).  They mentioned in a follow up article
that the 'leftist' party had cracked the encryption on a report
that had come into their hands from the ruling party detailing
who got paid off in some bailout.

There had been an earlier article, several weeks ago that the
decryption was being attempted.

Does anyone know any more details about this?


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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Is there any bright mind who have 5 seconds to spare?
Date: Fri, 14 Jul 2000 10:26:01 GMT

On Thu, 13 Jul 2000 20:29:43 +0200, Ichinin <[EMAIL PROTECTED]>
wrote, in part:

>a61d203f , round: f
>203f8622 , round: 10

>203f8622 (Crypttext)

>203f929a , round: 1

Obviously, that had better be 203fa61d instead. So if you can check
why your F-function, with 203f as input, is producing two different
outputs (or _is_ it being given 203f as input in both cases), you
should be able to find the problem.

John Savard (teneerf <-)
http://home.ecn.ab.ca/~jsavard/crypto.htm

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

From: "Hans Husman" <[EMAIL PROTECTED]>
Subject: Re: multiplier
Date: Fri, 14 Jul 2000 13:07:51 +0200


"Andrew Dunlop" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi,
>
> I'm looking for a smallish fast multiplier capable of multiplying 512 or
> 1024 bit numbers for RSA. Does anyone have suggestions for a good method?
>
> thanks
> A.
>
>

You could download the GMP bignumber library and take out the code you
need (of course according to the copyright). A big part of the code is
written in
assembler so it is fast. It can be compiled for must OS.

Best Regards

============================================================================
=========
Hans Husman
Security Specialist
Mynta Management & IT AB
Eriksbergsgatan 46
Box 26034
100 41 Stockholm
[EMAIL PROTECTED]
http://www.mynta.se

============================================================================
=========
Prenumerera på något av Myntas nyhetsbrev!

Mynt@. Ett nyhetsbrev från en elektronisk affärsvärld.
Säker med Mynta. En elektronisk tidning om datasäkerhet.

Skicka ett mail till [EMAIL PROTECTED] och ange vilket nyhetsbrev du vill ha.
============================================================================
=========




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

Date: Fri, 14 Jul 2000 10:45:02 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: New Idea - Cipher on a Disk

Benjamin Goldberg wrote:

> Trevor L. Jackson, III wrote:
> [snip]
> > I think this concept needs a true sideband channel -- one that extends
> > the interface between the drive and the world.  Such extension is hard
> > to do transparently.
>
> How about a hardware solution: The encryption key is stored in a
> self-erase-if-tampered-with microchip, in a case which can be plugged
> into the drive.  The case could either be a smartcard, or perhaps
> something which can go on a normal physical keychain.

Sure.  But if you were to make such a drastic (meaning non transparent) change
it would be better to make the key carrier generally available to all of the
subsystems within the computer.  Would you put up with a crypto dongle that
only worked for your disk drive?  Or, would you expect it to be available to
all of the applications you use (mail, web, etc.)?


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

Date: Fri, 14 Jul 2000 10:54:24 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: New Idea - Cipher on a Disk



Greg wrote:

> > > The key persists with the HD power and reset.
> >
> > So the drive knows it's own key?
>
> No, I miss stated that.  The key persist with the HD power - meaning it
> does not persist when the power goes away, and it remains even during
> reset.  But the latter can be optional.
>
> > Yes, this kind of enhancement is certainly possible.  Hard to
> > justify though given the existence of free packages like
> > PGPdisk and Scramdisk.
>
> I can see this.  But it would make encryption more pervasive in the
> market place.  People would opt to use it more if it came standard
> with every HD.  That was really my intent behind this - to get it
> into the hands of every common person using a computer.  Once it
> is in their hands (in the fashion that I outlined that makes the
> most compatibility sense to me), then it will be used.
>
> The software that is free is not used because people don't want to
> bother getting it or setting it up.  But if it is built in and they
> get a prompt at boot up, they will more likely use it because all they
> need to do then is literally just supply a password.  Everything else
> is fully transparent.
>
> Now there is one thing I would say would really hurt this approach -
> that the firmware on the cipher chip would be cumbersome to upgrade
> if at all.  That is where free software has one over.  But the absolute
> transparency cannot be matched by any other solution.

Agreed.  But does the average computer user need to add security to their
storage subsystem without adding security to their communication subsystem?  I
suspect most users are vulnerable to info theft via comm than via storage.
Personally, I fear abuse of Carnivore much more than I fear warrantless search
of my hard drives.

It may be that the market is defined by user's fears rather than the actual
threats to which they may be exposed.  Do people in general fear their secrets
will be discovered/exposed by breach of storage or breach of comsec?

>
>
> > There's also the issue of the obsolescence of the encryption hardware.
>
> Sort of like disk capacity, huh?

I don't think so.  Storage capacity is additive.  Computational throughput
generally isn't.

>
>
> >  I once had a machine that was one generation behind the
> > state-of-the-art machine.
>
> My machines get behind capacity every year.  I just upgraded my laptop
> to a 12G from a 4G.  No help from the manufacturer because it is no
> longer in production, but IBM makes good drives.  My Travelstar 12GN
> series replaced my 4GN series perfectly.  The BIOS wouldn't see the
> whole 12G, but Win98, Win NT4SP6, and Win2000 all did.  (but now I
> digress...)
>
> > The system used disk compression that made it IO bound when it
> > should have been compute bound, so I invested in an accelerator
> > card for the compression mechanism.  It gave me about a factor
> > of two in performance.
>
> I can see this.  But placing a cipher on a disk and having many of
> them is simply adding cipher processors to the system.  It would be
> interesting to see the results.
>
> > ...It would be _really_ tough to sell a secure drive that was slower
> > and more expensive than a bare drive plus free encryption software.
>
> I concur.  We simply have to ensure that does not happen, don't we?

Well, I guess my person bottom line is conditional.  If such drives were
available today, even at a 50% increase in price, I would use them.  But I
read sci.crypt, so I'm probably not a good sample.  Neither are you
(generalized you; the generic reader of this message ;-)


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

Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
From: Phil Britton <[EMAIL PROTECTED]>
Date: 14 Jul 2000 16:50:05 +0100

[EMAIL PROTECTED] (phil hunt) writes:

> On 12 Jul 2000 14:54:36 GMT, Paul Hughett <[EMAIL PROTECTED]> wrote:
> >In comp.os.linux.development.apps phil hunt <[EMAIL PROTECTED]> wrote:
> >
> >:>Explaining quite why a 1k plaintext encrypts to a 30k cyphertext
> >:>might keep you busy.
> >
> >: Not at all. If you try to encrypt a 1K file, the system will *always*
> >: produce a ciphertext which is substantially larger. This has the advantage
> >: of helping to defeat traffic analysis attacks.
> >
> >: Since stes will be open source, it probably won't be too difficult to prove 
> >: to a court that this is the case.
> >
> >The hard part comes when to try to prove to a court that the 1k plaintext
> >is the *only* message stored in this 30k ciphertext.
> 
> This will depend on the jurisdiction you live in. If a court will imprison you
> for failing to prove something that is impossible to prove, then you are not
> living somewhere under the rule of law, so stes cannot help you.

You mean the sort of country that Jack Straw is trying to turn Britain into

cheers

Phil

-- 
--
Philip W. Britton
Productisation & Support Manager
PrismTech Ltd,  UK.
Tel +44 191 497 9914       http://www.prismtechnologies.com

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

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Steganographic encryption system
Date: Fri, 14 Jul 2000 08:41:17 -0700
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux

> >Just remember that keyspace on its own is not a measure of security.
> >Consider how many keys a simple substitution cipher has, but it is
> >not generally secure.
>
> Yeah, but blowfish is secure against the sort of simplistic tricks that
> would work against a substitution cipher, right?

To a degree, but all ciphers can be viewed as substitution ciphers. The key
is used to determine what mapping between blocks to use, but tha actual
encryption can easily be viewed as a substitution of a much larger size (in
this case 64-bits instead of 8).
                        Joe



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

From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Cryptographic Camouflage
Date: Fri, 14 Jul 2000 10:01:14 -0600

Joseph Ashwood wrote:
<snip>
> > So the encryption
> > of e is to prevent attackers from substituting their own pq, e?
> 
> Actually it's because with a small pin protecting the D->d operation if e is
> know d can be found (I started some discussion a few months back on sifting
> through a series of d given e in RSA).
<snip>

So the theory is, that the attacker can get D, but we hope to prevent
an off-line guessing attack on the PIN (to acquire d, and therefore
be able to pretend to be the client) because the attacker does not
know e (only E)?

But what's to stop the attacker from capturing the challenge, and
the client's first response (C+padding)^d, and just trying PIN's
on D until he can replicate the client's response?

<snip>
> > Meanwhile, what other communication is going on?  That is, I
> > don't see what you could do with the above authentication except
> > say, "yep, that was really my client".  Then what?  Or is my
> > model of the communication path way off?
> Your model is quite accurate, we deal only with strict authentication, and
> even then only to the one server, instead of authenticating to generic
> entities.
>                 Joe

Um, what I meant, was, what can we do with the authentication?
Does the client tell us anything, or do we tell the client anything?
How do we know that the communication isn't hijacked after the
authentication?

Is the whole thing protected by some secure session in the first
place?

JM

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

From: "Eric C. Fromm" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical 
Date: Fri, 14 Jul 2000 11:24:35 -0500

Terje Mathisen wrote:

> What would the C pseudo-code for the Cray mod2 matrix mul look like?

good question. I'm not even certain BMM is supported in the compilers.

-- 
Eric C. Fromm                           [EMAIL PROTECTED]
Principal Engineer                      Scalable Systems Division
SGI - Silicon Graphics, Inc.            Chippewa Falls, Wi.

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

From: Chris T <[EMAIL PROTECTED]>
Subject: Re: New Idea - Cipher on a Disk
Date: 14 Jul 2000 16:32:42 GMT


Greg wrote:
< 
< > There's one thing that I'm not clear about. I'm not sure what
< > security needs you would be addressing with an encrypted disk?
< 
< My own.  I want security to become common place.  I want all disks
< to become self encrypted processes.  I want people to use this
< stuff because it asks nothing more than a password from them
< when their machine starts up.  When it gets to be that transparent
< and that easy to use, then people will use it far more than they
< do today - even if reluctantly.  I want security USED by all.  I want
< people to become so used to having it, that they will cry if they lose
< it.  Then the next step is building some type of on board encryption
< onto every network card or replacing the entire TCP/IP with TCP/SIP
< (secured internet protocol) - a network protocol based upon encrypted
< traffic.
< 
< It is for my security needs - I want to see this next evolutionary
< step in computers to take place ASAP all over the world.  I want
< so much security to transpire that any wire tap on the internet
< is a waste of money and time - by anyone and everyone.
< 
< Privacy is not something we enjoy because most people don't use it
< because most people don't know how or don't want to bother.  I want
< it everywhere.  I want to be part of it everywhere.  And I want to
< make the excuses drop away quickly and effortlessly.  I want there
< to be absolutely no reason for a person NOT to encrypt his disk from
< end to end.  That is my goal.
< 
< That is the security need I am addressing.  Make it everywhere,
< transparent, and extremely simple to employ.  Then people will use
< it and those seeking to gain access to confidential data will find
< all of us in a new era - an era where privacy prevails.
<


But for access points to information that can be protected in a physical
way I still prefer it that way. I would like a double electric fence
around my computer, 100 yards of mine field in between and armed security
guards all around. As for the hard disk I would like a lock on it that
would block any data transfer if not open not just encrypt it. And just in
case someone trying to take the disk apart I would like a small explosive
charge that would blow the platters to dust. 

 
Chris T

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: General Question on cryptography
Date: Fri, 14 Jul 2000 18:58:06 +0200



John Savard wrote:

> Cryptography as it exists today has been shaped by influential writers
> on the subject. Auguste Kerchoffs made a list of six characteristics
> the ideal cipher should have. One of them is that a cipher's easily
> changeable key - rather than the algorithm itself - should be the
> source of its security.
>
> There are good reasons for this. One key can be easily replaced by
> another, if someone has made a mistake (i.e. losing their password
> which was written down). But if someone finds out your clever secret
> algorithm, it takes longer to think of a new idea just as clever. So
> the idea is that keys are replaceable, but algorithms should be good
> enough that they can be kept around for a while.

I may be mentioned that an encryption system may have parameters
so that the key may affect these to the extent of determining its
structure dynamically, e.g. determining the component ciphers in multiple
encryptions. But, taking a global viewpoint, despite such dynamics there
is still one single (fundamental) algorithm involved, the knowledge of
which is conservatively assumed to be fully known to the opponent and
hence belongs to his fixed and invariant asset of knowledge. Whether he
is able to crack the system is of course an entirely another question.
One author of a paper, though, has the opinion that under certain
circumstances the assumption that the opponent has knowledge of the
algorithm could be weakened. I gave a citation of that some time back.

M. K. Shen


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

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Cryptographic Camouflage
Date: Fri, 14 Jul 2000 09:49:13 -0700

> So the theory is, that the attacker can get D, but we hope to prevent
> an off-line guessing attack on the PIN (to acquire d, and therefore
> be able to pretend to be the client) because the attacker does not
> know e (only E)?
Correct.

>
> But what's to stop the attacker from capturing the challenge, and
> the client's first response (C+padding)^d, and just trying PIN's
> on D until he can replicate the client's response?

The most important protection for that is the random padding, determined
exclusively by the client, with a 1024-bit signature, only 1/6 of the space
is occupied by the known data, that's not enough known data for any attack
on RSA that I'm aware of to be of any real use.

> Um, what I meant, was, what can we do with the authentication?

Right now, there's the plugin for IPlanet, Apache, IIS, Netegrity,
encommerce, etc, and several VPNs.

> Does the client tell us anything, or do we tell the client anything?

The server tells the client the challenge to be signed.

> How do we know that the communication isn't hijacked after the
> authentication?

The protection against that is that everything is sent over an SSL/TLS
connection.

>
> Is the whole thing protected by some secure session in the first
> place?

SSL.

Joe





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

From: [EMAIL PROTECTED] (Mack)
Subject: Re: Idea for CFB-like cipher
Date: 14 Jul 2000 17:15:49 GMT

>After reading the description of the 'Cipher FeedBack' mode of chaining
>for DES, where the last 64 bits of ciphertext were encrypted, and one
>bit of this was XORed with one bit of plaintext to get the next
>ciphertext bit, I came up with the following idea:  Using a small, fast,
>secure keyed hash, do something similar.  CFB in DES is slow and
>inefficient, but that's because DES is designed for 64 bit output; we
>can easily make a hash that is designed to have an 8 bit output.
>
>This has probably been done before, but who knows?
>
>IV = initialization vector.
>PT[0..] = plaintext
>CT[0..] = ciphertext
>H_K = a keyed psuedorandom function {0,1}^(8N) -> {0,1}^8
>
>Algorithm:
>CT[-N .. -1] = IV
>CT[i] = PT[i] XOR H_K( CT[i-1 .. CT[i-N] )
>

The MDC-MD5 use the same method but with MD5 as the
hash function.

This is also similar in structure to the SCOTT ciphers
as well as my X8 series which is based on the same idea.

Only those ciphers use a truly shuffled lookup table rather than
a computed function and have multiple rounds of chaining. M8 the
only secure (so far 3 years) variant of the X8 series also adds
a round key at the begining of each block and uses a modified
chaining method.

>The H I would use is more-or-less grabbed from lja1:
>
>/* K is the key, in is the input, N in the size */
>/* K is a shuffled array 0..255, which has been */
>/* changed so that for all i, K[i] != i */
>char H(char *K, char *in, int N) {
>       int i, out;
>       for( i = out = 0; i < N; ++i )
>               out = key[out+key[in[i]]];
>       return (char)out;
>}
>



>
>-- 
>This is the signature worm.
>Help me spread by appending me to your signature.
>
>This is the signature worm.
>Help me spread by appending me to your signature.
>
>This is the signature worm.
>Help me spread by appending me to your signature.
>
>This is the signature worm.
>Help me spread by appending me to your signature.
>
>This is the signature worm.
>Help me spread by appending me to your signature.
>
>
>
>
>
>
>
>
>


Mack
Remove njunk123 from name to reply by e-mail

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

From: "Bob Billing (AKA Uncle Bob)" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Fri, 14 Jul 2000 18:19:47 +0100

Phil Britton wrote:

> You mean the sort of country that Jack Straw is trying to turn Britain into

 Trying?

 Seriously though I've been following this with some interest, as an
encryption system like this would enable binary files to be encrypted in
transit, and to be given a "watermark" which could be used to prove
fairly conclusively which file was which. I may have a commercial use
for this.

-- 
I am Robert Billing, Christian, inventor, traveller, cook and animal
lover, I live near 0:46W 51:22N.  http://www.tnglwood.demon.co.uk/
"It burned me from within. It quickened; I was with book as a woman
is with child." CS Lewis - Till we have faces, Ch 21.

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

From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Cryptographic Camouflage
Date: Fri, 14 Jul 2000 11:15:44 -0600

Joseph Ashwood wrote:
<snip>
> >
> > Is the whole thing protected by some secure session in the first
> > place?
> 
> SSL.

Oh.  But in that case, I'm not clear on why RSA is involved at
all.  If we trust SSL, why couldn't the client just send his
PIN, which the server checks?  I think you already said that
the server learns the PIN when setting up the account.  And
because D is not protected, the PIN is the only thing that
the client needs to know, to prove who he is.

JM

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

From: Greg <[EMAIL PROTECTED]>
Subject: Win2000 Encryption
Date: Fri, 14 Jul 2000 17:18:49 GMT

I tried out the Win2000 encryption property on a file and found that
the file does not appear to be encrypted even though the attribute
says it is.

And what is more odd is that there is no password provided to me.

Can anyone explain what is happening?  Do I need to install some
software component to make this work or am I doing something wrong?


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