Cryptography-Digest Digest #802, Volume #10 Tue, 28 Dec 99 13:13:01 EST
Contents:
Re: More idiot "security problems" (CLSV)
Re: Economic Espionage Act of 1996 and the U.S.A. government's violations (Eric
Chomko)
Re: Secure Delete Not Smart ("Trevor Jackson, III")
Re: More idiot "security problems" ("Brian Gladman")
Re: Employing digits of pi (James Felling)
Re: unbreakable? (Keith Monahan)
Re: Encryption: Do Not Be Complacent (Steve K)
Re: unbreakable? (John Savard)
Re: Secure Delete Not Smart (John Savard)
Re: Employing digits of pi (Mok-Kong Shen)
Re: Employing digits of pi (Mok-Kong Shen)
Re: Secure Delete Not Smart (Steve K)
----------------------------------------------------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: More idiot "security problems"
Date: Tue, 28 Dec 1999 15:27:38 +0000
"Terry Ritter" <[EMAIL PROTECTED]> wrote:
> > >> 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.
[ * rule 1 * ]
> > >> Here "group" includes individuals, academics, AES participants, etc.
> > Brian Gladman wrote:
> > > Including the group of 'all human beings'.
> "CLSV" <[EMAIL PROTECTED]> wrote:
> > A cipher designed by all human beings,
> > what is that supposed to mean?
Brian Gladman wrote:
> [...] The group of 'all human beings' has created
> a large number of ciphers already and will continue to do so.
> Hence the rule implies that it is possible for human beings
> to produce ciphers that human beings cannot break.
This really doesn't sound right from a logical
point of view. You say: ciphers are created by the group
consisting of 'all human beings' (*). As far as I know aliens
nor dolphins have contributed anything yet to the crypto field
so I agree. Then you go on and say that by applying rule 1 you
can conclude that it is possible for human beings (**) to produce
ciphers that human beings (***) cannot break. So you are
identifying (*) with (**) and (***). But the group (*) = (***)
is larger than (**) because it consists of all human beings
that have ever existed, are existing, and will exist in the future
while (**) consists of all the human beings existing up to the
point of the creation of the 'unbreakable' cipher.
I wouldn't generalize Terry Ritter's statement any further.
Regards,
CLSV
------------------------------
From: Eric Chomko <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia
Subject: Re: Economic Espionage Act of 1996 and the U.S.A. government's violations
Date: 28 Dec 1999 15:48:06 GMT
In alt.politics.org.cia Jim <[EMAIL PROTECTED]> wrote:
: On 22 Dec 1999 18:20:50 GMT, Eric Chomko <[EMAIL PROTECTED]> wrote:
: >One world economy and that many more lawyers. Man, to think how much
: >litigation we have in the US over corporate squabbles and now its going
: >worldwide. I shutter to think about needing more lawyers and on a global
: >scale. <shutter>
: Just how do you do that? Shutter.
Ah yes, another Americanism of the English language: shutter. It would
mean to writhe in disgust. Sort of like drinking a shot of really lousy
whiskey.
Eric
------------------------------
Date: Tue, 28 Dec 1999 11:04:52 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Secure Delete Not Smart
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?
It you already have a plain copy stored, encrypting it will not prevent someone
from recovering the plain copy, because the encryption does not replace the plain
copy. The encrypted file is a separate representaiton of the information in the
plain file.So the plain file still exists to be recovered.
Even if the excrypted copy replaced the plain copy sector for sector it would not
hide the plain version of the file because the replacement would only write each
sector once. To fully erase the plain version of the file you need many writes to
each sector.
The best answer is to never store plaintext. The information must be encrypted as
it is stored. Disk encryption software does this for you.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: More idiot "security problems"
Date: Tue, 28 Dec 1999 16:07:20 -0000
"CLSV" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> "Terry Ritter" <[EMAIL PROTECTED]> wrote:
> > > >> 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.
> [ * rule 1 * ]
> > > >> Here "group" includes individuals, academics, AES participants,
etc.
>
> > > Brian Gladman wrote:
> > > > Including the group of 'all human beings'.
>
> > "CLSV" <[EMAIL PROTECTED]> wrote:
> > > A cipher designed by all human beings,
> > > what is that supposed to mean?
>
> Brian Gladman wrote:
> > [...] The group of 'all human beings' has created
> > a large number of ciphers already and will continue to do so.
> > Hence the rule implies that it is possible for human beings
> > to produce ciphers that human beings cannot break.
>
> This really doesn't sound right from a logical
> point of view. You say: ciphers are created by the group
> consisting of 'all human beings' (*). As far as I know aliens
> nor dolphins have contributed anything yet to the crypto field
> so I agree. Then you go on and say that by applying rule 1 you
> can conclude that it is possible for human beings (**) to produce
> ciphers that human beings (***) cannot break. So you are
> identifying (*) with (**) and (***). But the group (*) = (***)
> is larger than (**) because it consists of all human beings
> that have ever existed, are existing, and will exist in the future
> while (**) consists of all the human beings existing up to the
> point of the creation of the 'unbreakable' cipher.
>
> I wouldn't generalize Terry Ritter's statement any further.
>
> Regards,
>
> CLSV
You are right - I was being loose with definitions for convenience. But use
any definition you wish (all now, all now and in the past, all past, present
and future,...) consistently and there is still a conclusion that I would
not trust as valid.
I suspect the rule is already too general and should refer to 'design'
rather than 'create' as you suggested in your previous post. I also suspect
that there needs to be active involvement of all members of the group in the
design process. But these are all problems with the language of the
original rule.
Brian Gladman
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Employing digits of pi
Date: Tue, 28 Dec 1999 10:05:00 -0600
The issue I can see are as follows. 1) Given you are using offsets as
keys you are generating a n*k bit key where n=number of offsets, and k=
number of bits in a specific offset.
now if n is small you are vulnerable to crib draging or the like, and if
k is small your randomness pool will be too small and you will be
vulnerable. So you need a fairly large key to implement this system --
I'd think that passing it through n k-bit conventional cyphers would
result in greater security, and probably equivalent speed.
Mok-Kong Shen wrote:
> David A Molnar wrote:
> >
>
> > Maybe one billion is still out of reach?
>
> If an analysis of the complexity of the task could show that
> with relatively small n the resource required would be astronomical,
> then one would not need to consider such questions. Hence my request:
> Would someone knowledgeable in complexity issues please examine the
> current problem?
>
> M. K. Shen
------------------------------
From: Keith Monahan <[EMAIL PROTECTED]>
Subject: Re: unbreakable?
Date: Tue, 28 Dec 1999 16:39:28 GMT
Chuck,
chuck davis wrote:
> Hello to the group. I got an email from England this morning that really
> excited me. My code (at discovervancouver.com) is beginning to stir some
> interest. I'm no cryptographer, believe me, but I've developed a cipher
> that has been up for more than five months with no winner yet.
You have to understand that a cipher isn't considered strong until the
source
code has been released AND it's been reviewed by many smart people over
a long period of time. Most people won't touch it until there is a paper
describing
the design criteria, methods used, etc. Now, bump that prize up to 75,000
canadian
and I'd assure you your message would be cracked within days.
Don't get me wrong, I'm not trying to discourage you from having contests.
I think
they are fun and wish I had time to persue most of them. But honestly,
getting the
attention of top notch people is not easy.
>
>
> The prize for cracking it goes up one cent a minute, and at the moment
> it's over $2,200 Cdn. There are no gimmicks, no commercial tie-ins, just
> a simple, honest challenge. The company I work for, Stratford Internet
> Technologies, let me do this to humor me.
>
> Have a look at discovervancouver.com and try to Crack the Code. The
> solution is a single sentence from a well-known English-language
> encyclopedia.
>
> Absolutely no clues will be given.
>
> Cheers,
>
> Chuck Davis
You don't list an ending date for the contest. Is there one? or perhaps a
ballpark estimation?
Thanks,
Keith
------------------------------
From: [EMAIL PROTECTED] (Steve K)
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 17:42:05 GMT
On Tue, 28 Dec 1999 06:37:37 -0700, "Ryan Watson" <[EMAIL PROTECTED]>
wrote:
>I visited their damndable site after reading your post. Sure enough there
>it was, each and everyplace I've been since God was a baby. I wrote them a
>nastiygram, not that it would do any good.
Um, which site? What post? I seem to be missing something here. I
assume you just discovered Deja News??
>What I want to know from you is this. #1: Where and specifically whom are
>these anonymous retailers and how do I get in touch with them. Include
>information about costs and other information if possible. #2: Is there
>some way for me to force the bastards to comply with a request for privacy?
>#3: Are there others whom provide this wonderful service to spammers, the
>government, Wal-Mart, K-Mart, mom, dad, and my brother in Boston, and his
>bloody fish? #4: Will encrypting messages with PGP stop them dead in their
>tracks or just prevent them from reading my bloody mail but continue to sale
>contact information?
You can kill your posting history in Deja and similar databases, just
by giving a fake e-mail address. See mine. I am using Free Agent,
and I simply enter a phony email address in the Options > General
Preferences > User menu.
You can use an entirely wrong address, or insert some garbage that
people can remove to get your real address & send you mail. Or you
can set up a "throw away" web mail account, and use that address.
Either way will keep most of the Spam out of your "real" mailbox. I
use the former strategy in the NGs, and the latter on my web page, and
it's been moons since I have had any spam in my "real" mailbox.
However, the headers of your posts will identify your message with a
unique serial number that your ISP can tie to you if so required.
Most of trhe time for most of the people, this does not matter. But
if required, you can get around this, also.
One of the best introductions to the software and techniques used for
anonymous mail and news, is at
http://lycaeum.org/~sunny/SimpleAnonymity.html . This site will walk
you through the simplest low-security methods, through the use of
Cypherpunk and Mixmaster remailers designed to resist professional
attacks.
BTW, anonymous mailing is free. That includes addresses at
nym.alias.net, which allow others to reply to the account holder,
without them or the service provider having the faintest idea who he
or she really is.
HTH!
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] (John Savard)
Subject: Re: unbreakable?
Date: Tue, 28 Dec 1999 17:34:25 GMT
On Tue, 28 Dec 1999 16:39:28 GMT, Keith Monahan <[EMAIL PROTECTED]>
wrote:
>You have to understand that a cipher isn't considered strong until the
>source
>code has been released AND it's been reviewed by many smart people over
>a long period of time. Most people won't touch it until there is a paper
>describing
>the design criteria, methods used, etc. Now, bump that prize up to 75,000
>canadian
>and I'd assure you your message would be cracked within days.
This isn't someone with an "unbreakable cipher"; it's merely a puzzle
contest to obtain publicity for visiting Vancouver, and hence it is
presumably a _simple_ type of cipher that can be solved with paper and
pencil that is being used.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Secure Delete Not Smart
Date: Tue, 28 Dec 1999 17:31:09 GMT
On 28 Dec 1999 03:17:28 GMT, [EMAIL PROTECTED] (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?
Huh? If you have unencrypted data on your disk, and you overwrite it
with an encrypted version of itself, instead of with random data,
that's still just one overwrite.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Employing digits of pi
Date: Tue, 28 Dec 1999 18:53:22 +0100
CLSV wrote:
>
> As I understand it you want to xor the binary expansion
> of Pi from a certain offset with your plaintext (and
> repeat this procedure with different offsets a couple
> of times) to produce the encrypted text. So you have
> to specify what offsets you want to use. (Note that any
> permutation of offsets gives you the same encrypted text
> thus reducing the effort of analysis.) I assumed that you
> wanted to choose your offsets from a reasonable set. If you
> have a key of 128 bits you can for example choose 16 offsets
> in the range of [0..255]. That is not very secure. So you'd
> probably need to choose from a much larger set which costs
> much more bits, see my previous example.#
You need not have to obtain the offsets 'directly' from your key bits.
For example, your key could be a seed to a PRNG that generates
a very long sequence of bits to give large offset values. Of course,
that 'expansion' doesn't mean obtaining more entropy than what is
in the key at all. But it does enable you to address the far remote
parts of the pi digit sequence.
I didn't propose to XOR the bits of the plaintext with the bits of
the n subsequences of pi. (Yours is a different proposal.) In my
proposed scheme the first digits of the n subsequences are
'arithmetically' added and the sum reduced modulo the base to obtain
the first digit of R. (The base of the digits could be 10 or other,
depending on the format of your pi. You might advantagesously use a
large base.) The second and following digits of R are obtained in
similar manner. After R is obtained, it is still open how one is
going to use it, as far as my article is concerned. One can XOR the
plaintext bits with the bits of R or one can do addition mod 2^32
(i.e. adding 32 bits of plaintext with 32 bits of R) or use R in any
other ways one likes, e.g. as session keys.
> The side channel attacks refer to the calculation of the
> digits of Pi which I thought (I'd be happy to be proven wrong
> here) cost more effort as their index/offset gets larger.
> I don't suppose you are going to precompute 2^64 bits and
> store them.
I have difficulty of understanding here due to my poor knowledge. For
I couldn't yet link 'side channel attack' with 'higher computational
cost'. Could you please explain a bit more?
The sequence R need only be computed to a length that one actually
requires in applications. Whether one likes to do precomputation to
a certain adequate length and store that for future use is a decision
of management outside of what I am concerned currently. Personally
I disfavour however precomputations in the present and most other
situations.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Employing digits of pi
Date: Tue, 28 Dec 1999 18:58:24 +0100
James Felling schrieb:
>
> The issue I can see are as follows. 1) Given you are using offsets as
> keys you are generating a n*k bit key where n=number of offsets, and k=
> number of bits in a specific offset.
>
> now if n is small you are vulnerable to crib draging or the like, and if
> k is small your randomness pool will be too small and you will be
> vulnerable. So you need a fairly large key to implement this system --
> I'd think that passing it through n k-bit conventional cyphers would
> result in greater security, and probably equivalent speed.
I have answered a similar question in a reply to CLSV.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: Secure Delete Not Smart
Date: Tue, 28 Dec 1999 17:55:48 GMT
On Tue, 28 Dec 1999 19:18:21 +0800, Johnny Fenton <[EMAIL PROTECTED]>
wrote:
>Steve K wrote:
>
>> 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.
>
>On that note.. Is there anyone out there who is into physically
>retrieving data as a hobby? I've always considered it a very interesting
>one and wonder what type of hardware setups etc. are required. The only
>information i can find on the web is from large data-recovery lab
>companies, most of whom use proprietary methods/equipment etc.
>
This is just speculation on my part, but I rather suspect that the
recovery methods for overwritten data would involve hooking up digital
storage oscilloscope with a *huge* custom memory (orders of magnitude
larger than the drive being examined) directly to the read-head output
of the drive. You would read the data that may have over-written the
stuff you want to recover, and use software to look at the small
variations in output voltage that indicate left-over traces of the
previously stored bits.
When this fails (as it most likely will, if the data has been
overwritten with multiple layers of junk per DoD specs for their
contractors), it's time to go into the clean room and disassemble the
drive. I don't know the right names of the devices that would be used
for the recovery, but they would be a variation on the electron
microscope, and I am sure that they are present wherever R&D is done
on hard drive design.
Probably not the kind of stuff you would do in your garage.
: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.
------------------------------
** 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
******************************
