Cryptography-Digest Digest #46, Volume #11 Thu, 3 Feb 00 17:13:01 EST
Contents:
Specific Intelligence Skills ... and fuck the USA ... (Markku J. Saarelainen)
Re: Suitable hash for this application - in the public domain? ("Michael Scott")
Re: Jaws Technologies' L5 Data Encryption Algorithm? ("Trevor Jackson, III")
Re: How to password protect files on distribution CD (Eric Lee Green)
Re: need help with a basic C++ algorithm ("Trevor Jackson, III")
Re: NIST, AES at RSA conference (Shawn Willden)
Re: Court cases on DVD hacking is a problem for all of us (Eric Lee Green)
Re: How to password protect files on distribution CD (Sander Vesik)
Re: password encryption/decryption (Eric Lee Green)
Re: password encryption/decryption (Eric Lee Green)
----------------------------------------------------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia
Subject: Specific Intelligence Skills ... and fuck the USA ...
Date: Thu, 03 Feb 2000 21:01:39 GMT
Specific Intelligence Skills
1. Presenting Intelligence
2. Specific Data Collection Methods
3. Quantitative and Qualitative Analysis Skills
4. Market Research Skills
5. Mathematical Skills
6. Interviewing Skills
7. Intelligence Classifications
8. Intelligence Systems Development Skills
9. Briefings and Demonstrations
10. Intelligence Product Segmentation and Analysis
11. Basic Profiling Skills
12. Source Identification, Analysis and Research
13. Various Dessimination Methods
14. Competitor Analysis and Positioning
15. Tracing and Tracking Methods
16. Compiling, cataloging, identification and library methods
17. Public relations and communication systems
18. Human and executive research techniques
19. War Room Environment and techniques
20. Human Intelligence Support Laws
21. Language Skills
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: Suitable hash for this application - in the public domain?
Date: Thu, 3 Feb 2000 21:11:37 -0000
<[EMAIL PROTECTED]> wrote in message
news:87a4gb$16h$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Albert
> HAVAL has been around since 1982 and is still unbroken as far as I know.
> However, Bart Preneel and other hash experts seem to have ignored it -
> after all Australia is a long way away....
>
Funny you should say that. I was just browsing yesterday through the journal
Electronic Letters in the library, and there was an article describing what
seemd to be a quite damaging attack on Haval. No more details to hand.
--
Mike Scott
=====================
Fastest is best.
MIRACL multiprecision C/C++ library for big number cryptography
http://indigo.ie/~mscott
> Keith
> http://www.cix.co.uk/~klockstone
> ------------------------
> 'Unwise a grave for Arthur'
> -- The Black Book of Carmarthen
------------------------------
Date: Thu, 03 Feb 2000 16:19:26 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Jaws Technologies' L5 Data Encryption Algorithm?
Keith A Monahan wrote:
> And my guess is they probably won't even AFTER the patent.
They have no choice. The purpose of the patent system is to disseminate
inventions widely, so that any proficient practitioner can employ the
invention. In exchange the patent holder gets a limited monopoly.
But no matter what, trade secret protection ceases as soon as a patent issues.
> Although their
> web page says, "Experts tell us it would be secure even if someone found
> out our method", I suspect that they wouldn't want to risk someone
> finding out their algorithm is insecure. And although their page
> leads you to believe they trust their methods -- I doubt they trust them
> enough to let the cryptographic community review it. And see, what they
> don't understand is that with a GOOD solid secure cipher they have
> nothing to fear.
>
> Keith
>
> Trevor Jackson, III ([EMAIL PROTECTED]) wrote:
> : Paul Koning wrote:
>
> : > John Savard wrote:
> : > > ... the fact that they've applied for a patent
> : > > means that eventually they will be able to disclose their algorithm
> : >
> : > No; if they have applied for a patent they can disclose the
> : > algorithm *now*.
>
> : They can, but the need not. If the patent application is rejected they
> : may want to preserve the information.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.unix
Subject: Re: How to password protect files on distribution CD
Date: Thu, 03 Feb 2000 14:13:02 -0700
Vernon Schryver wrote:
> In article <[EMAIL PROTECTED]>,
> Eric Lee Green <[EMAIL PROTECTED]> wrote:
> ]AGH! Please don't do that. Within the past year we have updated major portions
> ]of our corporate network from 10baseT to 100baseT, ...
>
> ]cheapo-cards don't work properly in 100BaseT Full Duplex mode, meaning yet
> ]more cards replaced :-(.
> ]
> ]Our server load is taken up by SCO Unix (being retired) and Linux on Intel
> ]boxes, though we have numerous other platforms in our porting lab. We would
> ]not be pleased if our $30,000 accounting and manufacturing system broke
> ]because we upgraded our server :-(.
>
> So leave the old 10BASE-T card in your server unconnected or connected to
> a little used control or administrative network.
Switched 100BaseT network. A seperate administrative network could be added
via a NAT box but so far we haven't had the need -- the switched network
prevents password sniffing, and half of our employees need access to the
administrative systems so it wouldn't be much of a security help either.
Regarding leaving old cards in machine, I don't know of a reliable way to get
the MAC address of a second card under Linux or SCO Unix. For that matter,
there's "magic" involved in getting the MAC address of the FIRST card.
> - the least inconvenient and unreliable ways to get a MAC address on a
> WIN32 box is to ask for what Microsoft calls a GUI. Think about the
Err, we don't use Windows. We are a Unix and Linux shop.
> - your license may limit the bandwidth or number of network connections
Limit is on # of logged-in users. No problem there. Has nothing to do with
upgrading our internal network, and the (very expensive) package breaking
because of it.
> - there may be things in your $30,000 package that will break for purely
> technical reasons when you add network inferfaces or change their
> nature or speed. (E.g. some of what you wrote about hubs sounds
> inimical to multicasting)
Nope. We run a pure TCP/IP network. We do not run any proprietary protocols
such as IPX or NetBEUI.
> - if the license terms do allow upgrades of your hardware, then your
> vendor will be more than happy to provide a new key based on the
> new identity of your server.
That is the best case. It IS quite irritating to have that happen simply
because I decided to upgrade my network backbone to a faster speed. To say
that I would be upset would be the minimum.
> - for more than 20 years, reasonable computer systems, including all that
> I've been involved in designing, have had appliation-readable serial
> numbers.
That's nice. That doesn't have anything to do with my situation, which is that
MAC addresses are mutable objects on personal computers and thus not suited
for use
> $30,000 package is not already "node locked" to your server using
> the server's software-readable serial number other than its MAC
> address?
Err, as far as I know, our dual Pentium II/Xeon administrative server doesn't
HAVE a software-readable serial number. Though it's from a manufacturer (IBM)
known for doing such things. In any event, Linux has no drivers for reading
such a software-readable serial number (and end-user applications cannot
directly access the hardware under Unix-type operating systems), so I doubt
that it's an issue here.
>
> ]I don't know what my management would do, but I suspect it would NOT be
> ]polite, at a minimum with irate demands that you fix the problem [and possible
> lawsuit filed under state consumer protection laws]
>
> That is an distinctly silly pile of nonsense. I hope it was a
> mistake instead of typical.
Really? What's the deal? I pay $30,000, I expect a service, and my state's
laws say that you are required to grant a service ("implied warranty of
merchantability"), no matter what any contract says. Contract terms which
violate the law are unenforcable, in case you missed that lecture when you
took Business Law 101 in college.
The first thing I would do, of course, would be to notify the vendor that
their program had quit working and ask them to fix the problem. But if this
program is running my business I'm dead in the water until it's fixed. For a
manufacturing firm, that's not small potatoes... I could be losing hundreds of
thousands of dollars per day here. That's plenty reason to get upset.
> protection is stupid. The only people who make the blanket statement that
> all copy protection is bad are those without clues about their own lack
> of clues and those who aren't even honest about their dishonesty.
Well, my employer did not even have license key protection on its product line
for the first 16 years of its corporate life, much less copy protection, and
it doesn't seem to have stopped them from paying my salary :-). Of course,
there's little reason for people to be dishonest about our product line anyhow
-- there's a free alternative ('tar'), it's harder to use but the kind of
people who could crack our license key scheme don't care about that.
> ]If the goal is to keep honest people honest (and really, that's the only
> ]worthwhile goal here), a "normal" license manager which relies on the user
> ]typing in valid license data (valid as checked vs. an RSA public key or a MD5
> ]hashed shared key) will do that, without peeving current and future customers.
>
> What "normal" license manage does not not involve a hardware serial number
> or signature of some kind?
Windows 98? Just about all PC software that I've ever encountered that's
licensed on a per-user vs. per-seat basis?
> The fatal difficulty with any scheme not based on hardware is that it is
> too easy to copy all files of an application, including files containing
> generated hashes. An honest customer that accidentally copies a $30,000
> package onto a new system for a new or spun-off subsidiary or distant
> office, and finds that no new key is required will probably forget to call
> the vendor for another key.
So you say. But there's a couple of things going on here:
1) Usually, if you have an expensive package of that sort, you also have a
service contract. Getting calls from another site is going to be a sure-fired
tip-off that something's gone wrong! In real life that's the primary way we
detect unauthorized copies of our software -- such calls are then forwarded to
Sales in order to outfit the guy with the proper product legal and all.
Undoubtedly there are illegal copies of our software floating around. But
not at
our big customers, all of whom have site licenses with us for a certain amount
of copies
of our software. We operate on the honor system there at the moment, rather
than trying to
create a network license manager that would work on all dozen or so platforms
that we support. See #3 for another issue.
2) If a firm can afford a $30,000 package, it's unlikely that they can afford
to be sued for running an illegal copy of said package. In my experience,
companies are quite paranoid about the expensive stuff.
3) We're not concerned about teenage haxxorr types pirating a $30K package.
They're not going to buy a copy of it anyhow.
> I think that dongles, whether the original on the system bus or connected
> via parallel port, serial port, USB, or in series with the keyboard are
> too much hassle, including too unreliable.
Yet you insist upon using a network card as a dongle?
--
Eric Lee Green [EMAIL PROTECTED]
------------------------------
Date: Thu, 03 Feb 2000 16:27:11 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: need help with a basic C++ algorithm
Adrian DuChant wrote:
> Greetings,
> I am working on a program which will be using clear text files for basic
> data storage,
> I would like to encrypt them and decrypt them at runtime for reading into
> the program so as to not allow someone to tamper with the data held within.
> This only needs to be basic, nothing really intense.
> If some one could please give me a hand (or a snippet of code) to make this
> algorithm it would be most appreciated.
> TIA
> Adrian DuChant.
How proficient are the people who might tamper with the data? There is no
mechanism that can prevent all tampering.
First, as opposed to obscuring the contents of the data you will need to verify
the integrity of the data -- that it has not been tampered with. If this is
the sum total of your interest you do no need to encrypt the data, but simply
add an integrity check.
Checksums are simple integrity checks. Message Authentication Codes (MAC) are
more sophisticated integrity checks.
If you want something really simple just Rot-13 the text (works within the 26
letter of the alphabet). If you want to be ambitious Rot-47 the text (works
within the 94 characters of printable ASCII minus tilde). If the text is
mostly numeric data Rot-5 it within the decimal digits.
------------------------------
Date: Thu, 03 Feb 2000 14:23:44 -0700
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Terry Ritter wrote:
> >The point
> >of using the same key was to allow the stack to be changed frequently.
>
> Such is indeed the goal, but using the same key seems unnecessary. We
> do not generally use the same message key for multiple messages even
> now. Instead, we use a random keying value which probably will not
> re-occur. And we can do the same thing while also changing ciphers.
Okay, okay. It's now clear to me that I don't understand anything about the
way in which you're proposing to stack ciphers. I'll read your web pages
before I comment more.
Shwan.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Court cases on DVD hacking is a problem for all of us
Date: Thu, 03 Feb 2000 14:23:18 -0700
Highdesertman wrote:
> Ok. I yeild the floor to my esteemed newsgroup peers. I seem to be the
> only individual here that sees something wrong in taking that which
> does not belong to you.
Err, I buy a book. I can carry that book to work and read it. I can carry that
book home to read this. I can carry this book on the airplane to London and
read it while in London. I own this book. I do not own the words within this
book, that is, I cannot sell the words within this book (as arranged by the
author, or any "substantially similar" work containing largely the same
content in the same order), but I have the right to read this book in any
context that I wish. I even have the right to sell this book to a used book
shop once I am finished reading it.
You are saying that different standards should apply to DVD disks? You're
saying that I should *NOT* have the right to play a DVD on my Linux machine at
home, even though I own this DVD disk the same way that I would own a book?
You're saying that I DON'T have the right to play this DVD disk on a DVD
player in England (due to Zone Coding), despite the fact that it's perfectly
legal for me to carry my book to England and read it?
Or are you saying that the publisher of this book should be allowed to tell me
that I can only read this book while seated in one chair at home, and am not
allowed to read it on the subway, on the airplane going to London, or while in
London? Yet that's exactly what you're saying about DVD's. Which is silliness
on the face of it.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Sander Vesik <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: How to password protect files on distribution CD
Date: 3 Feb 2000 21:22:30 GMT
In sci.crypt John Savard <[EMAIL PROTECTED]> wrote:
> On Sat, 29 Jan 2000 00:20:40 GMT, [EMAIL PROTECTED] wrote, in part:
>>We have developed some software and we want to ship them on CD
>>in encrypted form to our customers. Then we want to give them some keys
>>to decrypt the software. We should be able to generate the passwords
>>for our customers. We might want to put further restrictions on
>>encryption and authorization in the future but not now.
>>What software do I need to use for this? If this is irrelevant to this
>>group, please point me to the correct one.
> The basic idea is that while the program on the CD-Rom is encrypted
> with one, fixed key, you can generate a key for an individual customer
> which, when combined with a serial number, or the customer's name,
> yields the required decryption key.
> This means that if the security program also on the CD-Rom is not
> disassembled, a customer would have to give away two pieces of
> information to let someone else use a copy of the CD-Rom, one of which
> would identify the customer.
Attacking such a scheme given "some" pairs of user names / licence codes
is the same a known plaintext attack. The cracker will later derive a new
fully fictional pair that will both pass and give no information about
who provided the original pairs (consider the case of a stolen or
snooped pair).
> Unfortunately, disassembling programs is much easier than cracking
> encryption, so the level of security you can achieve this way is
> somewhat limited.
That aswell.
> John Savard (teneerf <-)
> http://www.ecn.ab.ca/~jsavard/index.html
--
Sander
There is no love, no good, no happiness and no future -
these are all just illusions.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: password encryption/decryption
Date: Thu, 03 Feb 2000 14:28:48 -0700
[EMAIL PROTECTED] wrote:
> My application is a net-based app. I need a good
> algorithm to encrypt/decrypt the password the
> user uses to login to my application on the web.
>
> The algo. should be very simple and foolproof. I
> am unable to find it in this site. This is urgent.
> I came across some free algos. which are not
> patented but they are somehow difficult to
> understand. Because I will have to justify my
> choice.
The "standard" protocol, not involving any encyption, is to store a one-way
(non-reversible) hash of the password on the server. This way, if someone
compromises the password file on the server, it's no big deal.
How the communications works:
The server sends a random salt value (usually 128 to 168 bits in length) to
the client that wishes to log in.
The client sends a MD5 or SHA1 hash value to the server , a hash
that has hashed into it:
a) all characters of the password or passphrase, and then, the resulting
hash is
hashed with
b) all characters of the 'salt' value.
The server retrieves the one-way hash from its database, and adds in the
'salt' value.
The resulting hash is then compared with the one sent by the client. If the
two match,
the client is authorized. If the two do not match, the client is NOT
authorized.
Note that no passwords are ever sent across the network. Also note that this,
like many such schemes, is succeptible to dictionary attacks. See any good
book about encryption to find out about dictionary attacks, replay attacks,
and other such attacks that you need to be aware of.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: password encryption/decryption
Date: Thu, 03 Feb 2000 14:30:25 -0700
Steve Sampson wrote:
>
> Use LDAP. Lightweight Directory Access Protocol.
Has LDAP added a cryptographically-secure method to its authentication scheme?
Is this available in widely-available implementations like, e.g., OpenLDAP?
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
** 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
******************************
