Cryptography-Digest Digest #764, Volume #10 Sat, 18 Dec 99 23:13:01 EST
Contents:
Re: A dangerous question (Wim Lewis)
Re: 'Simple' password storage (Paul Johnstone)
Re: More idiot "security problems" (Xcott Craver)
Re: 'Simple' password storage (Paul Johnstone)
Re: 'Simple' password storage (Paul Johnstone)
Re: Ellison/Schneier article on Risks of PKI ([EMAIL PROTECTED])
Re: Microsoft- PKI/E-comm Director Opening ([EMAIL PROTECTED])
Re: A dangerous question (Awopadom)
Re: More idiot "security problems" (Xcott Craver)
Re: Sorry, I was unclear... (Omar N. Ikley)
Re: 8192bit Encrypt - Easy ! (William Rowden)
Re: Euclid Algorithm ("Miryadi")
Re: First Bijective Arithmetic Compression (William Rowden)
Re: First Bijective Arithmetic Compression (Tim Tyler)
Re: First Bijective Arithmetic Compression (Tim Tyler)
Re: NSA competitors (Tim Tyler)
Re: 'Simple' password storage (Eric Lee Green)
Re: Sorry, I was unclear... (Eric Lee Green)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Wim Lewis)
Subject: Re: A dangerous question
Date: 19 Dec 1999 00:25:24 GMT
In article <[EMAIL PROTECTED]>,
Johnny Bravo <[EMAIL PROTECTED]> wrote:
>On Mon, 29 Nov 1999 23:13:20 -0800, Jim Nelson
><[EMAIL PROTECTED]> wrote:
>>Saying this alone constitutes an illegal contract is like betting on the
>>Lakers and being arrested for fixing the game.
>
> However there is nothing illegal about the Lakers winning a
>basketball game.
There's nothing illegal about someone dying, either. It's illegal to
kill someone, and it's illegal (I assume) to fix a game.
Having a lot of people bet on the outcome of a Lakers game ends up creating
an incentive for someone to fix the game. Likewise, having a lot of people
bet on the death-date of a public figure ends up creating an incentive for
someone to either kill *or* preserve that person's life. Regardless of what
the desires of the individual betters are.
--
Wim Lewis * [EMAIL PROTECTED] * Seattle, WA, USA
------------------------------
From: Paul Johnstone <[EMAIL PROTECTED]>
Subject: Re: 'Simple' password storage
Date: Sun, 19 Dec 1999 00:31:40 +0000
Hi Robert,
Checked that out. Thanks. It looks a lot more promising that everything else
I have found so far.
Kindest regards,
-Paul
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: More idiot "security problems"
Date: 19 Dec 1999 00:18:36 GMT
Johnny Bravo <[EMAIL PROTECTED]> wrote:
>
> Not all programs, just programs that store encrypted data with an
>internal password rather than a user supplied one.
Not even this is true. If I have a program which encrypts
data using a key hard-coded into the program, you are not
necessarily able to unencrypt the data from reverse-engineering
the program.
Now, if the program is capable of decrypting the data too,
then you have a problem.
-S
------------------------------
From: Paul Johnstone <[EMAIL PROTECTED]>
Subject: Re: 'Simple' password storage
Date: Sun, 19 Dec 1999 00:33:59 +0000
Hi John,
Been using Netscape since the dawn of time (well, almost) and have JS figured
out fully. I was really hoping for something a little more complex than an
XOR.
Thanks for your reply :)
-Paul aka Amos
------------------------------
From: Paul Johnstone <[EMAIL PROTECTED]>
Subject: Re: 'Simple' password storage
Date: Sun, 19 Dec 1999 00:37:42 +0000
Hi Jerry,
Where do I find all of the AES entrants source code? I am relatively new to
cryptography, but a firm programming background makes it a lot easier to
understand what you are talking about.
I have been using PGP for a while too, although more for just use and not
understanding fully the entire source line for line.
Thanks for your guidance,
-Paul 'Amos' Johnstone
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Ellison/Schneier article on Risks of PKI
Date: Sun, 19 Dec 1999 00:25:30 GMT
> Which is why so much work goes toward protecting the CA's private
key. As the
> root of PKI trust, things like physical, personnel, and infosec
policy applied
> to your CA tell the rest of the world how much trust they can put in
your PKI's
> work products.
>
Yes you are right. But, once again, PKI is fundamentally flawed. I mean
how many PKIs are there? Loads - that means loads of roots. What the
probability that one of these roots will have their key compromised? I
think it's bound to happen somewhere along the lines.
Further still, many PKIs have multiple CA's - all it takes is one of
these CA's to have their key compromised and the rest of the chain
below that CA will be buggered - and that CA may only find out when
it's too late.
In real life everyone tries to follow strict security policies and
procedures, but at the end of the day these systems nearly always get
broken (if they didn't, then I would not be employed!!). With PKI,
having so many links, there are abundant opportunities to attack,
making it a step backwards rather than forwards in the security world.
DW
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Microsoft- PKI/E-comm Director Opening
Date: Sun, 19 Dec 1999 00:29:05 GMT
I think this IS microsoft as only they would be silly enough to invest
in PKI.
The loopholes in PKI + The loopholes in Microsoft = ultra security
In article <83f6hu$cds$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Keith A Monahan) wrote:
> If this is from Microsoft, then Gates must own deja news, because I
can't
> think of any other reason for one of the hughest computer companies
to use
> dejanews to post from.
>
> Keith
>
> David A Molnar ([EMAIL PROTECTED]) wrote:
> : [EMAIL PROTECTED] wrote:
> : > I hope I am not breaking group etiquette by
> : > posting this here, but I think it is highly
> : > relevant and some of you may be interested...
>
> : You know, we have no good reason to believe this is
> : really from Microsoft. Why not start your PKI effort
> : by signing this message ? :-)
>
> : -David
> : (no, you have no reason to believe this is from me, either)
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Awopadom <[EMAIL PROTECTED]>
Subject: Re: A dangerous question
Date: Sun, 19 Dec 1999 00:44:37 +0000
Hmm, that made me think.
In a way - the individuals make up the collective will of soceity - so if the
collective will of society is to be changed, so is the will of the individuals.
I only wish that my individual will to lock up Gloria Hunniford in an
underground prison became part of societies collective will. I can not stand
that woman!
-Amos
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: More idiot "security problems"
Date: 19 Dec 1999 00:39:42 GMT
Eric Lee Green <[EMAIL PROTECTED]> wrote:
>
>My complaint is about "security experts" who come out with rash statements
>intended to scare people for purposes of publicizing their "security firm"
>(usually one-man operations operating out of rented offices in Podunk,
>Kansas).
Just how much do you actually know, or think you know, about RST?
>The NSA Key scare was one such, and this Netscape Key thing is yet
>another one.
Plain and simple, this weak encryption is a serious flaw.
I don't know where your copy of Netscape is on your hard drive,
but I do know where that registry entry is. It's much easier
for a hostile program to grab that information than it is
for it to sift key info out of Netscape's binary. Extracting
the password is much easier, easy enough for a program or virus
to do, easier than reverse-engineering code, easier than
waiting for someone to connect to an IMAP server and sniff.
The NSA key was also a serious flaw, because it allowed
someone to replace part of the API, by changing the second
key and signing new modules with the second key, all without
invalidating modules signed with the first key. Either-or
situations (hashing a password using two methods, say, or
splitting a password into small chunks and separately encrypting
each chunk) are dangerous in computer security [and are very,
very Microsoft] and NSAKEY was an illustrative example.
>-- Eric Lee Green [EMAIL PROTECTED]
-X
------------------------------
From: [EMAIL PROTECTED] (Omar N. Ikley)
Subject: Re: Sorry, I was unclear...
Date: Sun, 19 Dec 1999 00:56:28 GMT
Paul Johnstone <[EMAIL PROTECTED]> wrote:
>Thanks for your quick feedback. I was, however, a little unclear as to
>exacly what I wanted to use it for.
>Think of programs like WS_Ftp that store the passwords in its .INI file in
>ciphertext. Only WS_Ftp can decode the files (theoretically - although I
>know that this is not the case).
>I want to write a program that stores several passwords as ciphertext in a
>file that can be attacked and distributed until the cows come home, but
>theoretically only the program can decode it, unlike WS_Ftp.
>It is unsuitable to have the user remember passphrases or store keys on a
>floppy etc. It it assumed that only the intended user can run the program,
>or enter a single program "startup" password - before it will decipher
>entries in the .INI file and display the plaintext password.
Bruce Schneier of Counterpane Labs offers a free program called
"Password Safe" here: http://www.counterpane.com/passsafe.html
There was a lot of controversy here recently (which I started) when nobody
could locate the source code for it, but as soon as he became aware, he
promised to release a new version with public source code in the near
future. Meanwhile, you can take comfort in the fact that there isn't a
cryptographer with a better reputation on the entire Internet.
--
"Omar N. Ikley" is actually [EMAIL PROTECTED] (1568 429703).
0123 4 56789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: William Rowden <[EMAIL PROTECTED]>
Subject: Re: 8192bit Encrypt - Easy !
Date: Sun, 19 Dec 1999 00:45:29 GMT
In article <[EMAIL PROTECTED]>, CLSV <[EMAIL PROTECTED]> wrote:
> Glen Bridgland wrote:
>
> > Hi, I new to the group however
How long did you lurk before posting?
> > I am current developing an encryption program
I assuming the "under development" status is the reason the product
cannot actually be ordered--there is no link from the disclaimer
page that I can find.
> > Please read the document and express your thoughts.
Most readers of this group will want to see source code for known
algorithms, and descriptions of unknown algorithms.
> [Please read the FAQ, please read the FAQ, please read the FAQ.]
Do the people that post without reading the FAQ also begin talking
to groups of strangers at cocktail parties without listening to them
first?
> Ok, having thought all that I am a bit curious about Nanosim.
> What is the algorithm?
I can't find a reference to it, either.
The "hacker's challenge" seems a trifle short to me. (It does have
neato characters and stuff, though. :-)) If I knew the reputation of
the designer, gloating would be sufficient motivation; for an unknown,
I'd want prize money.
--
-William
SPAM filtered; damages claimed for UCE according to RCW19.86
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB DA28 379D 47DB 599E 0B1A
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Miryadi" <[EMAIL PROTECTED]>
Subject: Re: Euclid Algorithm
Date: Sun, 19 Dec 1999 08:11:32 +0700
Thanks for all the reply
Best Regards
-- Yadi --
------------------------------
From: William Rowden <[EMAIL PROTECTED]>
Subject: Re: First Bijective Arithmetic Compression
Date: Sun, 19 Dec 1999 01:47:47 GMT
In article <83g6m4$1hfc$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Matt T. who posts out here has a version of what he is calling
> bijective arithmetic compression. It appears to have the property that
> decompress(compress(X))=X and compress(decompress(X))=X for any
> real file X.
What? Someone's using the mathematical term for a function that is both
one-to-one and onto? I'm going to miss "one-to-one," "one-on-one,"
"o-o-o," "1-1," etc. :-)
I must be in a sarcastic mood today. Flame away.
--
-William
SPAM filtered; damages claimed for UCE according to RCW19.86
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB DA28 379D 47DB 599E 0B1A
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: First Bijective Arithmetic Compression
Reply-To: [EMAIL PROTECTED]
Date: Sun, 19 Dec 1999 02:19:38 GMT
Gary <[EMAIL PROTECTED]> wrote:
: You introduce rules [...]
:>You wrote in your rejected ACM paper:
:>What follows is a set of rules that guarantee ''one to one'' compression in
:>a Huffman file where one uses a table of all 256 leaves:
: why are these rules here?
Without them there's the classic Huffman file ending problem - where the
message usually winds up getting padded with non-random stuff.
David's compression completely eliminates this padding - or any other
information not present in the plaintext.
: I'm babbling about the fact that you should trip these rules randomly in a
: legit compression that doesn't require them.
No, he "should" not. His rules about ending files are as good as those
rules can possibly be. Huffman compression *does* require David's rules,
if padding the resulting compressed file is to be avoided. Padding
before enctyption is bad because of the known-plaintext it can provide.
: Otherwise their non-tripping would tip off an analyst to a legit
: decompression.
Nope. How does than analyst detect which "rules have been tripped" in the
first place?
: Anyway it's academic as your compression is little more than a two way
: process an analyst has to go thru before getting to the actual information.
No. It's not "academic". You don't even mention the fact that
compression increases the entropy per bit of the message, making analysis
based on regularities in the plaintext more difficult. Nor do you mention
that it can distribute plaintext information over a large region of the
cyphertext. In fact, one is left wondering if you understand why
compression before encryption is a good idea at all.
: People are better off adding more rounds to their cipher or doing loads of
: time consuming all or nothing transforms, key strenghening etc.
That depends.
By all means, add more rounds if you feel the need - though at some point
you will probably hit diminishing returns.
Compression is often essential, simply to reduce the bandwidth of the
message. If you are sending images, for example, you /have/ to compress
to avoid being online for the next few hours. The question is often not
/whether/ you should compress - it is /how/ you should compress.
1-1 compression should be no more expensive than other sorts - but
demonstrably avoids a certain type of problem that potentially provides
a handle to analysts.
The addition of such handles is a thing it is desirable to avoid.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Some people are nice to be nasty to.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: First Bijective Arithmetic Compression
Reply-To: [EMAIL PROTECTED]
Date: Sun, 19 Dec 1999 02:27:57 GMT
Gary <[EMAIL PROTECTED]> wrote:
: Compression and encryption are seperate subjects and mixing the 2 just
: creates a headache when analysing the security of such a scheme.
Nonsense. Compression is a significant component of security. Without
compression (or with non 1-1 compression), every message effectively has
some "nearly-known" plaintext.
Why provide food for known-plaintext attacks - when you don't have to?
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
This tagline is immortal.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NSA competitors
Reply-To: [EMAIL PROTECTED]
Date: Sun, 19 Dec 1999 02:37:08 GMT
Crypto-Boy <[EMAIL PROTECTED]> wrote:
:> The Russian one, under the acronym FAPSI, now even has a web site too.
: Where is this web site?
LINKS TO OFFICIAL GOVERNMENT WEB SITES ON SECRET SERVICES AND RELATED AGENCIES
... http://www.hfhrpol.waw.pl/Secserv/links.html ...
Gives the FAPSI site as being here:
http://www.ipaccess.gov.ru/
For some reason, I can't reach the site from my current location...
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
UART what UEAT!
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: 'Simple' password storage
Date: Sat, 18 Dec 1999 20:39:05 -0700
Paul Johnstone wrote:
> If anyone would be kind enough to point me in the direction of a useful
> resource or post a reply containing a pseudo code example, I would be
> extremely grateful.
I first learned about how to store passwords on disk by reading the original
Robert Morris-inspired paper in the Unix V7 manual. The state of the art has
moved on considerably since then.
The current norm appears to be to use a cryptographically secure one-way
digest hash function such as MD5 or SHA1, possibly with a random initial
"salt" value the same size as the block size of the hash function. You then
store the result (and salt, if you added one) in your database. To see whether
a password authenticates the user, you hash it with the salt and compare it
against the database -- you never decrypt the data that is in the database
(you can't, in fact). That way even if the database is compromised, the worst
that can happen is that they can run a dictionary attack against the database
(i.e., try encrypting all words in a dictionary of commonly-used passwords
using the various salt values stored in the database, then comparing that
against all the stored hash values). That's bad, but not as bad as having
passwords that can be decoded to plain text :-(.
If you are sending passwords over a network, the server must provide a random
challenge string to the client, and the client adds that random challenge
string to the hash prior to sending it over the network (a different random
challenge string every time) so that attackers cannot do replay or
substitution attacks. See http://www.counterpane.com for a cryptanalysis of
MSCHAP81 and how Bruce & friends would have done things differently :-). But
again, values can be sniffed off the network and subjected to dictionary
attack.
The next generation of "accepted practice" will probably incorporate public
key encryption to add an additional level of security. You encrypt some value
known to both server and client (may be the MD5 hash of a password +
challenge, or whatever) using the server's public key, then encrypt the result
using your private key. The server then decrypts the value using your public
key, then decrypts the result using his private key. If the decrypted result
matches the expected value, you pass. This stops dictionary attacks, and
assuming that a random challenge is part of the encrypted value, it also
prevents replay attacks. It appears that the RSA patent and U.S. export
restrictions are what is preventing this from becoming the standard -- since
many core Internet protocols are Open Source, they must be provided as source
code. The cryptographic source code needed to do public key authentication is
unexportable (due to the fact that it could be modified to do generalized
encryption/decryption). The RSA patent can be stepped around by using elliptic
curve encryption, but that is a fairly recent event (caused by the expiration
of the original Diffie Hellman and El Gamal patents).
-- Eric Lee Green [EMAIL PROTECTED]
http://members.tripod.com/e_l_green
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Sorry, I was unclear...
Date: Sat, 18 Dec 1999 20:58:30 -0700
Paul Johnstone wrote:
> It is unsuitable to have the user remember passphrases or store keys on a
> floppy etc. It it assumed that only the intended user can run the program,
> or enter a single program "startup" password - before it will decipher
> entries in the .INI file and display the plaintext password.
The user will have to enter a password or passphrase before decrypting the
file in order to make it even halfway secure. Either run the password through
"crack" so that the user can't choose, say, his birthday, as a password (bad
user!), or otherwise require the user to use passwords that are't particularly
succeptible to "dictionary" attacks (a "dictionary" attack is where the
cracker tries all the passwords that are in a dictionary of often-used
passwords in order to "crack" the system -- you'd be surprised at how many
people use their login ID as their password, running "crack" on the password
file for the main server at the office terrifies me!).
Feed your password or passphrase to MD5 (along with a random salt stored
somewhere for later decryption purposes to help head off pre-compiled
dictionary attacks -- at least they'll have to compile the dictionary all over
again to crack your system!) to create a key. MD5 creates 128 bit hashes,
which nicely fits the 128-bit keyspace of AES. Encrypt/decrypt the file using
any of the AES finalists.
http://www.seven77.demon.co.uk/cryptography_technology/Aes/
for source code for the ECB mode, but I recommend that you implement CFB mode
on top of ECB mode and use that to encrypt the file -- see Bruce Schneir's
book "Applied Cryptography", page 200 or therebouts. I personally use TwoFish,
but that's mostly because TwoFish is one of the better documented entrants and
I trust Bruce, for better or worse.
It's really not very difficult, but I do recommend that you study the
appropriate sections of "Applied Cryptography" first. And use standard
algorithms like MD5 and TwoFish (actually, you'd probably be better off with
SHA1 and 3DES at the moment, but I didn't happen to have links to those handy
for this message :-).
Anyhow, good luck!
Eric Lee Green [EMAIL PROTECTED]
http://members.tripod.com/e_l_green
------------------------------
** 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
******************************
