Cryptography-Digest Digest #861, Volume #13 Sun, 11 Mar 01 11:13:01 EST
Contents:
Re: Hash value repetion ("Simon Johnson")
Re: OverWrite: best wipe software? ("Trevor L. Jackson, III")
Re: Noninvertible encryption (SCOTT19U.ZIP_GUY)
[REQ] SHA-1 MD5 hashing software (Thomas Boschloo)
Freeware issues? (Dan Hargrove)
A question about passphrases (Crypto Neophyte)
Re: => FBI easily cracks encryption ...? ("Sam Simpson")
Re: Why do people continue to reply to Szopa? (Vernon Schryver)
----------------------------------------------------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Hash value repetion
Date: Sun, 11 Mar 2001 14:05:15 -0800
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] writes:
> > If all possible 160 bit values were hashed with SHA1, would there be any
hash
> > results repeating? Or is it a 1 to 1 relation?
>
> Assuming that SHA-1 behaves like a random function, as it is designed
> to and certainly appears to, about 1/e of the possible output values
> would be skipped, meaning that there would be repetitions among the
> others.
>
> For SHA-1 to be a 1-to-1 function, i.e. a permutation of 160 bit
> values, be a fantastic, incredible, unbelievable coincidence. It
> would mean that there is hidden and unsuspected structure in the
> computational universe. One might even consider it tantamount to
> proof of the existence of God.
>
> > What about MD5?
>
> Same, for 128 bit values.
>
> > If neither are, are there hashes that are?
>
> Hashes are usually by definition intended to be pseudo-random
> functions rather than pseudo-random permutations. One problem is that
> you usually want the function to be one-way. For an example of a PRP
> you can consider RSA encryption using a modulus with an unknown
> factorization.
Discrete log problems are better, the reason being is that you can
distribute a generator you made yourself and you can insure people that you
do not have the means to reverse it. With RSA based hashes, this is
impossible because you have to generate the two primes to make the modulo,
which means you (or something else) must have known what they are, meaning
people are unlikely to trust it. .
Simon.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite: best wipe software?
Date: Sun, 11 Mar 2001 14:54:10 GMT
Caveat lector.
Lest innocents suffer, let the reader beware: The author of this software
has struck out.
Strike 1: He has not the slightest concept of the design and
implementation of security software.
Strike 2: He is impervious to all attempts to help him understand the
issues.
Strike 3: His products are unusable due to the unbelievably awkward
methodology they require of the user.
For the record, the descriptions and background presented below are far
more misleading than they are informative.
Anthony Stephen Szopa wrote:
> OverWrite: best wipe software?
>
> I think I have made Ciphile Software's OverWrite Security Utility
> Version 1.2 perhaps the best wipe utility available for Windows.
>
> Read below and you tell me. Now available for direct download at
> www.ciphile.com
>
> In addition to the prior instructions here are the new
> recommendations and facilities. What have I forgotten?
>
> "NOTE: For best results this program should be used only with
> Windows OSs and there should be no other programs running while this
> program is running. Maximum security from using this software
> results when overwriting files that are stored on 1.44MB floppy disks.
> Therefore, your most sensitive files should be written directly to
> 1.44MB floppy disks if you must be as absolutely sure as possible
> that this data is as nearly impossible as possible to recover once
> overwritten using this software. SCSI hard drives are not
> recommended. Nor are compressed drives. I use this software to
> overwrite files on my own IDE hard drives.
>
> RECOMMENDATIONS: You are probably familiar with MS Word. Start a
> new composition then save it. Then close the file. Now open it
> again. You will notice that a swap file has been created:
> ~$Doc1.doc if you saved the file as Doc1.doc. When you are through
> and close this file the swap file ~$Doc1.doc is deleted. But the
> ~$Doc1.doc data is still on your hard drive. So if you decide later
> to overwrite the Doc1.doc file you will not be overwriting previously
> removed ~$Doc1.doc data that is still on your hard drive. But take
> notice that even MS Word creates this swap file in the directory
> where the current document is stored.
>
> If you are serious about making sure that any data that has been
> saved to your hard drive is removed when you overwrite it using
> Ciphile Software's OverWrite Security Utility program then you
> should follow these specific recommendations.
>
> You should create a hard drive partition dedicated to storing and
> processing sensitive data. All sensitive data that you create or
> save or process with your computer should be done only in this
> dedicated hard drive partition.
>
> Now here is how you use this dedicated hard drive partition. For
> example purposes, make the dedicated hard drive partition at least
> and about 18,144,000 bytes long. Let's say your system calls this
> partition hard drive H:\. Now save 14 files of 1,296,000 bytes each
> called TFile1, TFile2, TFile3, and so on to hard drive H:\. Now use
> the OS delete function to remove only TFile2 through TFile13 from
> H:\. Got it? Now use this freed space available on H:\ for all of
> your secure data processing, etc.
>
> What does this do for you? Primarily it does two things. First it
> pretty much assures you that any processing you do on this dedicated
> hard drive H:\ will be confined to drive H:\. Not only is the data
> processing confined to drive H:\ but it is confined to the free space
> where you deleted TFiles 2 - 13. So you know where any writes are
> being made to your hard drive: only on drive H:\ and only within
> the free space made available from the deletion of TFiles 2 - 13.
> Remember the MS Word example? As long as you are using IDE hard
> drives in a non RAID set up I am unaware of any programs as simple
> as OverWrite that will go to another hard drive to carry on
> processing when you originate the executable program from and save
> to this one dedicated drive H:\. If other simple programs do go to
> other hard drives they are most likely going to require the
> configuration to be specifically set up to do this. In other words,
> you will have to set this up beforehand. Just don't do this with
> drive H:\
>
> Secondly, by dedicating drive H:\ as described above, you insure the
> best chances of all of your data being thoroughly overwritten when
> using Ciphile Software's OverWrite Security Utility program. Here
> is why. You are confining where the OS can process your confidential
> data to just the area freed up on drive H:\. For a tighter example,
> instead of deleting TFiles 2 - 13 just delete TFile8. This will free
> up only 1,296,000 bytes of space on H:\ whereas all the other space
> will be taken up by the other 13 TFiles. The OS is confined to this
> one relatively small area of 1,296,000 bytes on drive H:\ to do all
> its processing. This helps insure that the file you intend to
> overwrite is being properly overwritten with regard to OS and
> hardware optimization. To make completely sure that your file on
> the hard drive is the specific area being overwritten as you intend,
> you can either append into the file you were writing in and bring
> the byte count of this file up to the remaining available space in
> H:\ or you can use the OS delete function and delete the file you
> want to overwrite. Then write the TFile8 back to H:\. Then use the
> OverWrite program to overwrite this TFile8. There is no other place
> to go when overwriting TFile8 because all the remaining space on H:\
> is taken up by the other 13 TFiles. And since the space TFile8 now
> occupies includes the space where your file was written, your file
> space is necessarily overwritten when TFile8 is overwritten.
>
> Periodically, you may just want to overwrite the entire H:\ partition.
> Simply delete all the files in H:\. Then write a MixFile.otp file of
> 18,144,000 bytes to H:\. This will occupy the entire H:\ partition.
> Then use the OverWrite program to overwrite this MixFile.otp. The OS
> has no place to go except to overwrite the entire partition.
>
> As you may have noticed much of this discussion has been making an
> underlying assumption that because of OS and hardware optimization
> that sometimes and in some circumstances the actual overwrite may not
> be taking place exactly as thought and intended. You have noticed
> that I have described a procedure that will make sure that the
> overwrite does take place as desired. But there have been some
> additional improvements to Version 1.2 of OverWrite.
>
> Here they are in a nutshell fast and furious: in each of the 27
> passes of the overwrite process there is an fopen, overwrite,
> fflush, fclose, and ProcessMessages command. Each time, these are
> followed by a sleep command that suspends program operation for a
> specified number of seconds and this allows the OS to take over.
> This amount of time can be anywhere from 2 to 120 seconds and is
> user determined. This should provide the OS and hardware with more
> than enough time to commit and effect an overwrite. On my two
> systems a sleep(4) seems like enough. This is your decision to
> make. I look at the hard drive indicator light and listen to the
> hard drive and even feel the hard drive bay for indications that
> the write is physically taking place.
>
> Where do you get the TFiles and MixFile.otp? You can generate these
> using Ciphile Software's OAP-L3 or OAR-L3 software available from
> www.ciphile.com from the Downloads Currently Available web page.
> Also, you can generate files of any length by being creative with
> the Utility files included with these two software programs.
>
> If you follow the above recommendations it leaves very little if
> any wiggle room for the OS or hardware to forestall any overwrite
> operation or not to overwrite your intended file.
>
> Here is how you input the sleep parameter in seconds: Use NotePad
> or WordPad and create a file called VarDur.txt and place it into your
> H:\ drive or into the drive / folder / directory where the file is
> you want to overwrite. Write no more than three digit characters
> into this file. This will be how many seconds you want the program
> to suspend using the sleep function between each of the 27 overwrite
> passes. The default is 2 seconds. 2 seconds will be used if the
> number you enter in VarDur.txt is less than 2 or if the file does
> not exist. The maximum three digit value is 120 seconds. If you
> enter three digits greater than 120 then 120 will be used. Only
> three characters will be read from the VarDur.txt file and only
> digits will be accepted. All other characters will be ignored.
>
> You will see improvements in the program user interface with
> OverWrite Version 1.2. There is a progressbar, a percentage label,
> a pass label and a sleep duration label all to indicate to the user
> the parameters and progress of the overwrite process. See below
> for other instructions.
>
> I know that I could have made a better interface and written better
> instructions but this is freeware and I have limited time. But I
> think you all now have maybe the best overwrite program available
> if used properly.
>
> Take as much care as you think you should."
>
> Let's see you get out of this box.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: sci.math
Subject: Re: Noninvertible encryption
Date: 11 Mar 2001 15:05:12 GMT
[EMAIL PROTECTED] (Paul Lutus) wrote in
<yjFq6.45884$[EMAIL PROTECTED]>:
>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>
>> I think compression with encryption following is a greatly over
>> looked topic. Compression should help before encryption. But many
>> compression methods actually add information to a file so that it
>> can in theory make it weaker.
>
>You mean the encryption becomes weaker? No. This would suggest that
>compression partially decodes an encrypted file. The only purpose of
>compression is to compress. It has no effect on the encryption.
>
>And it is a matter of interpretation what "adds information to the file"
>would mean. It certainly doesn't add message information. It will add an
>unmistakable stamp of the compression method, but this is neutral WRT the
>encryption's effectiveness.
Most compression adds so much information to a file. That it becomes
trivally easy to test a key for a solution when one has "zero knowledege"
of the actual starting file that was encrypted. The main reson for this
is most compression routines have the property that for any file X:
then Decompress( Compress(X) ) = X
but when one tries to decompress an arivitrary binary file Y
then Comress( Decompress(Y) ) "seldoms equals" Y
there are only a few RLE, HUFFMAN, and ARTITHEMETIC compressors
that will allow any file to be treatd as a proprer compressed file.
There has been long discusions on this forum about compression and
its effect on a following encryption.
Even using any of the AES candidate methods of encryption with
a totally random few to encrypt. If that file was run through most
compressors one may only need a short random file of hundred bytes
or less to have the effect that only one key could have been used
on that file to produce a valid compressed encrypted output file
and that is not good unless your the guy testing for the key.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Thomas Boschloo <[EMAIL PROTECTED]>
Subject: [REQ] SHA-1 MD5 hashing software
Date: Sun, 11 Mar 2001 16:26:54 +0100
=====BEGIN PGP SIGNED MESSAGE=====
I was wondering if any of you guys have some (trustable) hashing
software on your sites. What I want is a program that computes the hash
of a file, preferably for MS-DOS or Windows, and that has a lot of them
(hashes).
I know of one program that does this for windows by Sarah Dean
<http://www.fortunecity.com/skyscraper/true/882>, but I would like to
know about some alternatives.
Somehow a websearch at e.g. cert didn't turn up much other than
'tripwire' and (presumably) large sized software like that.
I do want the software to be free and include a lot of hash algorithms
because I want to link to it on my homepage.
Thanks in Advance, this seemed like the right group to ask,
Thomas J. Boschloo
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
iQB5AwUBOquLEAEP2l8iXKAJAQEj4AMdHLjw9iT8uPoJzG4L7TAN72jqZrnXIhxK
+vuDjhc+iMOVq6a74Z9gUG86yrs+h+9DdAXt2NTxQxQngnBFaLeAOQ/pHmjDZYCW
ZYXOow0ebL70vdUgvRLDNYO+5fDwoE2wN24OYQ==
=UE0h
=====END PGP SIGNATURE=====
--
Jessica "I'm not bad, I'm just drawn that way"
------------------------------
From: [EMAIL PROTECTED] (Dan Hargrove)
Subject: Freeware issues?
Date: 11 Mar 2001 15:41:34 GMT
Hi, everybody;
I am a regular over at alt.comp.freeware, and have been doing some analysis
of freeware encryption programs in response to numerous questions we
receive regarding security related software.
I have some questions which I would like to ask, to increase the publicly
available knowledge-base about freeware encryption products. These
questions apply to Windows only. I hope this is on-topic.
1) Folder encryption
There seem to be only a few products available to encrypt whole folders.
Abi-Coder encrypts folders, but leaves them and their contents open for
inspection. Folders lite encrypts folders, but as in the case of Abi-
Coder, does not support recursive folders (or folders within folders). Is
there a freeware (or free) product that encrypts and locks recursive
folders with Blowfish or a similarly strong algorithm?
2) On-the-fly; volumes; partitions;
One commonly available product is E4M (it uses IDEA or DES). How secure is
E4M compared to commercially available software? Is the information
contained within an encrypted volume itself encrypted? It seems to me that
a program would have to be entirely decrypted before it would run properly,
but what do I know? What attacks (in laymans terms) could be successful
against encrypted volumes that would not be successful against encrypted
partitions? ScramDisk is another available product. Does ScramDisk have
weaknesses that are not presented in the documentation?
3) Blowfish and IDEA;
These are commonly used for file encryption, but are general-purpose
algorithms. Are there better algorithms/cyphers for file/folder
encryption?
4) Key size; passwords;
I suspect the information I am reading about brute force attacks. It seems
to me that with approximately 4 kb of key (including all subsets), a brute
force attack would be very effective. There are only so many combinations,
though (I imagine) exceeding the trillions. What about a database that
contains, say, %10 of all possible variations for 128 bit Blowfish keys?
Isn't that feasible?
5) Swapfile;
The swapfile issue with Windows appears to me to be insurmountable with
Windows. I have looked at two freeware programs that overwrite the
swapfile. One writes binary zeros to the entire file. The other
overwrites the swapfile seven times (Scorch) with hash. How effective are
these tactics against modern retrieval techniques?
6) Secure deletion;
There are many freeware products for "burning" files. What are the most
effective methods against modern retrieval techniques? Are they available
in freeware products?
I realize these questions are fairly extensive, and probably a big yawn to
most of you. I want to thank everybody in advance for whatever help they
can provide.
Dan Hargrove
------------------------------
From: Crypto Neophyte <[EMAIL PROTECTED]>
Subject: A question about passphrases
Date: Sun, 11 Mar 2001 15:53:33 GMT
Two of my programs, Tresor and PGP private for the MAC will tell me if I type
in the wrong passphrase. How do the programs know if it is the wrong one
without storing it on the disk? I mean if it is stored on the disk isn't that
insecure?
HKRIS
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Sun, 11 Mar 2001 15:59:12 -0000
The FBI had surreptitious access to his machine - would it be indicitive if
he were using PGP / Scramdisk/ Scott / S/Mime etc? I think not...........
--
Regards,
Sam
http://www.scramdisk.clara.net/
Mxsmanic <[EMAIL PROTECTED]> wrote in message
news:DwJq6.31064$[EMAIL PROTECTED]...
> "Phil Zimmerman" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> > What encryption was Hansen using that it was
> > so easily cracked?
>
> I am wondering the same thing, since I haven't seen the actual method
> described anywhere.
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Crossposted-To: alt.hacker
Subject: Re: Why do people continue to reply to Szopa?
Date: 11 Mar 2001 08:45:09 -0700
In article <[EMAIL PROTECTED]>,
Eric Lee Green <[EMAIL PROTECTED]> wrote:
> ...
>I usually ignore Szopa, but I have a cold and can't venture far from
>my chicken soup, so this is how I'm entertaining myself. Besides, it
>has been educational. I've dug around in Windows preferences and
>discovered things that I didn't know existed there, I've investigated
>how Windows writes blocks to disks (all kinds), found out some interesting
>things about how the Unix buffer cache works, etc. All in all, a very
>productive use of down time forced by a cold.
Maybe so or maybe not. For example, unless one has access to more
versions of flavors of UNIX box than is likely, one cannot find out
"how the Unix buffer cache works," because there is no singular "Unix
buffer cache." The variations in how UNIX systems manage their buffer
caches (and page caches if "unified") are as large as the variations
in how "the UNIX file system" works. Many people realize that such
as XFS and UFS differ significantly, but differences in buffer caches
are harder to notice and not documented or advertised as much.
While it is nice to have clues about this or that mechanism, the most
valuable clues are about what one does not know. The most important
lesson to be learned from a kook is how easy it is for any of us to
be loudly certain about things that aren't so.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
