Cryptography-Digest Digest #530
Cryptography-Digest Digest #530, Volume #10 Tue, 9 Nov 99 03:13:06 EST
Contents:
Re: How protect HDisk against Customs when entering Great Britain (Bill Unruh)
Re: Your Opinions on Quantum Cryptography ("Trevor Jackson, III")
Re: Lenstra on key sizes (DJohn37050)
Re: What's gpg? (Jerry Coffin)
Bracking RSA Encryption. Is it possible. ([EMAIL PROTECTED])
Re: PGP Cracked ? (Dennis Ritchie)
Re: Lenstra on key sizes (Bruce Schneier)
Re: Lenstra on key sizes (Tom St Denis)
Re: Q: Removal of bias ([EMAIL PROTECTED])
The story of a small boy --- sealed envelops --- encryption technologies (Markku J.
Saarelainen)
From: [EMAIL PROTECTED] (Bill Unruh)
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: 9 Nov 1999 01:45:29 GMT
In [EMAIL PROTECTED] [EMAIL PROTECTED] (DigitAl56K)
writes:
Even if you were detained without absolute proof of illegal data on
your PC, which would be impossible to obtain you would not have to
decrypt the data and therefore customs would be forced to hold you
indefinately (not very likely I think!) or let you go.
Actually customs has a lot more power than that. They could simply
refuse you entry and force you to fly back to your country of origin.
You could of course try raising a stink once back in your country of
origin, but it would not be terribly effective.
Customs has much more power to make you uncomfortable than you have to
make them uncomfortable.
can't force you to decrypt it.
You also cannot force them to let you into the UK.
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.
No. US law prevents you from taking any encryption, no matter where you
got it, out of the US without a license.
--
Date: Mon, 08 Nov 1999 21:13:54 -0500
From: "Trevor Jackson, III" [EMAIL PROTECTED]
Subject: Re: Your Opinions on Quantum Cryptography
John Myre wrote:
Bill Unruh wrote:
In [EMAIL PROTECTED] Jeremy Nysen [EMAIL PROTECTED] writes:
Also, quantum cryptography by itself doesn't prevent a middleman attack
(though it does make it very difficult). Which means it should be
Don;t confuse quantum crypto with quantum computing.
Also quantum crypto is immune to the "middleman" attack.
That is one of its strengths.
possible to set up a 'relay' box in between two communicating parties
that pretends to be the other. You would still need a 'relay' box for
No, that is exactly what quantum crypto prevents. Any such middle man
can be detected.
It is my understanding that quantum crypto makes it impossible
(well - arbitrarily unlikely) to eavesdrop passively, but that an
active man-in-the-middle is still possible: Alice and Bob have no
physical way to know who they are talking to. That is, Eve is
out of luck, but Mallory is still in business.
With normal communication methods, Mallory can replicate each
side exactly, thus behaving as Eve. With quantum crypto, I
think Mallory can no longer do this, as the information exchanged
is only probablistic. Mallory can pretend to be Bob while
talking to Alice, and pretend to be Alice while talking to Bob,
but he cannot ensure that the two connections end up with the
same session key.
Why does he care? If he starts by empulating the correspondents to each other,
what forces him to stop? I.e., why can he not continue maintaining the charade,
keeping both sessions independent?
So in addition to quantum crypto, you still mathematical crypto
to authenticate who you are talking to. (Even if we use the
secure quantum crypto channel to ask about maiden names, proper
authentication will require careful protocol design).
John M.
--
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Lenstra on key sizes
Date: 09 Nov 1999 02:14:32 GMT
The only reason I can see right now for using longer AES key sizes than 128 is
if quantum computers (or something similar) become real.
Don Johnson
--
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: What's gpg?
Date: Mon, 8 Nov 1999 19:32:44 -0700
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] says...
I just picked up the fact that there's a GNU version of PGP out, called
GPG or GNUPG.
I found the web page www.gnupg.org, and it makes claims that no
patented algorithms are used.
Okay.
From this claim I would assume that GPG is not as secure as PGP.
Why would you conclude that? The basics are simple: for the public-
key part, there are basically three major algorithms: Diffie-Hellman,
RSA and Elliptical-Curves. Of these, DH was patented, but the patent
has expired, and ECC hasn't ever been entirely
Cryptography-Digest Digest #531
Cryptography-Digest Digest #531, Volume #10 Tue, 9 Nov 99 08:13:03 EST
Contents:
Re: Nova program on cryptanalysis -- also cipher contest ("Douglas A. Gwyn")
Re: Can the SETI@home client be protected? (Scott Nelson)
Re: Lenstra on key sizes (Mok-Kong Shen)
Re: Lenstra on key sizes (Mok-Kong Shen)
Re: Lenstra on key sizes (Mok-Kong Shen)
Re: Can the SETI@home client be protected? (Francois Grieu)
The DVD Hack: What Next? ("http://www.hyperreal.art.pl/cypher/remailer/")
Re: Proposal: Inexpensive Method of "True Random Data" Generation (David Bernier)
Re: Build your own one-on-one compressor (Phil Norman)
Re: Can the SETI@home client be protected? (David A Molnar)
test, please ignore ("Peter Wilkinson")
Re: Montgomery vs Sqr Mul -- Specifics (Eric Young)
Re: Nova program on cryptanalysis -- also cipher contest (Frode Weierud)
Re: The DVD Hack: What Next?
Re: Phraseology [U-Boat Enigma Machines] (Anthony Stephen Szopa)
NOVA: the Code Breakers TONIGHT Nov 9 (Anthony Stephen Szopa)
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: Nova program on cryptanalysis -- also cipher contest
Date: Tue, 09 Nov 1999 06:01:27 GMT
Jan Bielawski wrote:
... I thought it has been very well documented by now
that the Enigma was broken in early '30s by 3 Poles who
worked at a Warsaw cipher bureau.
The initial break was by the Poles, but the British mathematicians
devised several important improvements (e.g., the diagonal board),
and of course the British set up the large-scale operation needed
to produce useful, timely intelligence from Enigma intercepts.
Poland, of course, was under German occupation by that time.
--
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Can the SETI@home client be protected?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 09 Nov 1999 06:22:50 GMT
On 08 Nov 1999 23:28:43 EST, [EMAIL PROTECTED] (Guy Macon) wrote:
Over in the sci.astro.seti newsgroup there has been some discussion
whether or not it is possible to protect certain software.
Here is the situation:
SETI@home [ http://setiathome.ssl.berkeley.edu/ ] is a scientific
experiment that involves millions of Internet-connected computers
in the Search for Extraterrestrial Intelligence (SETI). Participants
run a program that downloads and analyzes radio telescope data from
a server at Berkeley.
Certain people have created unauthorized patches that speed up the
client program. The scientists at the SETI project have asked that
only the autorized client be run, but the patchers will not comply.
This threatens the science behind the project by injecting possibly
corrupt data into the mix.
The scientists are working on a new version of both the client
software that you can download and the server software at Berkeley.
In the newsgroup some folks (not the SETI scientists) have opined
that it is impossible to protect the client software from such
patches, and that any such protection can be broken without breaking
the actual encryption. Is this true?
Note that those who run the patched versions want to do so, so
something like Verisign which mearly advises of modified software
isn't good enough.
Also, if a patched client gives a false positive, it will be caught
by double checking the calvulation at SETI, but if a patched client
misses ET, then the false negative will be like a needle in a haystack.
There is no need to actually prevent patched clients from running -
if the server can detect that the client is patched, it can stop
sending work to be processed, thus shutting the client down.
If the computer can understand (and therefor run) the
program, then a dedicated human can too. I've never
seen a program that successfully protected itself from
a determined hacker. While there are ways to make understanding
and modifying the program arbitrarily difficult, there's
no way to prevent it completely.
On the other hand, it sounds like the server could check
a random sampling of misses as easily as it checks the positives.
If not, you could have the client perform a hash of some of
the intermediate states so the server can, if it chooses,
check that the client actually did the work. There's no
way to pass such a test except by sending the correct data.
That doesn't prove the client isn't modified, but if it's
sending in the correct data, then why would you care
about modifications?
It's a good idea to do some double checking anyway.
There's no guarantee that even an 'approved' client is bug free.)
Scott Nelson [EMAIL PROTECTED]
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Lenstra on key sizes
Date: Tue, 09 Nov 1999 07:29:40 +0100
Roger Schlafly wrote:
Mok-Kong Shen [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
I am not sure whether your remark doesn't also well apply to the AES
project, which requires a longer key (than
Cryptography-Digest Digest #533
Cryptography-Digest Digest #533, Volume #10 Tue, 9 Nov 99 15:13:03 EST
Contents:
Re: Can the SETI@home client be protected? (Guy Macon)
OT: dates and sigs[Re: PGP Cracked ?] (Jim Gillogly)
Re: Montgomery vs Sqr Mul -- Specifics (Robert Harley)
Re: Can the SETI@home client be protected? (Guy Macon)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Scott Nelson)
Re: Signals From Intelligent Space Aliens? Forget About It. (SCOTT19U.ZIP_GUY)
Re: What sort of noise should encrypted stuff look like? (Lincoln Yeoh)
Re: Signals From Intelligent Space Aliens? Forget About It. (wtshaw)
Re: How protect HDisk against Customs when entering Great Britain (wtshaw)
Re: What sort of noise should encrypted stuff look like? (wtshaw)
Re: Can the SETI@home client be protected? (Volker Hetzer)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("Doug Gwyn
(ISTD/CNS) " [EMAIL PROTECTED])
Re: How protect HDisk against Customs when entering Great Britain (Bill McGonigle)
Re: Can the SETI@home client be protected? (Volker Hetzer)
Re: Self-certified public key.. (Volker Hetzer)
Re: Re: How protect HDisk against Customs when entering Great Britain (CoyoteRed)
ADVIL (wtshaw)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Medical
Electronics Lab)
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Can the SETI@home client be protected?
Date: 09 Nov 1999 11:21:52 EST
In article jzQV3.4769$[EMAIL PROTECTED], [EMAIL PROTECTED] (ME) wrote:
Some ideas are below
Lyal
Guy Macon wrote in message 8087tr$[EMAIL PROTECTED]...
Here is the situation:
SETI@home [ http://setiathome.ssl.berkeley.edu/ ] is a scientific
experiment that involves millions of Internet-connected computers
in the Search for Extraterrestrial Intelligence (SETI). Participants
run a program that downloads and analyzes radio telescope data from
a server at Berkeley.
Certain people have created unauthorized patches that speed up the
client program. The scientists at the SETI project have asked that
[snip]
Is this an intractable problem?
Yes
However, simple steps increase the difficulty of anyone trying to replace
the client.
I suggest a handshake process based on a challenge-reponse approach.
Start simple solution:
Issue a serial number by client.
Include serial number to track per client performance statistics.
Abberations in performance data can be detected - refuse more test data to
these clients.
End simple solution:
Complex description starts:
- Every client gets a serial number ( As a result, every client will have a
unquie hash result from MD5 or SHA etc).
- The server has a database of serial numbers, and expected hash results
(make the S/N reflect versions to address version control problems)
When the client uploads results, it must request a challenge
1) On receipt of the challenge, it produces a hash value based on the
serialised client and the challenge. This value is unique to the specific
client, and the challenge.
2) The hash and serial number are returned to the server
3) The server calculates the same hash from the serial number, the client
(the S/N version info identifies the client type/version) and the
challenge.
4) If a match, then :
a) accept the data, otherwise dump it.
b) provide more data, otherwise refuse to provide more data.
I suggest step 4 uses a server Public Key to ecnrypt the
challenge/response/serial # data, reducing the potential for spoofing.
This will prove the user has a valid client, and can reduce the potential
for invalid clients to exist.
This also allows statistical performancetracking per client. Clients
exceeding statistiscally expected performance can be considered invalid.
Refuse to supply more test data to these clients.
Not a trivial solution (server-side workload can be high) but the technology
is in use today in a commercial application to validate banking clients are
genuine.
End complex solution.
Start possibly simple solution:
Have a challenge for the fastest client that produces valid outputs on a set
of test data.
Include the fastest client in distrubutions of SET clients.
Offer kudos or a $1000 dollar challenge every month.
The unauthroised client makers may spend more time chasing the $100 than
using their clients to generate results.
End possibly simple solution
Interesting ideas! Does it help to know that the server knows the IP
address (so it can send work units) and the email address (so it can
credit the right person)? Right now those are both created upon
installation of legit or hacked versions. Right now I can download the
client and install it on multiple PCs. Maybe SETI should make the
software so that it only installs from the SETI@home server, serializes
the client, and makes it hard to get results credited to an email
address other than the one entered during the install... Just kicking
ideas around...
Cryptography-Digest Digest #535
Cryptography-Digest Digest #535, Volume #10 Tue, 9 Nov 99 20:13:03 EST Contents: Re: How protect HDisk against Customs when entering Great Britain ([EMAIL PROTECTED]) Re: Re: How protect HDisk against Customs when entering Great Britain (CoyoteRed) Re: Can the SETI@home client be protected? (John Savard) Re: Can the SETI@home client be protected? (John Savard) Re: Can the SETI@home client be protected? (John Savard) Re: Can the SETI@home client be protected? (John Savard) Re: Can the SETI@home client be protected? (Justin) Re: Lenstra on key sizes (Justin) Re: The story of a small boy --- sealed envelops --- encryption technologies (bob98g) Re: Build your own one-on-one compressor (Tim Tyler) Is there a secure-messaging service? (MDR) Re: Build your own one-on-one compressor (Tim Tyler) Re: The story of a small boy --- sealed envelops --- encryption technologies (SCOTT19U.ZIP_GUY) Re: Build your own one-on-one compressor (Tim Tyler) Re: The story of a small boy --- sealed envelops --- encryption technologies ([EMAIL PROTECTED]) Re: Compression: A ? for David Scott (Tim Tyler) 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 20:38:27 GMT On 9 Nov 1999 01:45:29 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote: No. US law prevents you from taking any encryption, no matter where you got it, out of the US without a license. Didn't realize that. So everytime the laptop goes out with PGP, encrypted browser etc..., the carrier is commiting a criminal offense? I knew that was the case with certain versions of browser encryption and with the US version of PGP but didn't think that carried over to the international versions. Guess that explains why the US version can't be obtained outside the US and why the international versions always seem to go to a site outside the US for download. Truly an example of a law that will never work as was originally intended yet will probably remain in place as it will give the authorities yet another reason to harass various individuals without a real reason. -- From: [EMAIL PROTECTED] (CoyoteRed) Subject: Re: Re: How protect HDisk against Customs when entering Great Britain Date: Tue, 09 Nov 1999 20:37:50 GMT Reply-To: this news group unless otherwise instructed! On Tue, 09 Nov 1999 19:57:11 GMT, [EMAIL PROTECTED] wrote: 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. I read the instructions on Magic Folders and it says that it does not protect against someone seeing it from a LAN, etc. You have a small program that runs at boot that hides the directories, if you don't have that file running then you have your directories in full view. I did say before to look into Magic Folder, but now I saying Magic Folders is /very/ lame. It /might/ guard against a causal viewer, but boot from a clean floppy, look in from a LAN, or maybe even bring it up in safemode, and your protection is gone. Don't rely on Magic Folders to secure your data. -- CoyoteRed CoyoteRed at bigfoot dot com http://go.to/CoyoteRed PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com -- From: [EMAIL PROTECTED] (John Savard) Subject: Re: Can the SETI@home client be protected? Date: Tue, 09 Nov 1999 20:48:39 GMT [EMAIL PROTECTED] (Guy Macon) wrote, in part: Once you find a case where the modified client gives a different answer, you have your test for that patch. The problem is that it breaks the scientific method even if the modified client gives correct answers. The scientists need to know that code X produced result Y. Hacked code lowers the confidence of any result even if it gives correct answers. This I can understand. It is possible to improve how your software is protected against unauthorized modification, although it is not possible to make it as hard to do that as it is to break encryption. It might also help, from a human engineering point of view, if there were an avenue through which suggested optimizations to the SETI@home client could be offered, and had a chance of acceptance. This wouldn't get everyone to act responsibly, but it would probably reduce the number of people motivated to act on their own like this. John Savard ( teneerf- ) http://www.ecn.ab.ca/~jsavard/crypto.htm -- From: [EMAIL PROTECTED] (John Savard) Subject: Re: Can the SETI@home client be protected? Date: Tue, 09 Nov 1999 20:49:59 GMT [EMAIL PROTECTED] (Guy Macon) wrote, in part: In article
Cryptography-Digest Digest #536
Cryptography-Digest Digest #536, Volume #10 Wed, 10 Nov 99 02:13:03 EST
Contents:
Modified Feistel network ("Adam Durana")
Re: Modified Feistel network ("Adam Durana")
Re: The story of a small boy --- sealed envelops --- encryption technologies
([EMAIL PROTECTED])
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: Modified Feistel network (David Wagner)
Re: Can the SETI@home client be protected? ("ME")
Re: The story of a small boy --- sealed envelops --- encryption technologies (Markku
J. Saarelainen)
Re: How protect HDisk against Customs when entering Great Britain (Albert P. Belle
Isle)
Re: What's gpg? (Jose Castejon-Amenedo)
Re: The story of a small boy --- sealed envelops --- encryption technologies (Markku
J. Saarelainen)
Re: Bracking RSA Encryption. Is it possible. (Jose Castejon-Amenedo)
Re: Build your own one-on-one compressor (Don Taylor)
Re: Modified Feistel network
Re: Modified Feistel network
Re: What's gpg? PHILOSOPHY 101 (Dennis Ritchie)
Re: Modified Feistel network (Tom St Denis)
Re: What sort of noise should encrypted stuff look like? (Tom St Denis)
Re: What sort of noise should encrypted stuff look like? (Tom St Denis)
Re: Signals From Intelligent Space Aliens? Forget About It. ("Trevor Jackson, III")
Re: The story of a small boy --- sealed envelops --- encryption technologies (Markku
J. Saarelainen)
Re: Can the SETI@home client be protected? ("Trevor Jackson, III")
Re: Modified Feistel network (David Wagner)
From: "Adam Durana" [EMAIL PROTECTED]
Subject: Modified Feistel network
Date: Tue, 9 Nov 1999 18:48:28 -0500
Break input into 3 pieces (L, M, R)
Li = Ri-1 xor F(Mi-1, K1)
Mi = Li-1 xor K2
Ri = Mi-1 ^ F(Li-1, K3)
Recombine the 3 pieces to get output.
After 4 rounds all pieces are influenced by the other pieces and the keys.
The influence is not even though, some pieces are influenced more by another
piece. Is this a problem? Or does anyone see any problems with this
method? Any comments would be greatly appreciated.
-- Adam
--
From: "Adam Durana" [EMAIL PROTECTED]
Subject: Re: Modified Feistel network
Date: Tue, 9 Nov 1999 18:53:16 -0500
Ri = Mi-1 ^ F(Li-1, K3)
That ^ is xor
--
From: [EMAIL PROTECTED]
Crossposted-To: alt.politics.org.cia,alt.math,soc.culture.russian
Subject: Re: The story of a small boy --- sealed envelops --- encryption technologies
Date: Tue, 09 Nov 1999 22:58:08 GMT
On Tue, 09 Nov 1999 05:34:34 GMT, Markku J. Saarelainen
[EMAIL PROTECTED] wrote:
was this young
child just smarter than many today's executives?
No. He now thinks this garbage is (i) worth reading, and (ii)
something to do with alt.math.
Dan.
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Wed, 10 Nov 1999 00:50:27 +0100
Tim Tyler wrote:
I suspect the *main* problem is finding a dictionary that actually
compresses text at all.
I assert than English text simply doesn't have anything like 65536 symbol
strings which are longer than two bytes, and which occur with approximately
equal frequency ;-(
If each word of the sentence above (where each character as ASCII
occuppies 1 byte) is replaced by 2 bytes, is that a small
compression ratio? That's bigger than one can normally achieve
when compressing the ASCII file with Huffman. Note that in the
replacing with 2 byte numbers we don't care about the frequencies
of the words.
M. K. Shen
--
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Modified Feistel network
Date: 9 Nov 1999 16:29:12 -0800
In article 1o2W3.24$[EMAIL PROTECTED],
Adam Durana [EMAIL PROTECTED] wrote:
Break input into 3 pieces (L, M, R)
Li = Ri-1 xor F(Mi-1, K1)
Mi = Li-1 xor K2
Ri = Mi-1 ^ F(Li-1, K3)
Recombine the 3 pieces to get output.
Why treat Mi so differently?
That's an obvious place where I'd start to look for attacks.
Note that you always want independent subkeys in every round,
or at least round subkeys that are different.
Maybe the following is better. Alternate the following two steps:
1. L := L xor F(R, K_i)
2. (L,M,R) := (M,R,L)
This seems like a reasonable enough way to build a cipher, _except_
that encryption and decryption are no longer symmetric. So you probably
want to do the above process for about 6 rounds, then do the reverse
process for another 6 rounds.
--
From: "ME" [EMAIL PROTECTED]
Subject: Re: Can the SETI@home client be protected?
Date: Wed, 10 Nov 1999 11:44:15 +1100
I'm not sure IP address is that useful, as some users will be dial-up, and
hence could have different IPs assigned.
Email addresses are more static.
Having multiple copies of a single client is not a problem, as long as you
can profile the different number of clients per
