Cryptography-Digest Digest #476, Volume #11 Mon, 3 Apr 00 12:13:01 EDT
Contents:
Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - ("Trevor L.
Jackson, III")
Re: summing hashes is not safe? ([EMAIL PROTECTED])
Re: Stolen Enigma (Jerry Ennis)
Re: I will make ANY software for ANYBODY ("Trevor L. Jackson, III")
Re: The lighter side of cryptology ("Test")
Re: Stolen Enigma (Frode Weierud)
Re: OAP-L3: Semester 1 / Class #1 All are invited. ("Trevor L. Jackson, III")
Re: summing hashes is not safe? ([EMAIL PROTECTED])
TO LEARN WHAT HAPPENED TO MARKKU J. SAARELAINEN READ ALT.POLITICS.ORG.CIA
([EMAIL PROTECTED])
Re: Another question about blowfish (Mark Wooding)
Re: NSA (Johnny Bravo)
Re: Stolen Enigma ("Tony T. Warnock")
Re: Implementation of Blowfish (James Felling)
Re: I will make ANY software for ANYBODY (Guy Macon)
Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - (Guy Macon)
Re: summing hashes is not safe? (Paul Koning)
Re: Disc encryption software question (Paul Koning)
Re: PGP Strength (Guy Macon)
----------------------------------------------------------------------------
Date: Mon, 03 Apr 2000 09:32:04 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator -
Guy Macon wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Thor Arne Johansen) wrote:
> >
> >I would challenge anyone to produce evidence that overwritten data, can
> >be recovered. There seem to be some sort of consensus that reading
> >overwritten data can easily be recovered. Most of the descriptions on
> >how to do this is quasi-science at the best, and mindless techno-ranting
> >at the worst.
>
> Absense of evidence is not evidence of absense.
>
> There is good reason to believe that the evidence you seek is classified.
>
> >Mr. Gutmans paper is the best description of secure deletion I've seen
> >so far (even though I still think overwriting is a secure way to erase
> >data from magnetic media). However the paper is not a writeup on
> >successful recovery of overwritten data, it is merely describing some of
> >the processes and techniques to consider.
> >
> >Why recovering overwritten data is almost impossible:
> >NONLINEARITY, Spindle Jitter, Clock Jitter, PRML encoding, poor signal
> >to noise, correlated noise.
>
> These effects, when they happen during the original writing or the
> attempted overwriting, make it *easier* to recover data. If the
> overwriting bit is off center and only partially covers the original
> bit, the job of recovery is made simpler.
>
> These techniqes do not apply if you use the methods detailed by Peter
> Gutmann in [ http://www.cs.auckland.ac.nz/~pgut001/secure_del.html ].
> Magnetic force microscopy lacks nonlinearity, Spindle Jitter, Clock
> Jitter, PRML encoding, poor signal to noise, and correlated noise.
>
> >Now, this could also be judged as techno ranting :), but if you look
> >into it, these things makes it incredibly hard (almost impossible), to
> >recover overwritten data.
>
> I have a lot of obsolete and partially related experience in this area
> as an engineer who has worked with the original 30MB/30MB Winchester
> mainframe disk drives, 9 track mainframe tape drives, timelapse video
> recorders, phillips cassette data recorders, spacebourn data recorders
> for the space shuttle, and most recently DVD-RAMs. None of this
> experience is with modern disk drives, but I understand the basics,
> and have recovered "erased" data from these various recoding devices
> using fine iron powder and a good microscope. I have also failed to
> recover the data many times. This opsolete technique wouldn't work
> withy modern disk drives, of course - a quick calculation shows that
> the features are too small for that. It is important to realize that
> we had plenty of nonlinearity, Spindle Jitter, Clock Jitter, poor
> signal to noise, and correlated noise, and that this did not prevent
> recovery.
What did?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: summing hashes is not safe?
Date: 3 Apr 2000 13:23:00 GMT
In a previous article, Tom St Denis <[EMAIL PROTECTED]> writes:
>If you had two hashes such that a = -b, then they cancel each other out
>when you simply sum them. That means they have no effect, and I can
>change those two hashes.
That will only happen if you add-mod the hashes, not if you simply add them.
That is, you will not have this problem if the individual hashes are 20 bytes
and they are added as positive integers into a 24 byte sum (as I recall the
method was described in the original post).
/Henrick Hellstr�m
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: Jerry Ennis <[EMAIL PROTECTED]>
Subject: Re: Stolen Enigma
Date: Mon, 03 Apr 2000 13:35:56 GMT
[EMAIL PROTECTED] (Jim Reeds) wrote:
>Apparently the stolen Enigma was an "Abwehr" Enigma, as
>described in a recent Cryptologia article. I can well
>believe that there are only 3 (or maybe now, 2) Abwehr
>Enigmas left in the world. A garden variety Wehrmacht
>Enigma, like my friend Fred bought a decade or so back,
>costs as much a new car, I suppose, and is no great rarity.
>But this one was different.
Right. The stolen machine was an "Abwehr" 3 rotor Enigma serial number
G-312 . A full description and photographs of this machine are given
in David Hamer's article :G-312: An Abwehr Enigma", Cryptologia, Vol.
24(1), January 2000."
Hopefully, with the entire community alerted, the machine can be
recovered safe and sound.
*****************************************************
From: Jerry Ennis ([EMAIL PROTECTED])
------------------------------
Date: Mon, 03 Apr 2000 09:45:23 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: I will make ANY software for ANYBODY
Paul Schlyter wrote:
> In article <[EMAIL PROTECTED]>,
> ECN UltraTrader <[EMAIL PROTECTED]> Wrote:
>
> > I manage a VAST group of programmers specializing in all fields of
> > software development. If you have an idea for software that you would
> > like to develop or are currently working on software but would like
> > to save time & money, I can help. I offer the CHEAPEST software
> > development rates in the United States. I can help you in developing
> > ANY type of software with any provisions you may have
> > (confidentiality, time limitations, etc). If you are interested,
> > email me, and I will personally send you more information.
>
> Thanks. I'd like the Windows-2000 operating system ported to the
> ENIAC. I'd like it to be finished the day after tomorrow, and this
> project should cost no more than $2. I request it to be delivered on
> ENIAC-readable paper tape. No bugs will be tolerated.
>
> I'm looking forward to cooperate with you. If you manage this
> project, on time and within budget, I have some other, bigger,
> projects in the pipeline -- or else I'll have to find someone
> else to do them....
There are two reasons you don't want to do this. First, you would need a
large farm of paired ASR33s to make a paper tape swap device (_ugly_
concept). Second, the time required to boot the system would be much longer
than the average uptime of W2K.
But as a test of the capabilities of the development group it will do to
screen out those who make silly performance claims. ;-)
------------------------------
From: "Test" <[EMAIL PROTECTED]>
Subject: Re: The lighter side of cryptology
Date: Sun, 2 Apr 2000 23:25:12 -0600
The scary part is I think this thread is funny! Sheesh, I need to watch more
television.
[EMAIL PROTECTED] wrote in message <8c0ftd$o7e$[EMAIL PROTECTED]>...
>In article <
>8bu51l$mj2$[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] (Xcott Craver) wrote:
>
>
>> >> But not every bra has a cryptographic function. Most are used for
ASCII
>> >> armor or for compression. Some are even designed to make the plaintext
>> >> stand out and more enjoyable to read. . . .
>
>
> Regarding crypto- perverts and the above
>crypto- bra here's a ditty:
>
>
> I'm a cryptogeek, and I'm okay,
> I xor all night and I hash all day.
>
> I make some keys. I wear high heels,
> Suspendies, and a *bra*.
> I wish I'd been a girlie,
> Just like my dear Papa.
>
>
> This ditty was lifted from Monty Python and,
>speaking of gay [double meaning] Brits, I leave
>you with this observation:
>
> Turing did it but couldn't decide if he had
>finished.
>
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Frode Weierud)
Subject: Re: Stolen Enigma
Date: 3 Apr 2000 13:24:14 GMT
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] (Jim Reeds) writes:
>Apparently the stolen Enigma was an "Abwehr" Enigma, as
>described in a recent Cryptologia article. I can well
>believe that there are only 3 (or maybe now, 2) Abwehr
>Enigmas left in the world. A garden variety Wehrmacht
>Enigma, like my friend Fred bought a decade or so back,
>costs as much a new car, I suppose, and is no great rarity.
>But this one was different.
The machine that was stolen is one of the Enigma machines used by the
German military intelligence service, Abwehr. There probably are more than
three of these machine left but they are extremely rare and I would not be
astonished there would only be a handful of these machines left. The only
other machine of this type I know about in a museum with public access is
the one in the National Cryptologic Museum, at Fort Meade, USA.
The Abwehr machine stolen from BP carries the serial number G-312 and is
equipped with rotors I, II and III also marked G-312. The official
designation of this Enigma model is G or the G-machine. It was also called
the counter machine or "Zahlwerk-Enigma" because it is equipped with a
letter counter. The machine is quite different from the normal Service
machine as it does not have a plugboard (Stecker), it has a most unusual
keyboard, which carries extra numbers or symbols on every key, as well as
a rotor engage/disengage lever which is situated on the top-rear part of
the machine just behind the rotor windows, as well as the mentioned letter
counter.
You can download a copy of David Hamer's paper on the Abwehr machine,
"G-312: An Abwehr Enigma; David H. Hamer; Cryptologia XXIV(1); January
2000" from David's Web site at:
http://www.eclipse.net/~dhamer/download.htm
It is a ZIP archive which contains an Acrobat PDF file. The article
contains a lot of photos and other information about the BP machine G-312
which has now been stolen.
If you should happen to have any information that can lead to its recovery
you are advised to contact Christine Large of BP at:
Phone: +44 (0)7971 193546
Mobile: +44 (0)20 7737 7220
Email: [EMAIL PROTECTED]
Or contact BP at:
Phone : +44 (0)1908 640404
Fax: +44 (0)1908 274381
Frode
--
Frode Weierud Phone : +41 22 7674794
CERN, SL, CH-1211 Geneva 23, Fax : +41 22 7679185
Switzerland E-mail : [EMAIL PROTECTED]
WWW : home.cern.ch/frode/
------------------------------
Date: Mon, 03 Apr 2000 09:52:56 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Anthony Stephen Szopa wrote:
> Now, for any of those interested, Version 4.3 will be available
> very soon. Here are the additions to OAP-L3 in Version 4.3:
>
> 1) you will get two more random number generators: they are
> exactly the same as the current one where only MixFile1 is
> rotated except that PRNG2 will only rotate MixFile2, and PRNG3
> will only rotate MixFile3.
>
> 2) you will get several other processes:
>
> you will be able to scramble every subsequent set of 14 arrays in a
> MixFile to any one of 14! sequences
>
> you will be able to reverse the order of each element in each array
> in a MixFile
>
> you will be able to reverse the byte sequence of an entire MixFile.
> (Keep in mind that each MixFile is compressed using BCD so each
> byte contains information for two digits.)
>
> you will be able to reverse the array sequence of an entire MixFile
>
> you will be able to add 1 - 9 to each element in all arrays in a
> MixFile
>
> you will be able to shift all elements in each array in an entire
> MixFile
>
> These additional processes will greatly increase the possibilities
> of ordering the MixFiles thus making the MixFiles that much more
> difficult to determine
But according to your advertising the older product provided "absolute
privacy". Why would anyone want more than that?
>
>
> The additional PRNGs will provide more random numbers from which
> to create the OTPs, again making predicting the OTPs that more
> improbable.
>
> (I like to say that much more impossible.)
If your claim that much more is possible is true than it must be the case that
there are very many holes in your absolute privacy. One can only improve an
imperfect product.
Please stop posting in sci.crypt until you believe your product does not need
more strength.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: summing hashes is not safe?
Date: Mon, 03 Apr 2000 13:59:34 GMT
In article <8ca1b5$ob7$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In this case there is a limitation of 24 bytes to the sum. So if a+b >
> 24 bytes (very likely) information of the hashes is lost.
> In this case a few 100 message-hashes are added.
No, you are probably mixing up concatenation with addition. If you add
two 160-bit values the sum will be at most 161-bit, i.e. double the
maximum value of a 160-bit value.
...but certainly this means that information is lost when you add
values.
> How hard is it to construct (multiple) messages which are added to
> match the same sum of the orignal hashes?
It is claimed to be very hard. In order to perform such an attack, you
must find a message which matches at least one of a bounded number of
hash values.
> The summed hash is checked first, then the messages are decoded; bogus
> messages are discarded.
> Mike
May I ask: How do you know that the hash signature is intact?
/Henrick Hellstr�m
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: TO LEARN WHAT HAPPENED TO MARKKU J. SAARELAINEN READ ALT.POLITICS.ORG.CIA
Date: Mon, 03 Apr 2000 14:00:21 GMT
TO LEARN WHAT HAPPENED TO MARKKU J. SAARELAINEN READ
ALT.POLITICS.ORG.CIA
- MESSAGES POSTED BY VLADIMIR
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Another question about blowfish
Date: 3 Apr 2000 14:47:12 GMT
Jan Krumsiek <[EMAIL PROTECTED]> wrote:
> i want to encrypt a string which's length is not a multiple of 8.
>
> i tried to do this in the following way:
> let's say i got a 20-bytes string, i first encrypted the first 16
> bytes. than i copied the last 4 bytes into a new char array, set the
> other bytes of that array to 0 and encrypted the array. at last i
> copied back the first 4 bytes of the help-array into the original array.
> this did not work!! what's wrong?? how can i realise this??
Block ciphers, such as Blowfish, transform an entire block at a time.
If you pick a plaintext from some restricted subspace of possible blocks
(e.g., by forcing some of the bits to be zero), you're unlikely to find
that the ciphertext also belongs to that (or any other) restricted
subspace. So you need to remember the entire ciphertext block to be
able to reconstruct the plaintext.
There is a technique, `ciphertext stealing', which avoids this. To make
it work, you must encrypt *at least* one block at a time, but you don't
have to have a complete block at the end. It works by processing the
final two blocks (a complete one and a partial one) together:
Let's say that there are N bits in a block, and k bits in the final
partial block. Encrypt the complete plaintext block, giving a
ciphertext block C. Now take the final N - k bits of C and append them
to the partial plaintext block (giving a complete block). Encrypt that,
and then write out that ciphertext and the first k bits of C.
Decryption sorts out the resulting mess in the obvious way. You now
have a way to encrypt arbitrary sizes of text without padding.
Schneier's book describes the technique in detail, and explains how to
combine it with CBC mode. The only library I know of which implements
ciphertext stealing is my own Catacomb, available from
http://www.excessus.demon.co.uk/misc-hacks/#catacomb. Note that there
are some bugs in the multiprecision maths in the current version which
particularly affect RSA decryption. These are fixed in a new version
which hasn't been released yet. Note also that Catacomb is a personal
project of mine, and not something I do at work.
-- [mdw]
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: NSA
Date: Mon, 03 Apr 2000 10:47:12 -0400
On 01 Apr 2000 07:44:50 GMT, [EMAIL PROTECTED] (NFN NMI L.) wrote:
><<information, this being one of the most (the most maybe?) famous crypto
>related newsgroup on usenet.>>
>
>Information? From USENET? Hah!
>
>Just remember - the NSA is a government agency.
Precisely. There is a guy getting paid more 6 figures to read this
group and publish a monthly report entitled. "Intelligence Gathered
from Various Diverse Sources with Close Ties to Multiple Crypto
Assets." That is the kind of stupidity the government indulges in.
Government can only grow more inefficient, might be tied in with the
2nd law in some way. <grin> After all, in the year of my birth a
government project costing $20 billion dollars and lasting roughly 15
years managed to send humans to the moon and return them safely to
earth. Care to estimate how long it would take and how much it would
cost to duplicate that feat if we started right now?
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Stolen Enigma
Date: Mon, 03 Apr 2000 09:06:10 -0600
Reply-To: [EMAIL PROTECTED]
Perhaps it was stolen by the same guys who stole the laptop. They may
hope to use the Enigma machine to decode the laptop contents.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Implementation of Blowfish
Date: Mon, 03 Apr 2000 10:12:16 -0500
Tom St Denis wrote:
> lordcow77 wrote:
> >
> > This is intellectually dishonest, implying an unbiased
> > observation or judgement when in fact, CB is your own API. While
> > I am fairly certain that you have no underhanded motives, fully
> > disclosing your relationship to a product that you suggest to
> > others is a standard ethical practice.
>
> I was trying to be funny and informative. If you find any problems with
> CB though [which I am not doubting] please let me know.
>
> Tom
There are no known problems with it that I have noticed ( I have given it a
casual once over), but I do agree that it is best to say
" I wrote the CB API and it is a good one go ahead and use it" vs. " I would
recomend the CB API"
The reasons behind this are
1) It prevents you from sounding like the individuals (who shall remain
unnamed here) who plug their own unique crypto prducts as the best thing
since sliced bread.
2) Its your API be proud of it.
3) It prevents people from thinking hey the guy who recomended this to me
wrote it, and didn't say so at the time -- is there some weakness or the
like to this or a backdoor that he could use. Firmly associating yourself
with your product upfront prevents the apearance of having something to
hide.( I know it is ridiculous, but that is the way it seems to work
now-a-days)
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: I will make ANY software for ANYBODY
Date: 03 Apr 2000 11:42:50 EDT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jerry
Coffin) wrote:
>
>In article <8c8hvc$pnm$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>says...
>
>[ ... ]
>
>> Thanks. I'd like the Windows-2000 operating system ported to the
>> ENIAC. I'd like it to be finished the day after tomorrow, and this
>> project should cost no more than $2. I request it to be delivered on
>> ENIAC-readable paper tape. No bugs will be tolerated.
ENIAC was not a stored program computer, nor did it have a paper tape.
input was switches and jumpers, output was lights. As usual, most
problems in engineering projects are tracable to bugs in the requirements.
[ http://www.seas.upenn.edu/~museum/qman/quick.html ]
>I'll be happy to take this on. Of course, you have to supply the
>working ENIAC, its staff of full-time technicians to keep it running,
>and (of course) getting my house wired to power it... <G>
Don't make promises that you can't keep on the assumption that your
conditions cannot possibly be met. See the following web pages for
a real ENIAC that you can buy today.
[ http://www.ee.upenn.edu/~jan/eniacproj.html ]
[ http://www.upenn.edu/computing/printout/archive/v12/4/chip.html ]
>Just to make sure the staff is up to speed, we'll need an EDSAC,
>an EDVAC and a Mark I for a month ahead of time as well...
Now you are padding the contract. The original ENIAC programmers
didn't need those new-fangled contraptions, so why should you?
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator -
Date: 03 Apr 2000 11:56:23 EDT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Trevor L. Jackson, III)
wrote:
>
>>
>> I have a lot of obsolete and partially related experience in this area
>> as an engineer who has worked with the original 30MB/30MB Winchester
>> mainframe disk drives, 9 track mainframe tape drives, timelapse video
>> recorders, phillips cassette data recorders, spacebourn data recorders
>> for the space shuttle, and most recently DVD-RAMs. None of this
>> experience is with modern disk drives, but I understand the basics,
>> and have recovered "erased" data from these various recoding devices
>> using fine iron powder and a good microscope. I have also failed to
>> recover the data many times. This obsolete technique wouldn't work
>> with modern disk drives, of course - a quick calculation shows that
>> the features are too small for that. It is important to realize that
>> we had plenty of nonlinearity, Spindle Jitter, Clock Jitter, poor
>> signal to noise, and correlated noise, and that this did not prevent
>> recovery.
>
>What did?
Keeping in mind that this was older technology, I found that if by chance
the new data was right on top of the old, I couldn't pick out the old
with my microscope. It was variation in track pitch and on/off timing
that made the new data miss the old. Multiple writes didn't stop me
because a lot of the track pitch variation was temperature dependent
and the multiple overwrites would keep missing the old data.
Because we used fine iron dust in a liquid base, we only saw north and
south, not fine graduations of magnetic intensity or magnetic patterns
not on the surface - those would be major improvements on our methods.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: summing hashes is not safe?
Date: Mon, 03 Apr 2000 11:54:24 -0400
[EMAIL PROTECTED] wrote:
>
> Just came across some code in which multiple (100's) 20 byte message-
> digests are summed into one 24 byte sum as a hash for the complete
> batch.
> Something tells me this is not the way to handle (SHA-1) hashes. Can
> anyone confirm my feeling that it's fairly easy to add fake messages?
A good cryptographic hash has these properties: (a) it's very hard to
find a message with a given hash value, (b) it's very hard to change a
message in a way that changes its hash in a given manner.
So there shouldn't be a feasible way to spoof the individual 20 byte
digests.
On the other hand, adding is clearly the wrong thing to do because
it doesn't protect against reordering of the parts. So while an
attacker shouldn't be able to substitute his own component messages,
he can modify the order of the components without being detected.
The most efficient approach is to do a single hash of the entire
message, rather than to hash it in pieces. SHA-1 (and MD5) work
for message of up to 2^64 bits. If you have to deal with pieces,
perhaps because they come with the hash values already in place,
then concatenate the component hashes and hash that. This will protect
against reordering as well as other attacks.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Disc encryption software question
Date: Mon, 03 Apr 2000 11:37:42 -0400
Eli Akronym wrote:
> ...
> As far as I know, the only disk encryption programs available that have
> open source code and verifiable integrity are Scramdisk and PGPDisk. All
> other disk encryption programs should be considered worthless.
That's perhaps a tad too strongly stated. I'd trust SFS (from Peter
Gutmann) on the strength of his reputation even though it's not
open source last I looked.
paul
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: PGP Strength
Date: 03 Apr 2000 12:06:10 EDT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Niklas Frykholm)
wrote:
>
>> In the documentation for PGP, I read that it uses ZIP Compression to
>>generate smaller files and thus less predicatble contents, but does this not
>>mean tht the files will contain a standard Header(Not Nesscerily "PK" but
>>some sort of Table that that LZW Compression needs), or does it do this
>>outside the Encrypted Area, either way I cannot see the ZIP Compression
>>Improving the strength because using both you are able to predict the
>>contents even better in my mind.
>
>I think it is best to see compression as a way of speeding up
>encryption/decryption and message transfer and not as a way of increasing
>security. If you want to do that, it is better to use stronger encryption,
>because compression algorithms are not designed with cryptographic concerns in
>mind.
>
>As you say, the compressed file should not contain headers or other easily
>identifiable structures (I'm not sure how PGP handles this), but even if it does
>this is perhaps not such a big deal, since modern cryptosystems are designed to
>be secure against known-plaintext attacks.
>
>If we look at key search attacks, the claim that compression increases security
>is doubtful (even if we ignore the problem with headers). The important question
>here is how quickly we can distinguish valid messages from garbage. Compression
>does not necessarily make this much harder, because we can create a lookup table
>for the first few bytes of valid compressed messages, just as easy as for valid
>uncompressed messages. Also, decompression is usually a quick procedure.
>
>Prepending some random bytes might improve the situation, but still I think it
>is better to address security concerns in the encryption algorithm.
>
I think that you should do both. Pick a method resistant to
known plaintext attacks, then prepend and append a random amount
of random data in case you are wrong. This will also pad the
plaintext to a random length in case you are wrong about resistance
to chosen length attacks. None of this should take away from your
effort to use the strongest protection that you can, of course.
------------------------------
** 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
******************************
