Cryptography-Digest Digest #564, Volume #10 Sat, 13 Nov 99 20:13:03 EST
Contents:
Re: PALM PILOT PGP found here (Keith Monahan)
Re: Public Key w/o RSA? (Scott Nelson)
Re: McAfee Fortress (Tom McCune)
Re: Specific use of a hash function ? (Henri)
Re: PGP ("Markku J. Saarelainen")
Re: RC4 Hardware implementation (Paul Koning)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Coen Visser)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Coen Visser)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("karl malbrain")
Re: SCOTT16U SOLUTION ON THE WEB (Boaz Lopez)
Re: S/MIME plug-in for Eudora? Strong Encryption (amateur)
REVIEW - Vulnerability of "Password Protection" Applets (Michel Dalle)
Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !! (JPeschel)
Re: Need technique for about 24 bytes (Caesar Valenti)
Re: New Way To Prevent Employees From Vandalizing Files ("John E. Kuslich")
Re: Specific use of a hash function ? (Nicol So)
----------------------------------------------------------------------------
From: Keith Monahan <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.sys.palmtops.pilot
Subject: Re: PALM PILOT PGP found here
Date: Sat, 13 Nov 1999 16:55:34 GMT
The extension is ".tgz" which stands for tar gzipped.
So, to expand, first use gzip (gnu gzip), then use tar.
Under unix, commands are "gzip -d filename.tgz", then "tar -xvf filename.tar"
or under windows, most of the popular 'zip' packages support it directly,
Under my WinZip version 7.0, it automatically de-gzip's and de-tars it.
If you need additional help, feel free to email me.
Keith
Brian S. Jones wrote:
> What can expand the ".tqz" archives?
>
> TIA,
> B
>
> On 12 Nov 1999 16:05:07 GMT, [EMAIL PROTECTED] (Keith A Monahan) wrote:
>
> >I know a bunch of people (including myself) were looking for PGP
> >for their 3com Palm Pilots. You can find it at the following URL
> >which is at the North American Cryptography Archive, which is great
> >for everything, in addition to this. I have not tried this yet,
> >since I just found it.
> >
> >http://cryptography.org/crypto/hnKpw9sv/pgp/palmopgp/
> >
> >It looks like it's based on the SSLEAY crypto libs. If you download
> >the latest version (1.2?), it includes source, and the executable(
> >a .prc file)
> >
> >Hopefully deja or someone will archive this message - because finding this
> >up to this point has been a pain.
> >
> >Keith
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Public Key w/o RSA?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 13 Nov 1999 17:01:29 GMT
On Sat, 13 Nov 1999 "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
>John Kennedy wrote:
>
>> On 12 Nov 1999 23:48:03 GMT, David A Molnar <[EMAIL PROTECTED]>
>> wrote:
>>
>> > > And if so, then why is RSA in
>> >> particular so popular?
>> >
>> >Name recognition. Ease of explanation. Ease of prototype implementation.
>> >PGP used RSA. There's an entire company dedicated to commercializing RSA.
>> >That kind of thing, I'd expect.
>>
>> Well also RSA has been used more extensively than any othe public key
>> system and thus has a proven track record that other systems can't
>> match yet. That's worth something.
>
>In what sense does PGP have a proven track record? I'd expect the people with
>the resources to actually dent PGP to keep their mouths shut no matter how far
>they got against it. Do you have authoritative information that indicates
>that no one has dented PGP, or are you make the assumption based on the fact
>that no one has made a credible claim to have done so?
There are a lot of people who would publish the results of
any attacks they found against RSA. Whether those people
have more or less resources than those who'd keep their mouths
shut is an open question, but the fact remains that the
publishers form a non-trivial group. RSA has received their
attention for a while, whereas brand new algorithms have not.
In that sense, RSA has a proven track record.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: McAfee Fortress
Date: Sat, 13 Nov 1999 17:10:05 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Rebus777)
wrote:
>>Does anyone have any comments about the McAfee Fortress program? It uses
>>Blowfish with up to 448 bits, also DES and Triple DES. You can enter a
>>password/passphrase of up to 32 characters. This seems like it would be a
>>good program but I never heard of it until recently. Has anyone used this
>>program or know if its good or not?
>>
>>Kris Hendricks
>>
>
>Are you refering to Strong Hold that comes with Nuts and Bolts Utilities?
Fortress is the newer name for Strong Hold.
-Tom
I use PGP for Privacy and Authenticity:
http://www.Tom.McCune.net/PGP.htm
------------------------------
From: Henri <[EMAIL PROTECTED]>
Subject: Re: Specific use of a hash function ?
Date: Sat, 13 Nov 1999 18:18:36 +0100
Thanks all for your help.
My application supports some collision and the list is going to be updated
regularly.But it will be a list of about one or two thousands people, not
more. So I think the risks of collision are acceptable for me.
Your suggestion of generating ID and keeping a mapping between ID and
personnal data is good but not viable for me. In effect, I make an unique file
to calculate statistics and establish profiles from data which come from
colleagues who work in different societies of my company. Even me, I must not
be able to know the personal data by the knowledge of the ID. But my
colleagues will keep a mapping between their people and the ID. Moreover, I
must be able to detect persons who work in the same time in different
societies of my company in order not to count them twice in my statistics.
Don't you think that if I put in the hash a concatenation of an secrete key
and about 15 characters from personnal data it won't be secure ? Of course it
depends on the length of the key ,I suppose ?
Have you any idea about the length of the secrete key and the hash function
that would be appropriate in order to make difficult for an attacker to make
an exhaustive attack ? I am only afraid by low-skilled attackers, I mean one
or two people with some PC. NSA is not interested by me , I think ;-)).
Thomas
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Crossposted-To:
soc.culture.yugoslavia,soc.culture.russian,soc.culture.greek,soc.culture.europe
Subject: Re: PGP
Date: Sat, 13 Nov 1999 12:32:45 +0000
personally I would not use pgp, but I would use another method for
encrypting my email messages ....
DWH wrote:
> PGP Page Links:
>
> http://irfaiad.virtualave.net/links/PGP/
>
> http://www.pgpi.org/products/
>
> PGPfone21
>
> http://www.pgpi.org/cgi/download.cgi?filename=PGPfone21-win.zip
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: RC4 Hardware implementation
Date: Wed, 10 Nov 1999 13:32:22 -0500
Yusuf Motiwala wrote:
>
> Hi,
>
> Are there any chips available for RC4 hardware implementation. ?
Hi/fn for one. There may well be others; RC4 is a pretty
popular algorithm.
paul
------------------------------
From: Coen Visser <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Sat, 13 Nov 1999 19:08:29 +0000
"Trevor Jackson, III" wrote:
>
> Coen Visser wrote:
> > After that one is gone they may
> > plow under the software crisis, with its 25-50% failed software
> > projects.
> Where are you getting these numbers? I suspect the source is using an
> atypically narrow definition of failure.
Ah, you expect a higher failure rate? Among other sources
(which take a bit longer to look up) this page gives a
nice if sometimes outdated overview:
http://www.csc.calpoly.edu/~jdalbey/crisis_quiz.html
Regards,
Coen Visser
------------------------------
From: Coen Visser <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Sat, 13 Nov 1999 19:17:23 +0000
Scott Nelson wrote:
>
> On Sat, 13 Nov 1999 "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
>
> >Coen Visser wrote:
> >
> >There is a fundamental linguistic issue that you have failed to address. The
> >term "a random string" is actually shorthand for the phrase "a randomly selected
> >string". This puts the emphasis on the generator, specifically the selection
> >mechanism, instead of the output.
Please be careful when quoting. I did not write the above text
("There is ... the output."), that was Trevor.
Regards,
Coen Visser
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Sat, 13 Nov 1999 11:11:50 -0800
Scott Nelson <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Sat, 13 Nov 1999 "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
>
> >Coen Visser wrote:
> >
> >There is a fundamental linguistic issue that you have failed to address.
The
> >term "a random string" is actually shorthand for the phrase "a randomly
selected
> >string". This puts the emphasis on the generator, specifically the
selection
> >mechanism, instead of the output.
> >
> Or perhaps it isn't short hand, and it's your assumption that
> it is that should be questioned. Or then again, maybe it
> is short hand, but short hand for a different term.
> I get the impression that "random string" is being used
> by one 'side' to mean "random selected string from a set of
> finite strings that are the same length as the string" and
> by the other 'side' to mean "a string of symbols, each
> of which (the symbol) is random"
Yes, and the DIVISION originates from the sci.crypt participants, who have
as their history a difference between analyzing STREAM ciphers and designing
`new' block ciphers with OUTPUT feedback mechanisms.
The stream ciphers were designed with ONE TIME PADS (paper teletype tapes)
which were SECRETLY generated and disseminated streams of individual RANDOM
characters, INPUT to some simple OPERATOR so that a plain message would take
on the characteristics of a RANDOM string while being sent from one side to
the other. Karl M
------------------------------
From: Boaz Lopez <[EMAIL PROTECTED]>
Subject: Re: SCOTT16U SOLUTION ON THE WEB
Date: Sat, 13 Nov 1999 12:25:40 -1000
SCOTT19U.ZIP_GUY wrote:
>
> Yes no one anwsered it since it is much better at encrypting files
> than the short keyed AES stuff the phony crypto gods want people
> to use.
> Next year assuming we are still alive and no chinese rockets or
> previously planted nukes and bioterrism weapons destroy this nation
> I will if not assinated have another contest
I got assinated one, but I still held a new contest.
------------------------------
From: amateur <[EMAIL PROTECTED]>
Crossposted-To:
comp.security.misc,comp.security.pgp.tech,alt.security.pgp,comp.mail.eudora.ms-windows
Subject: Re: S/MIME plug-in for Eudora? Strong Encryption
Date: Sat, 13 Nov 1999 13:45:45 -0700
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Adam Kippes wrote:
In <8hFW3.4593$[EMAIL PROTECTED]>, Doug McIntyre wrote:
> There's no reason PGP would be able to do anything that S/MIME
> couldn't. Its the same concept, and the same execution.
Perhaps, but there is no expiry on the keys and I can (and do) use it for a
lot more than encrypting mail.
-
===================================================================================================================
Hmm, I thought that there was an option that allowed the PGP key to expire but
I can't seem to find
it......
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.0.2
Comment: No, I'm not paranoid!
iQA/AwUBOC3N54woPKBUx8xQEQJMiwCg+vFn+wbjj5J+GDI7KRTvWWYmkicAoIQ+
n2DGg3WenQxIl/O0Nrr5l7rO
=bXrW
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Michel Dalle)
Subject: REVIEW - Vulnerability of "Password Protection" Applets
Date: Sat, 13 Nov 1999 21:20:28 GMT
You probably all know how insecure client-side applets can be. Here is
a review of 14 so-called "Password Protection" applets that are supposed
to protect access to webpages :
http://gallery.uunet.be/Michel.Dalle/passappl.htm
Your comments would be appreciated, since I'm definitely not
a crypto specialist...
For educational purposes only,
Michel.
P.S.: does anyone know whether there are applets available that DO
provide some adequate security ?
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !!
Date: 13 Nov 1999 21:41:00 GMT
fungus [EMAIL PROTECTED] writes:
>JPeschel wrote:
>>
>> fungus [EMAIL PROTECTED] writes:
>> >Read the subject line "Encryptor 4.0 by Comotex.. .... cracked",
>> >not "Algorithm XXX cracked"
>>
>> You read it. This guy hasn't cracked anything.
>>
>
>Your reasoning is....?
It's pretty much as I've already said. He has found a weakness that can
be exploited. In order to fully crack this program, he needs
to fully understand the encryption algorithm and write
a dedicated cracker. Examples of real cracks are on my
web page. You might want to see my comments in the Encode-it
thread, too.
He has, however, found a pretty good attack, one that I think
can be developed so that is requires only one ciphertext. When
he does I hope he is willing to share it.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Caesar Valenti <[EMAIL PROTECTED]>
Subject: Re: Need technique for about 24 bytes
Date: Sat, 13 Nov 1999 14:15:47 -0800
Thanks to all of you for your suggestions. I am still looking into all
the above posts emails; and am now reading Applied Crypto....a major
undertaking in itself!
Here is a bit more info:
This will be used in a device that will essentially verify its own serial
number (which the routine can read). All devices must use the same
routine and probably the same key. I could base the key on the serial
number, but the serial number is what is being encoded/decoded. The
platform is Windows NT. I can use C/C++ or VB. What I envision is
something similar to Microsofts CD key.
For example, the plaintext would be somthing like this (ignore the
dashes):
SN-ABCD-0123456-9999999 where the first 13 chars are the serial number,
and the remaining chars would be some device dependent info. At this point
I don't know how many extra chars there will be...maybe 5 to 10?? The
device could then verify that the first 13 chars match the serial number
of that device. If so, it would then act upon the remaining bits. I
would like the ciphertext to completely change even if only one char is
changed. The actual length is not critical; it just must be relatively
easy to enter....how much do YOU like entering Microsofts 25 char CD
key!??
And finally, security is only a moderate concern as it is unlikely our
customers will go thru much
effort to defeat this....besides, one could always monitor the CPU to
reverse engineer this.
Thanks
Gary wrote:
> What is the destination platform?
> IE What are the memory, bandwidth, error rate, and cpu (8,16,32 bit?)
> limitations?
> Is the string made up of completely random characters or does it have
> redundancy which could squeeze the string into 15 8 bit bytes (each
> character averaging 5 bits)?
> These parameters effect what type of compression and cipher algorithms
> should be used.
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: New Way To Prevent Employees From Vandalizing Files
Date: Sat, 13 Nov 1999 15:30:14 -0700
Well, the scope of this particular product IS rather narrow, although we
soon will be releasing similar products for a number of widely used
software packages.
As for a solution seeking a problem :
You would be absolutely amazed at the number of businesses, small and
large, who are victims of password vandalism on the part of their
employees. We get calls and E-mail every day with the same sad story -
"my secretary/assistant/lacky/employee/son/daughter/wife
accidentally/purposely put a password on my accounts receivable/master
database/file I cannot live without. He/she has left town and will
not/cannot tell me the password."
There is a GREAT need for this easily applied ounce of prevention all
over the corporate and small business world. Business today runs on
information...employees know this and this makes them dangerous.
The MAIN point as far as this newsgroup is concerned is that PC software
is easily subverted. This means that, in general, unless it is
physically secured at ALL times and the software that it runs subjected
to the most sophisticated analysis (not the usual case), the PC is not a
secure environment for encyption. Encryption on the PC should always be
suspect. It does not matter how theoretically secure an algorithm is.
If the software that runs the algorithm is insecure, the encryption is
not secure. I don't care if you do triple DES with zillion bit keys
followed by RSA with gazillion bit keys. If you do your encryption in
software on a PC that others may physically access, you might as well
write the plain text on a postcard.
Every so often, I see the idea of putting MD5 or other checksums on
executables to verify software integrity. These ideas IMHO are
nonsense. The attacker just nops out your checks after the software is
loaded in memory. Even dynamic memory checks in software are worthless
because they are easily detected and subverted.
Those who doubt this, I believe are not very familiar with the Windows
API (and some of its undocumented "features").
JK Http://www.crak.com
Nicol So wrote:
>
> "John E. Kuslich" wrote:
> >
> > As those of us in the password recovery business know, disgruntled
> > employees are a leading cause of data loss through password protection.
> >
> > CRAK Software has just introduced a new product WordMon (
> > http://www.crak.com/Wordmon.html )that monitors the Windows message
> > loop and prevents users from password protwecting Word documents.
>
> Maybe I'm missing something, but this sounds very much like a solution
> looking for a problem. I don't see why the threat described warrants a
> (separate) countermeasure with such a narrow scope of protection.
>
> --
> Nicol So, CISSP // paranoid 'at' engineer 'dot' com
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Specific use of a hash function ?
Date: Sat, 13 Nov 1999 19:06:39 -0500
Reply-To: see.signature
Henri wrote:
>
> My application supports some collision and the list is going to be updated
> regularly.But it will be a list of about one or two thousands people, not
> more. So I think the risks of collision are acceptable for me.
>
> Your suggestion of generating ID and keeping a mapping between ID and
> personnal data is good but not viable for me. In effect, I make an unique file
> to calculate statistics and establish profiles from data which come from
> colleagues who work in different societies of my company. Even me, I must not
> be able to know the personal data by the knowledge of the ID. But my
> colleagues will keep a mapping between their people and the ID. Moreover, I
> must be able to detect persons who work in the same time in different
> societies of my company in order not to count them twice in my statistics.
I assume it is OK for those colleagues of yours who supply you with
anonymized data to know the mapping between IDs and identities.
> Don't you think that if I put in the hash a concatenation of an secrete key
> and about 15 characters from personnal data it won't be secure ? Of course it
> depends on the length of the key ,I suppose ?
> Have you any idea about the length of the secrete key and the hash function
> that would be appropriate in order to make difficult for an attacker to make
> an exhaustive attack ? I am only afraid by low-skilled attackers, I mean one
> or two people with some PC. NSA is not interested by me , I think ;-)).
> Thomas
Since you've decided that your adversaries are not very skilled and have
limited resources, your requirements are pretty low. Any of the three
hash functions you mentioned in your previous message will work. As for
the length of the secret key, 80 bits should be more than sufficient
against casual attackers. Make it 128 bits or more and you don't have
to worry about exhaustive search. Remember to use good key management
practices.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
------------------------------
** 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
******************************
