- cypherpunks-legacy - lists.cpunks.org

Public-key secret sharing
by Mike Ingle 17 Dec '03

17 Dec '03

Has anyone combined polynomial secret sharing with public-key cryptography to create a public-key secret sharing system? For example, encrypt a file with a session key, SK. Use secret sharing to split SK into n parts, with m required for decryption. Encrypt each of the n parts with a different person's public key. Publish the encrypted file and public-key encrypted pieces of the key. To decrypt, m of the trustees use their secret keys to recover their shares of SK, combine them, and retrieve SK to decrypt the file. This has the advantage of requiring only one copy of the file, and requiring no pre-arrangement with the trustees. Is there a better way to do this (especially so the size of the file does not grow linearly with the number of trustees)? When is PGP 3.0 with the toolkit coming out? This should make it easy to implement these things, along with digicash and other projects. The MPI library and conventional crypto is fairly accessible, but the code which creates PGP-format packets is not easy to call from another program. --- MikeIngle(a)delphi.com

1 0

Re: Traffic analysis and file size
by hfinney＠shell.portal.com 17 Dec '03

17 Dec '03

Scott Morham asks about how well file sizes are preserved by encrypted remailers. Generally speaking, in creating a nested encrypted remailing request, at each stage PGP will attempt to compress the input, then encrypt it, which preserves its size but adds a block to the beginning of about the size of the public key (typically 100-150 bytes), then makes it ASCII, which increases the size by 1/3, then adds a small header block of 50 to 150 bytes or so. Since the compression is ASCII-encoded encrypted text, the best it can do is to "undo" the ASCII encoding or compress by about 1/4, but I don't know if it actually does that well. Probably it compresses by somewhat less. So generally each chain will add a few hundred bytes and scale the size of the message up by probably 10 or 20 percent. I think that this will probably allow pretty reliable matching of incoming and outgoing messages on the basis of size alone, at least, more reliable than I would be willing to count on to prevent attacks by this means. Scott also suggests using .zip compression at some point, but this isn't likely to help much since encrypted files look random and are basically not compressible. What we have talked about here is adding random padding to change the file size. Because encrypted files do look random, you can generally pad them with random bytes pretty easily and undetectably. This depends somewhat on the file format but it is basically easy. I wrote some perl scripts to pad .pgp public-key-encrypted files undetectably. The extra bytes are ignored when the file is decrypted. The scripts aren't really production- quality since they just use perl's built-in random numbers. Good random numbers should be used. Hal hfinney(a)shell.portal.com

1 0

Re: Remailers: Turnaround Times?
by hfinney＠shell.portal.com 17 Dec '03

17 Dec '03

Coerr asks about turnaround times for the remailers. Karl Barrus posts a list of remailers approximately every month. On that list he shows which remailers have high-speed, continuous connections to the internet and which have intermittent connections which introduce larger than normal delays. In my experience, the direct-connected remailers generally respond within a minute or two. The other ones introduce delays ranging from an hour or so up to overnight. A good test is to send a "ping" (remail to self) message to each remailer and see how quickly responses arrive. In my experience, the extropia remailer tends to take a few hours, while the rebma remailer is usually a day or sometimes longer. I don't have recent values for the others. Hal Finney hfinney(a)shell.portal.com

1 0

Secure Clear
by XXCLARK＠indst.indstate.edu 17 Dec '03

17 Dec '03

wisej <wisej(a)acf4.NYU.EDU> asked: > (M) MOTOROLA > Motorola and Secure Clear are trademarks of Motorola, Inc. (c) 1993 > Motorola, Inc. >Comments? Don't have one, but know two who do. Scramble, as I understand the meaning of the word, they don't. Last I knew, "Secure Clear" is simple frequency inversion, and can be defeated by: a $15 kit added to a scanner, or; tuning the freq on a single sideband receiver. I've even heard of individuals who had trained themselves, or been trained, to understand the freq inverted signal. Check out Cincinnati Microwave's spread spectrum frequency phones. I don't know if they use frequency hopping or direct sequence, but they may be secure against all but military and LEA types... and the really determined and accomplished hardware hacker.

1 0

taxes (net)
by Black Unicorn 17 Dec '03

17 Dec '03

-> --------------------- Tax Havens on the Net --------------------- compiled by James R. Hart Leichtenstein net access: ---f- languages: German, Alemanni currency controls: none bank secrecy: excellent preferred legal entities: allows any type found anywhere in the world (!) establishment (limited liability, unlimited duration) company limited by shares foundations and trusts taxes: none for income outside Leichtenstein. Net worth tax of 0.01% on capital and reserves (min. 1,000 Swiss francs), local resident taxes tax treaties: not party directly or indirectly to any exchange-of-information agreements double-tax treaty exists only with Austria n.b.: bankers won't assist law enforcement officials with drug, fraud, theft, or tax investigations. They might assist in money laundering and insider trading investigations, informing the customer first. Yes but, Liechtenstein, Not LEIchtenstein. :) You'll find it difficult to invest less than 1.5 million in Liechtenstein secretly. -uni- (Dark)

1 0

Re: Anonymous Video on Demand
by Hal 17 Dec '03

17 Dec '03

Jim - That is a nice protocol. Seems to work OK. I had thought of a variant: Vendor creates a set of pairs of numbers and random DES keys: (1,KEY1), (2,KEY2), (3,KEY3),... These are sent via oblivious transfer to buyer such that he only gets one but the vendor doesn't know which. Suppose buyer gets (10,KEY10). Buyer sends back a mapping of the numbers 1-N and a set of N movies. He maps the number he got in step 1 (10 in my example) with the movie he wants. Vendor encrypts these movies with the corresponding numbered DES keys, and sends them to buyer. He will only be able to decrypt one of them. These protocols have the obvious disadvantage of increasing the needed bandwidth by a factor of N. I guess we assume bandwidth is cheap. Once I get the movie, what stops me from recording it and giving copies to all my friends for free? Nothing, as far as I can see. Therefore, it would be good to think of a system where N movies are broadcast all the time (on N channels), all N encrypted, but with each person who has paid only able to decrypt one of them. You argued that people would just share keys, but I don't think that is an issue since they might as well just share movies. This system is much more acceptable in terms of bandwidth. It would be interesting to think of a solution which worked with this situation, where the encrypting keys are fixed. The requirement is, given a set of keys, 1-N, which A knows, B ends up knowing only key I, where I is chosen by B ahead of time, but A doesn't know which key B got. Off hand I don't see how to do this. Hal Finney P.S. with a little thought, a variant on my protocol can solve this, and perhaps your protocol works too. In step 1, A sends random keys to B via oblivious transfer; in step 2, B sends a mapping of key numbers and movies, pairing up the key he got and the movie he wants; in step 3, which is different, A sends not the movies, but the movie keys which will be used during the broadcast phase, encrypted with the random keys chosen in step 1. B is left with one key which will decrypt just the movie he wants during the broadcast. Maybe if this were done in tamper-proof chips like the encryption chips used in current cable boxes it would be secure enough for most purposes, at least as secure as current pay cable.

1 0

The Best Death Threat Yet
by L. Detweiler 17 Dec '03

17 Dec '03

This person claims I have `threatened' Nate Sammons, Colorado Cypherpunks Founder and Leader. I have done no such thing. Please do not send me this vomit. `Mine enemies without reason outnumber the hairs on my head.' I am only posting this in case the person is serious, whoever starts an investigation has something to go on. Death threats are illegal in the U.S.Mail, and there is probably a pretty good case to be made they are illegal in email as well. I'm not aware of any legal precedents. Maybe someone could post on the subject. ===cut=here===

1 0

Re: Anonymous Video on Demand
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Mike Ingle writes: >Are you thinking of physical videotape or electronic distribution? Electronic distribution. "Anonymous video on demand" is a bit misleading, because I'm not so much interested in preventing the video provider from knowing my identity, just from correlating my identity with my video selections. >For electronic distribution, suppose you have a fiber-optic cable with >n channels, where n is a large number. My feeling is that this architecture is too inflexible. Here's the sort of thing I have in mind: Customer browses the video supplier's catalog and notes the catalog number of the video it wants Customer randomly chooses 99 other catalog numbers to generate a pool of 100 catalog numbers. The Customer and the Video Provider engage in a protocol so that the Customer ends up receiving 100 compressed and encrypted videos, only one of which the Customer can successfully decrypt (and uncompress). The Video Provider never learns which of the 100 videos the Customer successfully decrypts, but is sure that the Customer can decrypt only one of them. I don't know what the protocol would be, but it sounds like an ANDOS-like protocol. By the way, I think that if the "rental" fee is low enough, the Video Provider wont have to worry about cheaters. If it costs you more money (or time) to cheat the Video Provider than it does to simply pay the fee, then most people will pay the fee. I'm thinking the fee would be as small as 25 cents/video, for example. Jim_Miller(a)suite.com

2 1

_The Hacker Crackdown_ on-line
by Anonymous 17 Dec '03

17 Dec '03

Excuse the repost, but this is interesting stuff. From: kadie(a)cs.uiuc.edu (Carl M Kadie) Subject: _The Hacker Crackdown_ on-line Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL Date: Sat, 1 Jan 1994 20:40:43 GMT The short of it: To access Bruce Sterling's _The hacker crackdown: law and disorder on the electronic frontier_, try gopher -p1/Publications/authors/Sterling/hc gopher.well.sf.ca.us 70 The long of it: I've directed followup to this article to comp.org.eff.talk. I found _The Hacker Crackdown_ with the CAF/WELL whatsnew server (gopher gopher.eff.org 5070). You can access the book via email. For details, send email to archive-server(a)eff.org. Include the line: send acad-freedom/admin access The electronic version of the book is being released as "literary freeware". Here is the library entry for the paper version of the book. Sterling, Bruce. The hacker crackdown : law and disorder on the electronic frontier / Bruce Sterling. New York : Bantam Books, c1992. xiv, 328 p. ; 24 cm. Includes index. Published simultaneously in the United States and Canada. ISBN 055308058X : $$23.00 ($$28.00 Can.) 1. Computer crimes--United States. 2. Programming (Electronic computers)--Corrupt practices. 3. Telephone--United States--Corrupt practices. I. Title. ocm25-914955 - Carl -- Carl Kadie -- I do not represent any organization; this is just me. = kadie(a)cs.uiuc.edu =

1 0

Re: Anonymous Video on Demand
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

could As I think about it more, the "anonymous video on demand" problem can be solved with an oblivious transfer protocol. Here's how I see it working: (The following is adapted from the oblivious transfer protocol described in "Applied Cryptography" on page 98.) Say Alice is the Video Vendor and Bob is the customer... Alice generates a public/private key pair for each movie in her video database and publishes the public keys in an electronic catalog. Each public key would be paired with a movie description and a catalog index number. Bob downloads Alice's catalog and browses through it offline. Bob makes a selection, and also randomly picks 99 (or any large number) other catalog numbers Bob generates a random DES key and encrypts this key with the public key associated with his selection. Bob sends the encrypted DES key and the list of 100 catalog numbers to Alice. Alice decrypts the DES key with the private key associated each catalog number received from Bob. In only one case will Alice successfully recover Bob's DES key, only she doesn't know which case. Alice encrypts each movie selection with the resulting DES keys from the previous step and sends all 100 encrypted movies to Bob. Bob will only be able to decrypt and view the movie he selected and Alice wont know which of the 100 movies Bob selected. Ta Da! The nice thing about this protocol is that it doesn't really have anything to do with videos. It could be used for an electronic library, or any warehouse of digital information where the Vendor wishes to charge for a download, yet the Customer doesn't want the Vendor to know which item is selected. Also, the Vendor still can use statistical analysis to determine which items are more popular and which items are less popular. The Vendor could keep track of how many times an item was mentioned in a Customer selection list. The more popular items would appear in more lists. Unpopular items would have different statistics. This analysis breaks down if all items are equally popular, or Customers don't chose the other 99 items randomly. Jim_Miller(a)suite.com

3 2