Cryptography-Digest Digest #534, Volume #10 Tue, 9 Nov 99 17:13:02 EST
Contents:
Re: Signals From Intelligent Space Aliens? Forget About It. (John Kennedy)
Re: Wireless LAN suggestions? (Bill McGonigle)
Re: Steganography Academy (JPeschel)
Re: What sort of noise should encrypted stuff look like? ("Douglas A. Gwyn")
Re: Signals From Intelligent Space Aliens? Forget About It. ("Douglas A. Gwyn")
Re: Montgomery vs Sqr & Mul -- Specifics (Ian Goldberg)
Re: secrecy/generation of IV (Ian Goldberg)
Re: Lenstra on key sizes (Mok-Kong Shen)
Re: Can the SETI@home client be protected? (David Wagner)
Re: How protect HDisk against Customs when entering Great Britain (Stefek Zaba)
Re: How protect HDisk against Customs when entering Great Britain
([EMAIL PROTECTED])
Re: Signals From Intelligent Space Aliens? Forget About It. ([EMAIL PROTECTED])
Re: How protect HDisk against Customs when entering Great Britain (Albert P. Belle
Isle)
----------------------------------------------------------------------------
From: John Kennedy <[EMAIL PROTECTED]>
Subject: Re: Signals From Intelligent Space Aliens? Forget About It.
Date: Tue, 09 Nov 1999 13:43:14 -0500
On Tue, 9 Nov 1999 15:09:06 GMT, "Doug Gwyn (ISTD/CNS) <gwyn>"
<[EMAIL PROTECTED]> wrote:
>Anthony Stephen Szopa wrote:
>> I have also spoken to a math professor and he believes that we should be able
>> to achieve speeds about 90% that of light and survive the voyage.
>
>This isn't a matter of belief; it can be readily determined.
>I had an example on this topic in the notes for a course on
>relativistic field theory I gave for a small group of friends
>in 1970. Assume traveling for a certain amount of time T/2
>(measured on the spaceship) under constant forward acceleration
>G followed by deceleration at the same rate G for another
>interval T/2. From special relativity, it is easy enough to
>compute the total distance traveled, D. Then take any
>reasonable estimate of human longevity as a function of G;
>that curve maps G to T, and one can graphically solve for
>D vs. G to see how far one could actually get within a human
>lifetime.
Do you have an engineering solution to deliver an acceleration of G
for the time required?
-
John Kennedy
The Wild Shall Wild Remain!
http://members.xoom.com/rational1/wild/
------------------------------
From: [EMAIL PROTECTED] (Bill McGonigle)
Subject: Re: Wireless LAN suggestions?
Date: Tue, 09 Nov 1999 12:57:06 -0500
In article <8059l9$oup$[EMAIL PROTECTED]>, Phillip George Geiger
<[EMAIL PROTECTED]> wrote:
> Ugh. 40 bits? Is this a limitation of RC4 or just their boneheaded
> implementation? Still, I guess 40 bits is (marginally) better than zero
> bits.
It stops the casual person from sniffing. It is rather easy to set up on
the Lucent gear I'm working with. Also one has to know the Network Name
to get an access point to listen. I'm sure this isn't secure, but I
haven't found tools yet to sniff on an 802.11 net. It certainly won't
take long.
> There has GOT to be something better out there.
Yes, encrypt your datastream in software before broadcasting it on your
802.11 40-bit net.
-Bill
=====
[EMAIL PROTECTED] / FAX: (419) 710-9745
Dartmouth-Hitchcock Medical Center Clinical Computing
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Steganography Academy
Date: 09 Nov 1999 19:05:14 GMT
korejwa [EMAIL PROTECTED] writes:
>I would be interested in reading your essay, if you still have it.
>Although I have also "cracked" Fravia's Steganos Image, you may have done it
>in a different way and know things which I do not.
>
>Jean Flynn mentioned "Siko's Method" on the "Light" version of his essay
>available on all the Fravia Mirrors. Are you able to describe this method?
I have most or all of the essays from Fravia's advanced steganography
page. I am, however, considering placing them on my site if can get
Francisco's permission.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: What sort of noise should encrypted stuff look like?
Date: Tue, 9 Nov 1999 19:04:55 GMT
Lincoln Yeoh wrote:
> If that is the case if I try to decrypt stuff and fail,
> should the result still be "white noise"?
Not necessarily. For example, a system with precompression
before encryption might take a random ciphertext (with wrong
key) and decrypt it to garbage that has approximately normal
plaintext statistics.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Signals From Intelligent Space Aliens? Forget About It.
Date: Tue, 9 Nov 1999 19:07:16 GMT
"SCOTT19U.ZIP_GUY" wrote:
> While don't just tease us what distance did you come up with?
I don't have my notes with me right now and don't want to
spend time recomputing it. I'll try to look it up at home
and post a follow-up with the info.
------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Subject: Re: Montgomery vs Sqr & Mul -- Specifics
Date: 9 Nov 1999 19:24:11 GMT
In article <[EMAIL PROTECTED]>, Eric Young <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>The only slow numbers I have are from a few year ago and
>for a 486-66 (32bit words),
>which was 0.084 sec for a 512 private operation.
>Take the clock speed down to 2 mhz, multiplies are ~ 30cycles, so if you
>only have a 8*8, you have to do about 16 of them ~ 180 cycles, so
>0.084*33*6 == 16.6 seconds. It could be feasible.
I've got a slow number.
RSA 1024-bit private key op (using CRT) on a Palm Pilot (16 MHz 68000-class)
takes 28 seconds.
Slowing down by 8x (for 2MHz) and speeding up by 8x (for 512-bit instead of
1024-bit) gives you ~30 seconds back again. That's using 16x16=32 bit
multiplies. If you only have 8*8, it should be longer.
- Ian
------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Subject: Re: secrecy/generation of IV
Date: 9 Nov 1999 19:31:16 GMT
In article <804trs$gsv$[EMAIL PROTECTED]>,
David Wagner <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Allen Landsidel <[EMAIL PROTECTED]> wrote:
>> I suppose D/H could be used to agree on IVs during a session just as
>> easily as using it to generate the key..
>
>However, I'm not convinced that it really busy you anything.
It saves you the need to transmit the extra 8 bytes of IV. If you do
D-H, you're already transmitting 128 bytes, and will derive ~128 bytes
of shared data from that. May as well use it; that's more than enough
for 128-bit crypto keys, 128-bit MAC keys, and 64-bit IV's in each
direction.
- Ian
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Lenstra on key sizes
Date: Tue, 09 Nov 1999 20:21:18 +0100
DJohn37050 wrote:
>
> AES design criteria is to be suitable for a long time. It is conservative as
> we do not know what is possible a few years hence.
I believe it is indeed a good idea of AES to provide more than one
key lengths, so that different applications can make a choice
depending on their specific requirements. Apparently not everyone
agrees on that, though. Some seemingly hate all kinds of
variability/diversity and desire one single 'absolutely unique'
'standard' apparatus to serve the needs of all. I have to admit on
the other hand that such view points could not be disposed of easily.
Once I heard the opinion that, if all buildings and houses of the
world were built exactly according to some dozens of 'standard'
types, then much money could be saved, in particular the bills from
the architects. (I was unable to offer appropriate counter-arguments
on that occasion.)
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Can the SETI@home client be protected?
Date: 9 Nov 1999 11:42:53 -0800
In article <[EMAIL PROTECTED]>,
Francois Grieu <[EMAIL PROTECTED]> wrote:
> I think it is true. No general way of ensuring that data has been
> remotely processed in a prescribed way exists (that I know of),
There is a general probabilistic auditing approach based on cut-and-choose
techniques which may be useful in some cases. However, the efficiency
of the general technique will depend greatly on the application, so it's
not clear to me whether will be workable here.
Divide the computation up into N tasks, so that the tasks are largely
independent. We'd like each task to depend on only a few outputs from
the previous tasks. The more state that one must maintain between tasks,
the less efficient the technique will be.
As the client works on each task, it should generate a transcript that
proves the correctness of the computation for that task. If the task is
purely deterministic, it will suffice for the transcript to just contain
the inputs and outputs from the task.
If the task is non-deterministic (i.e., computed by a randomized
algorithm), a bit more cleverness is required. Fortunately, in this
case we may apply a bit of crypto: the server should send a small random
`seed' to the client, and the client should use a (deterministic!)
cryptographic pseudorandom generator to stretch the seed into a long
sequence of random-looking bits. (For instance, the client may use
a standard stream cipher, such as RC4, DES-OFB, etc.) This makes the
task deterministic.
After all this background, I'm finally in a position to describe the
protocol used to audit client behavior. When the client sends the claimed
output of the computation to the server, the client should also send a
_commitment_ to each of the N transcripts it generated while performing
the N tasks. The commitment may be, for example, just the hash of the
transcript using a cryptographic (collision-free) hash function such as
MD5 or SHA.
Then the server may pick a few of of the tasks at random and challenge
the client to open the corresponding commitments; if the client is
able to open the commitment correctly, and if the server can verify the
correctness of all the resulting transcripts, then we may increase our
confidence that the entire computation was correct.
If the client wants to cheat, he has to expend a considerable amount
of computation power to do so -- perhaps as much as would be required
to do the whole computation correctly. This prevents the client from
raising his ranking on the stats list through cheating.
In particular, suppose we open 10 of the transcripts at random; then the
client must calculate > 93% of the tasks correctly to get even a 1/2
chance of surviving the cheater-detection. Therefore, in this case a
cheater can run at most 7% faster than a correct client, which is enough
to prevent him from rising in the rankings very much; and even then,
there is still a significant chance of detection.
The more tasks you can split the computation into, the smaller the
relatively workload of the server. For instance, if we can break the
computation into 10000 tasks, and we check only 10 of them, then the
server has only .1% of the workload of the client.
This technique composes very well with the long-term reputation tracking
approach suggested in my previous post: if you track the correctness of
the client over many computations, and bump him if he ever is unable
to correctly open a commitment, then you can get an extremely high
probability of detecting cheaters. You can even verify the correctness
of transcripts by comparing them with transcripts from other, more-trusted
clients, rather than verifying them directly at the server.
------------------------------
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,comp.security.pgp.tech,alt.privacy,alt.privacy.anon-server
From: [EMAIL PROTECTED] (Stefek Zaba)
Subject: Re: How protect HDisk against Customs when entering Great Britain
Date: Tue, 9 Nov 1999 19:41:40 GMT
In sci.crypt, HJS ([EMAIL PROTECTED]) wrote:
> The UK Customs are so understaffed and underpaid that, as Juergen points
> out, this procedure would take hours to complete for just one passenger.
> It's nonsense with a little bit of paranoia added.
Dismissing it as "nonsene with a little bit of paranoia added" is (woefully)
uninformed. Secondary sources documenting this practice on the Web are at:
http://news.bbc.co.uk/hi/english/sci/tech/newsid_150000/150465.stm
http://www.vortex.com/privacy/priv.07.15
http://www.vortex.com/privacy/priv.08.07
For a time there was - according that most unreliable source, my personal
memory - a document at the UK Customs and Excise website, currently
http://www.hmce.gov.uk/, offering clarification of their search policy.
(A message on the ukcrypto list dated 23aug98 gave the URL as
http://www.open.gov.uk/customs/discscan.htm - this has long since faded into
the ether.) The ukcrypto message is archived at
http://www.fitug.de/debate/9808/msg00289.html
and summarises the UK Customs clarification as saying that the laptop
is in full sight of the traveller during the examination... while also
saying the data is *copied* from the laptop hard drive; a later message,
for which I can find no Web archive, contradicts this, reporting a phone
conversation with the UK Customs authorites saying the laptop is booted
from a freshly-unsealed boot floppy which is then thrown away.
The kerfuffle seemed to die down within a few months: perhaps the perceived
return (a way to catch the uninformed infosmuggler) was deemed too low
compared with the cost (Britain seen as e-backward :-)
Stefek
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,comp.security.pgp.tech,alt.privacy,alt.privacy.anon-server
Subject: Re: How protect HDisk against Customs when entering Great Britain
Date: Tue, 09 Nov 1999 19:57:11 GMT
On Sat, 06 Nov 1999 01:33:46 GMT, [EMAIL PROTECTED]
(DigitAl56K) wrote:
>>- From my knowledge, we have 2 comparable products : PGPdisk & Scramdisk. Please
>>provide advise which I should implement to achieve the best hide & camouflage
>>results.
>
>No need for PGP Disk.
>Install WinZip and move all important files/folders into the zip file
>with the "Save extra folder info", "Recurse subfolders", "Include
>system&hidden files" enabled.
>
>Once the Zip file has been successfully created encrypt it using PGP
>to your private key, selecting to erase the original copy. Next run a
>PGP Free Space Wipe on the original drive.
>
I like that. Simple, yet effective.
>
>What the hell is on your hard drive dude?
>
Hehehe... If one could elaborate, one probably wouldn't have such an
urgent need for encryption/camouflage
>
>Wrong - if illegally camoflaged material was to be found they could
>detain you and make you decrypt then encrypted info.
>Encryption stands up much stronger.
>
>>- - I'm encrypting now my files but I'm not implementing camouflage technique.
>
>That's the best way
>
How about first encrypting, followed by hiding the encrypted files??
I use a little program called encrypted magic folders to hide
directories as my 'puter is at home is also my primary machine at work
and is left on unattended much of the day (passworded etc..., but you
never know). There are things at home I don't need my kids to see and
things at work I don't need my workers to see.
I encrypt most of these files and then hide the directories. How
detectable are files/folders hidden by such a utility. It would be
hard to imagine Joe Blow Customs dude being able to find them without
bringing in the super geeks from hell at the government Orwell
division.
Even if the hidden material is found, then it should just be back to
the point of refusing to decrypt personal material as it still can't
be considered illegal without proof. Hiding the stuff might just save
a little hassle to begin with but shouldn't extend your stay at
customs for any longer than a disk full of encrypted matter.
>>Any other techniques should I use ?
>
>None, however posting here first might have customs looking out for
>you! Ever thought of that?... ;)
Still not proof that what is on the disk is legal or illegal. Things
can be embarassing enough to want to hide without being illegal...
>
>You might want to use PGPi though as US export restrictions stop you
>taking the normal PGP (which most of the world has anyway) out of the
>country.
Which I believe is the exact same thing, the only difference being
that the source code was exported as hard copy (paper and ink) which
isn't illegal rather than exported electronically, which is illegal.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.military,talk.politics.misc,talk.politics.crypto
Subject: Re: Signals From Intelligent Space Aliens? Forget About It.
Date: Tue, 09 Nov 1999 20:02:30 GMT
On Tue, 09 Nov 1999 01:18:53 GMT, Gary Carroll <[EMAIL PROTECTED]>
wrote:
>
>
>Bill Unruh wrote:
>>
>> In <[EMAIL PROTECTED]> Anthony Stephen Szopa <[EMAIL PROTECTED]>
>writes:
/snip/
>> >National Security necessitates that we must assume that there are no
>> >friendly space aliens.
>>
>> National Security necessitates that we must assume that there are no
>> friendly ghosts. We need to spend at least 10 billion a year on anti
>> ghost weapons. Much more important than protecting against space aliens.
>> (ghosts are here already and they have a much greater insight into how
>> we work and what our weaknesses are.)
>
>Ah... but we know that SOME ghosts are friendly. Casper, for instance.
He misstated his case. We would have to know there are no unfriendly
ghosts, in order to justify neglect of anti-ghost precautions.
Cheers,
Bredon
---
http://www.geocities.com/Athens/Thebes/4809
I. The Law of General Beneficence: (Golden Rule, help the community)
II. The Law of Special Beneficence (Put own family and friends first)
III. Duties to Parents, Elders, Ancestors (Respect and care for elders)
IV. Duties to Children and Posterity (Protect and care for children)
V. The Law of Justice (marriage, property, fair courts)
VI. The Law of Good Faith and Veracity (Tell truth, keep promises)
VII. The Law of Mercy (Be tender-hearted)
VIII. The Law of Magnanimity: (Soul should rule the body)
------------------------------
From: Albert P. Belle Isle <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,comp.security.pgp.tech,alt.privacy,alt.privacy.anon-server
Subject: Re: How protect HDisk against Customs when entering Great Britain
Date: Tue, 09 Nov 1999 15:10:17 -0500
Reply-To: [EMAIL PROTECTED]
On Tue, 9 Nov 1999 19:41:40 GMT, [EMAIL PROTECTED] (Stefek Zaba)
wrote:
>
>Dismissing it as "nonsene with a little bit of paranoia added" is (woefully)
>uninformed. Secondary sources documenting this practice on the Web are at:
>
> http://news.bbc.co.uk/hi/english/sci/tech/newsid_150000/150465.stm
>
> http://www.vortex.com/privacy/priv.07.15
>
> http://www.vortex.com/privacy/priv.08.07
>
>For a time there was - according that most unreliable source, my personal
>memory - a document at the UK Customs and Excise website, currently
>http://www.hmce.gov.uk/, offering clarification of their search policy.
>(A message on the ukcrypto list dated 23aug98 gave the URL as
>http://www.open.gov.uk/customs/discscan.htm - this has long since faded into
>the ether.)
A copy of the page may be found at
http://www.CerberusSystems.com/INFOSEC/discscan.htm
which was originally copied from
http://www.open.gov.uk/customs/discscan.htm
but it's heavy on justification for, and light on description of the
specific forensic technique(s) used.
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE with
Forensic Software Countermeasures
http://www.CerberusSystems.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
******************************
