Cryptography-Digest Digest #836, Volume #9 Tue, 6 Jul 99 20:13:03 EDT
Contents:
ANNOUNCING TINYSAFR ("Robert G. Durnal")
Crandall Papers ??? (Randy Given)
Re: I don't trust my sysadmin ("David N. Murray")
Re: I don't trust my sysadmin (Patrick Juola)
Re: Keeping File Formats Safe (Medical Electronics Lab)
Re: Standard Hash usage ([EMAIL PROTECTED])
Re: I don't trust my sysadmin (Terje Mathisen)
Re: Keeping File Formats Safe (Bradley Yearwood)
Re: Keeping File Formats Safe (William Tanksley)
Re: Crypto Books on CD-ROM (JD)
Re: DES-NULL attack (Xcott Craver)
Re: I don't trust my sysadmin (Scott Gifford)
Re: DES-NULL attack (Xcott Craver)
Re: Keeping File Formats Safe (Kile Mornay)
Re: The One-Time Pad Paradox (William Tanksley)
----------------------------------------------------------------------------
From: "Robert G. Durnal" <[EMAIL PROTECTED]>
Subject: ANNOUNCING TINYSAFR
Date: Tue, 6 Jul 1999 13:20:30 -0400
ANNOUNCING TINYSAFR, a CFB version of the SAFER+ AES Candidate
SAFER+, the latest of CYLINK Corporation's SAFER series of ciphers,
features 128-bit fixed block size and key sizes of 128, 192, or 256 bits. The
cipher is not a Feistel type cipher, but instead mixes addition, XOR (addition
mod 2), exponentiation, logarithmic conversion, and Hadamard matrix multiply
with the number of rounds dependent on the key size. And thanks to CYLINK, the
cipher is in the public domain, completely free of patent or copyright issues.
Like my other TINY series of ciphers, this uses a DOS shell for CFB
block chaining mode, based heavily on the work of Fauzan Mirza in his TinyIdea
cipher. And like TinyIdea, the executable portion of the cipher will fit in a
single disk sector (actually, 470 bytes). The distribution file is assembled
for 128-bit keys, but simply changing the ROUNDS variable to 0Ch for 192-bit
or 10h for 256-bit keys is simple. The source is compatible with Eric
Isaacson's A86 compiler, available as shareware from www.eji.com.
Because the Bernstein decision has been appealed, and only applies to
the California circuit anyway, EAR applies, and the distribution file has been
encrypted (PGP 2.6.3a conventional encryption) and to decrypt you must send me
your PGP public key (RSA only, and I found out the hard way that it cannot have
any D-H signatures) and I will send you the decryption key along with the
instructions on how to use it.
Try this cipher and enjoy.
My home page URL=http://members.tripod.com/~afn21533/ Robert G. Durnal
Hosting HIDE4PGP, HIDESEEK v5.0, PGE, TinyIdea (link) [EMAIL PROTECTED]
and BLOWFISH in both Windows and mini-DOS versions. [EMAIL PROTECTED]
EAR may apply, so look for instructions.
------------------------------
From: [EMAIL PROTECTED] (Randy Given)
Subject: Crandall Papers ???
Date: 06 Jul 1999 18:05:29 GMT
Where can I get the Crandall papers:
- "Discrete Weighted Transforms and Large-Integer Arithmetic"
- "Irrational-base Discrete Weighted Transform"
Thanks!
Randy Given
[EMAIL PROTECTED]
http://members.aol.com/GivenRandy
public key at http://members.aol.com/GivenRandy/pgpkey.asc
------------------------------
From: "David N. Murray" <[EMAIL PROTECTED]>
Subject: Re: I don't trust my sysadmin
Date: Tue, 06 Jul 1999 19:11:46 GMT
Hmmm, I don't seem to be having much luck.
Let's try a real-world example and see if that helps:
My sysadmin is *not* allowed into my payroll database,
however, I need to run a job every night against the
payroll database (let's say a program that e-mail's
employee review notifications to managers).
Is there anyway to secure the 'review notifier' program
against illicit access by the sysadmin? The only
solution I have been able to come up with is that
the HR dept hires their own sysadmin (whom they do
trust) and manages the server outside of MIS.
Any solution I come up with, generically, seems
to revolve around obscurity, which (I'm told) is
not security, at all.
Thanks for the input,
Dave Murray
Eric Hambuch wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > "David N. Murray" <[EMAIL PROTECTED]> wrote:
> > > Greetings, all:
> > >
> > > I'm in search of a protocol to implement the following scenario:
> > >
> > > I have an automated task that connects to a database.
> > > The database requires a username/password combination.
> > > I need to store the username/password with the automated task.
> > > My system administrator (who needs to be able to read the
> > > automated task to do backups) is not authorized to access
> > > the database. (Protecting the database is not my concern.
> > > Just protecting the automated login.)
> >
> > Hash the password and store the hash on the protected side. So you
> > type the password on Machine A, it gets hashed goes thru the middle man
> > and compared with the HASH on Machine B.
> >
> > Unless the sysadmin can get access to stuff you type (which I doubt
> > they can) they will not be able to tell what the password was.
>
> As far as I know, "root" can access everything you type on the console
> ?!
>
> Eric
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: I don't trust my sysadmin
Date: 6 Jul 1999 15:19:55 -0400
In article <[EMAIL PROTECTED]>,
David N. Murray <[EMAIL PROTECTED]> wrote:
>Hmmm, I don't seem to be having much luck.
>Let's try a real-world example and see if that helps:
>
>My sysadmin is *not* allowed into my payroll database,
>however, I need to run a job every night against the
>payroll database (let's say a program that e-mail's
>employee review notifications to managers).
>
>Is there anyway to secure the 'review notifier' program
>against illicit access by the sysadmin? The only
>solution I have been able to come up with is that
>the HR dept hires their own sysadmin (whom they do
>trust) and manages the server outside of MIS.
>
>Any solution I come up with, generically, seems
>to revolve around obscurity, which (I'm told) is
>not security, at all.
Not under Unix, or indeed under most systems.
Think of it this way -- what's to prevent the sysadmin from pulling
the disk, physically, out of your machine, byte-by-byte copying it
on a PC box and then going over the data at his leisure?
There *are* operating systems available that prevent this; they
tend to be sold to the DoD and almost no one else.
-kitten
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Keeping File Formats Safe
Date: Tue, 06 Jul 1999 12:31:46 -0500
Ronald Klazar wrote:
> I would like to prevent other people from discovering the format of the
> data files for my application. Is there a sound method for implementing
> a system such as this when both the application and data file are stored
> locally?
>
> Hard coding an encryption key in the application is not feasible because
> reverse engineering presents a way to uncover the key.
If the data exists on the users machine, they can reverse engineer it.
If the application exists on the users machine, they can watch it and
read the data file using a debugger. It's more work if you add more
steps in the process, but it is still possible to reverse engineer
the data.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Standard Hash usage
Date: Tue, 06 Jul 1999 20:25:11 GMT
In article <[EMAIL PROTECTED]>,
John Myre <[EMAIL PROTECTED]> wrote:
> > That function, hash = sha1(P) || sha1(P || sha1(P)), limits the
> > entropy to no more than 160-bits, when P has more than 160-bits
> > of entropy.
>
> I don't see why this is so.
>
> Can you explain it, or point me at the right place to
> read about it? Does it have anything to do with SHA in
> particular, or the order of the appending, or is it a
> general fact about hash functions?
>
He is not exactly correct. For any HASH output, the output should be a
random function of the input. Guessing the output of SHA requires O
(2^159) on average. You cannot say that there is more then 160-bits of
entropy because the output is limited...
However when used in counter mode (and since HASHes are not functions)
there is 160-bits per output. As long as the password has at least 160
bits of entropy it will work. This means to guess the first output
will require on average 2^159 tries... To guess the next you still have
the password to guess.
Basically this mode of operation is heavily dependant on the length of
the password and it's quality. You will never have in total more
entropy then their is in the password, however simply guessing the hash
output will require more effort then guessing the passwd...
enough of this. It's OT anyways...
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: I don't trust my sysadmin
Date: Tue, 06 Jul 1999 22:31:15 +0200
David N. Murray wrote:
>
> Hmmm, I don't seem to be having much luck.
> Let's try a real-world example and see if that helps:
>
> My sysadmin is *not* allowed into my payroll database,
> however, I need to run a job every night against the
> payroll database (let's say a program that e-mail's
> employee review notifications to managers).
>
> Is there anyway to secure the 'review notifier' program
> against illicit access by the sysadmin? The only
> solution I have been able to come up with is that
> the HR dept hires their own sysadmin (whom they do
> trust) and manages the server outside of MIS.
>
> Any solution I come up with, generically, seems
> to revolve around obscurity, which (I'm told) is
> not security, at all.
The only real solution (AFAIK) to this problem is to use
application-level strong crypto on all the data in your database, this
way the server and it's disks and backup tapes becomes pretty much
worthless for anyone without the proper keys.
The problem is that I've been unable to find anyone who can deliver a
product like this. :-(
It is easy enough when I have full control of the application, but much
harder when it has to work on generic client-server apps.
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: [EMAIL PROTECTED] (Bradley Yearwood)
Subject: Re: Keeping File Formats Safe
Date: 6 Jul 1999 21:19:18 GMT
In article <[EMAIL PROTECTED]>,
Ronald Klazar <[EMAIL PROTECTED]> wrote:
>Hello,
>
>I would like to prevent other people from discovering the format of the
>data files for my application. Is there a sound method for implementing
>a system such as this when both the application and data file are stored
>locally?
The best way to prevent this is to keep the application locked up on
your own machine and not attempt to sell it.
I look forward to the day when standards of auditability and fiduciary
responsibility finally recognize the risks of opaque proprietary data
formats. No prudent person should allow their vital business data to be
taken and held hostage.
------------------------------
From: [EMAIL PROTECTED] (William Tanksley)
Subject: Re: Keeping File Formats Safe
Reply-To: [EMAIL PROTECTED]
Date: Tue, 06 Jul 1999 21:24:51 GMT
On Tue, 06 Jul 1999 13:06:36 +0200, Ronald Klazar wrote:
>Hello,
>I would like to prevent other people from discovering the format of the
>data files for my application. Is there a sound method for implementing
>a system such as this when both the application and data file are stored
>locally?
What sort of enemies do you have?
I wanted to protect a game's files from cheaters. So I started by adding
a powerful cheat mode to the game, with the intent of making anything
possible except getting onto the real hiscores list (cheaters have their
own hiscores list).
Once I get a good start on that, I'm going to obfusicate and chaff&winnow
the save files so that it's harder to break that one last "mark of cain"
which keeps people on the cheater's list.
The goal here is not to prevent cheating, but rather to divide cheaters
into two categories: game cheaters (go ahead, you can't ruin anyone's fun
but your own) and social cheaters (I can't stop them, but their community
can).
So, are you fighting cheaters or bandits?
>Ronald Klazar..
--
-William "Billy" Tanksley
------------------------------
From: JD <[EMAIL PROTECTED]>
Subject: Re: Crypto Books on CD-ROM
Date: Tue, 06 Jul 1999 21:31:12 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bruce Schneier) wrote:
> It's worth buying the new version of the CD-ROM. All the books are in
> pdf format, and the hyperlinking actually works. I found the first
> version almost useless, but I like this version.
Alas, I was one of the "early adopters" that spent 6 months waiting
for the CD to be shipped after they prematurely took my order, only
to find that it was hamstrung by a Windoze-only reader so buggy as
to be useless.
Has anyone been able to talk DDJ into an "upgrade" to the new disc
which apparently works? I complained to the publisher a while back,
only to get finger-pointing to the software vendor, from whom I got
no response. :(
(I also own several of the volumes in hardback, which as has been
mentioned in other posts, might be the preferred media for just
reading cover-to-cover. But the ability to search and cross-reference
quickly when you know what you need would be valuable.)
--JD
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: DES-NULL attack
Date: 6 Jul 1999 22:07:14 GMT
S.T.L. <[EMAIL PROTECTED]> wrote:
><<billion Gigabytes>>
>
>Why not say the real word? People work with gigabytes all the time, so a
>billion doesn't seem like that much. However, one Terabyte seems humongous.
I disagree: the fact that people work with gigabytes all the time
makes it much easier to _visualize_ a billion gigabytes. An
Exabyte is more likely to just be another huge number.
If you can fit a terabyte in a cubic foot of hard drives, then
the Alex DES-NULL attack machine could be crammed into a cube
maybe 10 stories high? Without Power or cooling or Jeffries
tubes. That's pretty much what Alex is proposing to implement
his chosen plaintext attack. On DES! How big is Deep-Crack
in comparison?
Does Alex post these terrible flaws in RSA (and now DES)
to drive people to use Alex Encryption instead? When people
find out that the attacks boil down to Alex not realizing
just how big 2^64 is, wouldn't they end up using anything
*but* a cipher of his design?
------------------------------
Subject: Re: I don't trust my sysadmin
From: Scott Gifford <[EMAIL PROTECTED]>
Date: 06 Jul 1999 18:39:08 -0400
"David N. Murray" <[EMAIL PROTECTED]> writes:
> My sysadmin is *not* allowed into my payroll database,
> however, I need to run a job every night against the
> payroll database (let's say a program that e-mail's
> employee review notifications to managers).
>
> Is there anyway to secure the 'review notifier' program
> against illicit access by the sysadmin? The only
> solution I have been able to come up with is that
> the HR dept hires their own sysadmin (whom they do
> trust) and manages the server outside of MIS.
We would handle this with our database by creating a procedure that
gathers only the data needed, then creating a user that is only
allowed to run that query. Then you can store that username and
password on the system, and if the sysadmin takes advantage of it, all
he can do is run the same query. I don't recall what database you're
using, but I would think any modern database would be able to do this.
I think this was suggested here earlier, actually. Does this solve
your problem?
=====Scott.
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: DES-NULL attack
Date: 6 Jul 1999 22:42:54 GMT
Patrick Juola <[EMAIL PROTECTED]> wrote:
>Xcott Craver <[EMAIL PROTECTED]> wrote:
>> Alex is notorious for these kinds of attacks, apparently
>> unaware that they amount to nothing more than brute-force.
>
>A very selective and intelligent kind of brute force, however....
How so? Brute-force machines exist which did not require
a city block of space and possibly lifetimes to construct.
Alex's attacks are usually many times worse than even
unoptimized brute force; his RSA-NULL attack, for instance,
is exponential complexity, whereas simply factoring the
key is sub-exponential.
>Except that NULL blocks are rather common in some sorts of files; if
>what he's looking for are executable files, for intstance, those tend
>to have lots of zero blocks lying around. Similarly, if I wanted to
>find English text, the string " in the " is exactly sixty-four bits
>in length (i.e. one DES block) and occurs with much greater frequency
>than 1 in 10 quadrilliion.
...in uncompressed text. Even if compressed files tend to
be littered with 0 blocks, I'd want a small failure rate
before sorting 2^56 plaintexts (how long would that take?
Not storage in RAM, storage on disk or backup tape?
It's fair to assume that megabytes or gigabytes can be
read at once into ram for processing, is there a sort
method ideal for this kind of large-scale sort?)
and finding a football stadium to hold them.
> -kitten
------------------------------
From: [EMAIL PROTECTED] (Kile Mornay)
Subject: Re: Keeping File Formats Safe
Date: Tue, 06 Jul 1999 23:04:44 GMT
[EMAIL PROTECTED] (Bradley Yearwood) wrote:
>I look forward to the day when standards of auditability and fiduciary
>responsibility finally recognize the risks of opaque proprietary data
>formats. No prudent person should allow their vital business data to be
>taken and held hostage.
Agreed, but this sounds like a case where the author is supplying his own
data and doesn't want it grabbed and used elsewhere. For example, a
dictionary program that supplies definitions and pronunciations of words
could benefit from protection like this.
--
"Kile Mornay" better known as [EMAIL PROTECTED]
0123 456789 <- Use this key to decode my email address.
Fun & Free - http://www.5X5poker.com/
------------------------------
From: [EMAIL PROTECTED] (William Tanksley)
Subject: Re: The One-Time Pad Paradox
Reply-To: [EMAIL PROTECTED]
Date: Tue, 06 Jul 1999 23:21:34 GMT
On Mon, 05 Jul 1999 15:51:35 +0200, Dr.Gunter Abend wrote:
>Jim Gillogly wrote:
>In order to avaoid this kind of leak of the OTP technique
>you should not apply it to ASCII texts, but compress them
>beforehand. Usually, the bit frequencies in compessed files
>are fairly uniform.
Always compress before you encrypt (unless your data is random, in which
case you don't need to encrypt ;-).
But seriously, if you're compressing, you're not going to be able to leak
useful info. Even when you DO get a string of seven zero bytes only junk
will show though, even to the most dedicated psychic.
>But: this amount of "information" which
>is inherent to OTP of ASCII texts, is usually not considered
>a (theoretical) problem.
Bingo. Nor a practical one. Compression is still economical, but it
doesn't and can't increase the security. OTP has _perfect_ security.
>Ciao, Gunter
--
-William "Billy" Tanksley
------------------------------
** 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
******************************
