Cryptography-Digest Digest #800, Volume #10 Tue, 28 Dec 99 04:13:02 EST
Contents:
Re: Employing digits of pi (Matthew Montchalin)
Re: Are PGP primes truly verifiable? (Johnny Bravo)
Re: how good is RC4? (Tom St Denis)
Re: PKZIP compression security (SCOTT19U.ZIP_GUY)
Encryption: Do Not Be Complacent (Anthony Stephen Szopa)
Re: PKZIP compression security (Steve K)
Secure Delete Not Smart (UBCHI2)
Re: Secure Delete Not Smart (David A Molnar)
Re: Enigma ("John E. Gwyn")
Re: Secure Delete Not Smart ("John E. Gwyn")
Re: Encryption: Do Not Be Complacent (wtshaw)
Re: Homophones (wtshaw)
Re: Secure Delete Not Smart (Steve K)
Re: HD encryption passphrase cracked! (Matthew Montchalin)
Re: Employing digits of pi (Mok-Kong Shen)
Re: More idiot "security problems" ("Brian Gladman")
----------------------------------------------------------------------------
From: Matthew Montchalin <[EMAIL PROTECTED]>
Subject: Re: Employing digits of pi
Date: Mon, 27 Dec 1999 17:09:26 -0800
|> You mean 'concatenate' rather than 'add?' What you've got after
|> going this far is a long series of digits that 'appear' random.
Mok-Kong Shen wrote:
|I wrote 'add' and meant really 'add' never 'concatenate'!
Okay. What you've got, then, is a single digit, after indexing
in, loading a register with the desired digit, and adding it to
the sum, then storing back into the register that represents the
sum. (Sounds like a lot of work just to shuffle the bits around
inside a single digit.) But by concatenating these things, instead
of adding them, you can generate bigger and bigger numbers.
|The sum obtained is reduced modulo the base. I suppose I have
|explained the subsequences very clearly. These are digits starting
|from the n chosen starting points. All the n digits at the n
|starting points are added modulo the base to become the first
|digit of R. Then all the next n digits are added modulo the base
|to become the second digit of R, and so on. (I wonder how did you
|read out 'concatenation' from my post.)
Since you are constructing your digits one at a time, and putting
them into the proper order, that sure looked like you meant
concatenation.
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Crossposted-To: talk.politics.crypto;
Subject: Re: Are PGP primes truly verifiable?
Date: Mon, 27 Dec 1999 20:44:51 GMT
On 27 Dec 1999 23:07:21 GMT, [EMAIL PROTECTED] (Boudewijn W. Ch.
Visser) wrote:
>>point and verify that every prime before it is not a factor of the
>>prime in question. Once you get to a certain length, it becomes
>>infeasible to do so. Once you get to another certain length,
>>it becomes physically impossible to validate the prime in question.
>
>It is easily possible to prove numbers prime that are much larger
>than the limit you image. (numbers of hundreds of thousands digits
>large have been proved prime. Although these numbers are of a
>special form , for which extremly fast algorithms are possible ).
2^6,972,593-1 is the biggest prime known and the primality proving
took two weeks on a DEC 500mhz Alpha workstation. This prime is more
than two million digits long (2,098,960)! Very luckily indeed the
Lucas-Lehmer Test is much faster than checking all the primes up to
sqrt(x). :)
Best Wishes,
Johnny Bravo
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: how good is RC4?
Date: Tue, 28 Dec 1999 01:52:16 GMT
In article <[EMAIL PROTECTED]>,
Jim Gillogly <[EMAIL PROTECTED]> wrote:
> Greg wrote:
> > Is your post exporting strong encryption?
> >
> > Perhaps I should ask are you in the United States of America?
>
> He's not in the USA. Even if he were, why should you care?
> Perhaps I should ask whether you are in the Bureau of Export
> Administration?
>
> I will point out that if his post included strong encryption,
> then yours (which copied the whole thing while adding these two
> lines of commentary) was exporting strong encryption from whatever
> jurisdiction <you> reside in.
Ouch crash and burn. Good post Jim :)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: PKZIP compression security
Date: Tue, 28 Dec 1999 03:02:23 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Johnny Bravo)
wrote:
>On 27 Dec 1999 19:34:51 GMT, [EMAIL PROTECTED] (BigJim44) wrote:
>
>>I know it's not exactly PGP but would zipping a text file with PKZIP before
>>encipherment significantly increase the security of the link?
>>
>>Thanx...
>
> It is only useful for decreasing bandwidth since the first few known
>bytes in standard headers will not affect the security of modern
>ciphers as they are designed to withstand plaintext attack of the
>entire file, much less a few bytes.
>
> Johnny Bravo
>
Not true. While there is attempts to make modern ciphers safer
against some forms of plain text attack. It is foolish to think they
are totally safe against plain text attack and more foolish still to
use pkzip and encrypt. Why tell your opponet what your first
few bytes of plaintext are?
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,talk.politics.crypto,talk.politics.misc,talk.politics.drugs
Subject: Encryption: Do Not Be Complacent
Date: Mon, 27 Dec 1999 18:07:50 -0800
Reply-To: [EMAIL PROTECTED]
Encryption: Do Not Be Complacent
Even though you encrypt your messages with what you believe to
be excellent encryption, do not necessarily be frank in these
encrypted communications.
Continue to use code words and euphemistic phrases, etc. that only
you and your recipient understand. In fact, I would create an
entirely original vocabulary to communicate sensitive information
in the plain text.
I would create several specific words and phrases that convey the
exact same meaning. I guess the best security would be to assign
certain numbers to represent certain words and phrases. Then have
any of several numbers represent the exact same word or phrase.
Remember, encryption is only part of the solution to privacy. There
are protocols, secure (isolated) machines, bug (sophisticated
eavesdropping device) threats, etc. If any of these holes in
security might effect you then your plain text may be compromised
even if you encrypt.
By being purposely ambiguous or using additional codes in your plain
text you will have an additional level of security.
It could mean the difference between succeeding or failing.
------------------------------
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: PKZIP compression security
Date: Tue, 28 Dec 1999 03:08:21 GMT
On Tue, 28 Dec 1999 03:02:23 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Johnny Bravo)
>wrote:
>>On 27 Dec 1999 19:34:51 GMT, [EMAIL PROTECTED] (BigJim44) wrote:
>>
>>>I know it's not exactly PGP but would zipping a text file with PKZIP before
>>>encipherment significantly increase the security of the link?
>>>
>>>Thanx...
>>
>> It is only useful for decreasing bandwidth since the first few known
>>bytes in standard headers will not affect the security of modern
>>ciphers as they are designed to withstand plaintext attack of the
>>entire file, much less a few bytes.
>>
>> Johnny Bravo
>>
>
> Not true. While there is attempts to make modern ciphers safer
>against some forms of plain text attack. It is foolish to think they
>are totally safe against plain text attack and more foolish still to
>use pkzip and encrypt. Why tell your opponet what your first
>few bytes of plaintext are?
Gotta side with DS on this one. I try to keep quoted material to a
bare minimum in encrypted replies, and so on and so forth.
Granted, modern ciphers are designed to diffuse the data in the
plaintext, spreading the bits of those bytes across a signifigant
patch or real estate. But until I understand these things a *lot*
better (newbie that I am), I will make the most pessimistic
assumptions.
;o)
Steve K
---Continuing freedom of speech brought to you by---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
PGP key 0x5D016218
All others have been revoked.
------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: Secure Delete Not Smart
Date: 28 Dec 1999 03:17:28 GMT
Data has been recovered after 9 overwriting wipes according to the PGP manual.
It seems foolish to secure delete something without encrypting it first. Why
isn't this ever suggested in the manuals?
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Secure Delete Not Smart
Date: 28 Dec 1999 03:36:28 GMT
UBCHI2 <[EMAIL PROTECTED]> wrote:
> Data has been recovered after 9 overwriting wipes according to the PGP manual.
> It seems foolish to secure delete something without encrypting it first. Why
> isn't this ever suggested in the manuals?
I don't know why it isn't suggested in the manuals...but...
If you overwrite the old data with the encrypted data, you just overwrote
it once. At least 9 more times to go.
If you don't overwrite the old data, you still have to destroy the old
data. Having an encrypted copy doesn't help much.
-David Molnar
------------------------------
From: "John E. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Enigma
Date: Mon, 27 Dec 1999 22:14:26 -0600
Mok-Kong Shen wrote:
> Two questions of ignorance: Does that mean Friedman's method is
> more general than and superior to what is done at Bletchley Park?
Friedman approached the problem by looking for ways to exploit
the regularities inherent in a (straight) rotor system. Thus
his methods can be applied to all such systems. In particular,
one doesn't have to know in advance anything about the system
in order to crack it. (Certain standard favorable conditions,
such as isologs, are needed to do this efficiently.)
"Superior" is a judgment call, and Bletchley Park certainly
deserves praise for their work.
> Are there publically available detailed technical literatures on
> cracking of Purple?
Not really. The nearest thing is WFF's "Analysis of a Mechanico-
Electrical Cryptograph" (not the Purple machine), which has been
released in redacted form to the National Archives. (I'm not sure
that the whole thing has been released even today. Rotor systems
were very widely used for high-grade traffic not so long ago, and
the exact extent of their vulnerability is not information to be
divulged lightly.)
- Douglas
------------------------------
From: "John E. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Secure Delete Not Smart
Date: Mon, 27 Dec 1999 22:19:17 -0600
UBCHI2 wrote:
> Data has been recovered after 9 overwriting wipes according to the
> PGP manual.
> It seems foolish to secure delete something without encrypting it
> first. Why isn't this ever suggested in the manuals?
Probably because almost everyone understands that it is the original
data track, already present on the disk, that would be recovered.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.privacy,talk.politics.crypto,talk.politics.misc,talk.politics.drugs
Subject: Re: Encryption: Do Not Be Complacent
Date: Tue, 28 Dec 1999 01:13:27 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Encryption: Do Not Be Complacent....
>
Age-old sound advice.
--
Only a little over a year left to go in this centrury....
Knowing this, figure that a year from now, we will
resale of the hoopla we are getting ready to see now.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Homophones
Date: Tue, 28 Dec 1999 01:08:08 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> According to Schneier's AC, Homophonic substitution ciphers are
> very easy to break.
>
> Question: What if one employs homophones in the manner of
> polyalphabetic substitutions, i.e. when there are more than one
> substitution tables (columns)? And when the tables are not
> periodically selected by a short key but chosen by the output
> of a PRNG with, say, some 200 tables? (To avoid misunderstanding,
> my question is about practical, not theoretical, security.)
>
There is a cipher known as Homophonic, and it is relatively easy to
break. There are a number of ciphers class a homophonic, and some are
harder than others to break, some not even practical to begin attack.
Given that I see them as inductive ciphers, a rose by any name is still as
sweet.
Yes, such a design is practical. To make it work well, some means of
diffusion to mask component keys helps. There are still other
alternatives. Schneier means well, at the time he had it locked up, but
he was obviously ignorant of my work in that area, not his fault.
The problem is that crypto knowledge is a moving target. If you are going
to view it through a rearview mirror, take care that you are not
permanently parked or you will be dated in what you learn.
AC? OK, but, supplement.
--
Only a little over a year left to go in this centrury....
Knowing this, figure that a year from now, we will
resale of the hoopla we are getting ready to see now.
------------------------------
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: Secure Delete Not Smart
Date: Tue, 28 Dec 1999 07:15:39 GMT
On Mon, 27 Dec 1999 22:19:17 -0600, "John E. Gwyn"
<[EMAIL PROTECTED]> wrote:
>UBCHI2 wrote:
>> Data has been recovered after 9 overwriting wipes according to the
>> PGP manual.
>> It seems foolish to secure delete something without encrypting it
>> first. Why isn't this ever suggested in the manuals?
>
>Probably because almost everyone understands that it is the original
>data track, already present on the disk, that would be recovered.
There's a lot to be said for processing sensitive material in an
encrypted container or partition, a Scramdisk volume for instance.
That way plaintext should never written to the disk in the first
place, and the whole issue is avoided.
I also believe that recovering data that has been overwritten more
than a couple of times involves taking the drive apart and using some
very fancy magnetometer gear on it. That sounds pretty expensive.
When you consider the real-world threats that a typical user faces,
it's pretty redundant to worry about attacks that go beyond what can
be done with software alone. Unless it's just a hobby.
:o))
Steve K
---Continuing freedom of speech brought to you by---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
PGP key 0x5D016218
All others have been revoked.
------------------------------
From: Matthew Montchalin <[EMAIL PROTECTED]>
Crossposted-To: misc.misc
Subject: Re: HD encryption passphrase cracked!
Date: Tue, 28 Dec 1999 00:18:32 -0800
On 27 Dec 1999, Guy Macon wrote:
|Speaking as an engineer who has actually designed hard disks and who
|has read but not tried the standard methods of reading wiped data,
(The proof is in the pudding, btw.)
|I can tell you three things:
|
|[1] I can't read data wiped with Keith's method.
|
|[2] I can read data wiped with your method. (Hint: DC vs. AC)
You can read *some* of the data. I doubt you can read *all* of it,
though. And because the medium now may have dirt on it, there is
a limited number of times you can try, or will want to try. For
some disks that I was playing with, rapid back and forth 'vibrating'
movements of the kitchen magnet were a lot better than long continuous
circumferential sweeps. (And I prefer rare earth magnets, but if you
overdo it, and overmagnetize the medium, you may not be able to overcome
the reluctance of the medium, and your drive won't reformat.) But *you*
are the expert, so I'll defer to your expertise. :)
|[3] Damage to hard disks from internal particulates is not limited
| in such a way that there are usable good sections. What you
| get is cumulative damage all over the disk.
I never lost *any* data from particulate damage. (Don't smoke. And
for what it's worth, I happen to run a number of air purifiers in the
background -- which isn't good enough to make the area a true 'clean
room,' but it is a whole lot better than what you would find in a
smoker's house, or a house with lots of pets.)
| Once you open it up outside of a cleanroom, any byte may be
| destroyed at any time. The good news for those reading this is that
| if your drive has been running fine for over two weeks, you know
| that it doesn't suffer from particulate contamination.
It may also be a good idea to cut the medium up into itty bitty little
pieces with a pair of scissors, and then burn 'em, I mean, if you
*really* wanted to get rid of the offending data.
| Something else will eventually kill your drive.
Of course! In *my* case, it was a Seagate that overheated from six
months of continuous running, and the lubricant on the spindle congealed
and gummed up so it wouldn't spin any more. (Sigh.) I had no choice but
to open the drive and transfer the medium... Since then, I'm no longer
as shy about taking the thing apart.
| If you don't back up your data. you are an idiot.
Wasn't the original question how to get rid of sensitive data?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Employing digits of pi
Date: Tue, 28 Dec 1999 09:45:19 +0100
Matthew Montchalin wrote:
>
> Since you are constructing your digits one at a time, and putting
> them into the proper order, that sure looked like you meant
> concatenation.
Mmm, you can certainly also claim that you were not in the above
writing a sentence but simply concatenating a number of charaters :-)
M. K. Shen
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: More idiot "security problems"
Date: Tue, 28 Dec 1999 08:42:54 -0000
"Terry Ritter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> On Fri, 24 Dec 1999 04:48:33 GMT, in <[EMAIL PROTECTED]>,
> in sci.crypt [EMAIL PROTECTED] (Bruce Schneier) wrote:
>
> >On 17 Dec 1999 09:55:08 GMT, [EMAIL PROTECTED] (Xcott Craver)
> >wrote:
>
> >>[...]
> >> Bruce Schneier and Counterpane have been known to assert, in
> >> talks and white papers, that good crypto/security cannot be
> >> distinguished from bad crypto/security. I've always considered
> >> this "Schneier's first law."
> >
> >A corollary is that: "Anyone can create an encryption algorithm that
> >he himself cannot break."
>
> Just to keep things honest, I would say the real situation is even
> more general:
>
> *Any* *group* can create an encryption algorithm that no-one in the
> group can break.
>
> Here "group" includes individuals, academics, AES participants, etc.
Including the group of 'all human beings'.
Brian Gladman
------------------------------
** 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
******************************
