December 2003 - cypherpunks-legacy

DNA
by Mats Bergstrom 17 Dec '03

17 Dec '03

Databases of fingerprints and retina-images might still have a future for specialized applications but DNA-typing (why not on a simple blood sample at birth) combined with a fixed social security number valid for life will probably become a widely used method for governments to control the identity of their serfs. Even without legislation stating compulsory testing of all citizens there are great possibilities with this method. Serologic tests for various reasons (i.e. HIV, rubella in pregnancy etc) are routinely performed on a majority of the population in developed countries. These samples are usually frozen and saved for decades (for the purpose of comparison if the individual should fall ill; and for research if something might get interesting) at most laboratries. DNA- analysis efter thawing is no big deal with modern techniques. So if one is planning to commit hideous crimes in the future, or if one has other reasons to maintain DNA privacy, one should demand that blood samples taken from oneself are destroyed after testing (alternatively take the tests under a pseudonym). Unfortunately there is no known method of encrypting one's DNA code in situ but hopefully they will safely (in escrow?) encrypt it in the databanks. For most purposes a cheapish imprint (sort of a hash function) of an individual's DNA code will suffice, i.e. for secure identification. Longer strains of code will give additional information on the person's genetic dispositions of course (until now only for physical diseases and risk factors but coding relating to schizophrenia and psychopathy are expected Real Soon - the science of molecular biology is in an exponential phase). For such an extended analysis it is, at least for some more years, not enough with a frozen blood sample for serologic testing or a blood/semen-stain from the clothes of a victim but culturable cell-lines are necessary. These observations were provoked by the following forwarded letter: //mb Date: Thu, 09 Jun 94 05:06:29 MST From: mednews (HICNet Medical News) To: hicnews Subject: Course: DNA Databanks and Repositories Message-ID: <iHJNNc7w165w(a)stat.com> DNA DATABANKS & REPOSITORIES will be presented 4-5 November 1994 at the Sheraton Inn Midway, St Paul Minnesota, USA. SPONSORS: Armed Forces Institute of Pathology and the American Registry of Pathology. GENERAL INFORMATION: AFIP Education Dept. (INT), 14th & Alaska Avenue, NW, Washington, DC, 20306-6000 USA; (301)427-5231; FAX (301)427-5001; or INTERNET: LOWTHER(a)email.afip.osd.mil CONTENT: DNA typing of biologic tissues and fluids has revolutionized criminalistics. This technology is so powerful that over one half of all states have legislatively mandated the creation of DNA databanks and repositories for law enforcement purposes with other states considerating the same. The passage of the federal DNA Identification Act will bolster the growth of these databanks. DNA repositories also have been established for military remains identification, for scientific human geneic diversity studies, and for numerous public health reasons. This is the third national conference devoted strictly to the establishment of DNA databanks and repositories. This conference is designed to be a practical discussion on the creation and the set-up of DNA databanks/repositories, focusing on forensic identification. It is intended for DNA repository directors, policy makers, and administrators considerating establishment of a DNA collections program, and other interested persons. Lectures will be presented on current state sex offender databanks, the FBI's National DNA Index, the DNA Identification Act, practical aspects of databank setup and administration, and the associated legal and ethical issues. Convictions based on the Minnesota State DNA Database will be featured and a tour of the Minnesota Bureau of Criminal Apprehension's facility will be conducted. (English) COURSE DIRECTOR: Victor W. Weedn, LTC, MC, USC TUITION: $220.

3 3

(None)
by Jeff Gostin 17 Dec '03

17 Dec '03

dfloyd(a)runner.utsa.edu (Douglas R. Floyd) writes: > How rude is it for people to post (or mail to a mailing list) anon messages > encrypted with someone's PGP key? It makes it easy for the receiver to > obtain it, but how irritating is it to people? Fairly. In fact, it's considered downright rude. It's like sitting around a table of, say, 3 people, and whispering with someone next to you. The first person is you -- you're sending the message. The second person is your friend -- he's recieving it. The third is me -- I'm just watching two people whispering. Further, newsgroups are a very inappropriate place to send private mail for propogation. --Jeff -- ====== ====== +----------------jgostin(a)eternal.pha.pa.us----------------+ == == | The new, improved, environmentally safe, bigger, better,| == == -= | faster, hypo-allergenic, AND politically correct .sig. | ==== ====== | Now with a new fresh lemon scent! | PGP Key Available +---------------------------------------------------------+

1 0

Re: Cantwell Bill
by catalyst-remailer＠netcom.com 17 Dec '03

17 Dec '03

Perry wrote, >For those who haven't been paying attention, the Cantwell Bill could >die in the intelligence committee. Please pay attention to Stanton >McCandlish's alert from EFF and act on it TODAY. Call up those >congressmen! When I called, most of them indicated they hadn't heard >from people. Make the phone ring off the hook with concern that this >measure pass! I *cannot* figure out why nobody has responded in a week to this new revelation, as it has total relevance to the Cantwell Bill! Once again, Sumex-aim.stanford.edu, the internet's biggest Mac ftp archive has been *EXPORTING* MacPGP2.2, many times a day, every day for over a YEAR. This is automatic, since there are mirror sites in most countries on the internet, including Singapore and China. *Had* someone picked up on this sooner, there would still be time to spread the word to the point where congresscritters would know this was going on. I don't care any more. Y'all deserve what y'git. I send my fax.

2 1

Crytography - Solution (long) (fwd)
by Jim choate 17 Dec '03

17 Dec '03

Forwarded message:

1 0

Re: (None)
by Ben.Goren＠asu.edu 17 Dec '03

17 Dec '03

At 12:50 PM 6/13/94 -0500, Jeff Gostin wrote: >dfloyd(a)runner.utsa.edu (Douglas R. Floyd) writes: > >> How rude is it for people to post (or mail to a mailing list) anon messages >> encrypted with someone's PGP key? It makes it easy for the receiver to >> obtain it, but how irritating is it to people? > Fairly. In fact, it's considered downright rude. It's like sitting >around a table of, say, 3 people, and whispering with someone next to you. >The first person is you -- you're sending the message. The second person >is your friend -- he's recieving it. The third is me -- I'm just watching >two people whispering. Further, newsgroups are a very inappropriate place >to send private mail for propogation. Might it be appropriate, though, to create an alt group for that purpose? Sort of the digital equivalent of putting "coded" messages in the personals section of your favorite newspaper's classified section. You know--"John, you have five days to pay up" means to meet at the Ritz for dinner next Thursday, and "I love you, Sally" means to run for the border. But far, far more effective digitally. Could be especailly useful for people "in the field," considering how many universities and other places permit Usenet posting without an account, so long as your IP is considered local--easier to get access. > --Jeff b& -- Ben.Goren(a)asu.edu, Arizona State University School of Music net.proselytizing (write for info): Protect your privacy; oppose Clipper. Voice concern over proposed Internet pricing schemes. Stamp out spamming. Finger ben(a)tux.music.asu.edu for PGP 2.3a public key.

3 2

Anon posts (was irritating posts...)
by dfloyd＠runner.utsa.edu 17 Dec '03

17 Dec '03

> From owner-cypherpunks(a)toad.com Mon Jun 13 14:23 CDT 1994 > X-Sender: ben@localhost > Mime-Version: 1.0 > Date: Mon, 13 Jun 1994 12:17:00 -0700 > To: cypherpunks(a)toad.com > From: Ben.Goren(a)asu.edu > Subject: Re: (None) > Precedence: bulk > > At 12:50 PM 6/13/94 -0500, Jeff Gostin wrote: > >dfloyd(a)runner.utsa.edu (Douglas R. Floyd) writes: > > > >> How rude is it for people to post (or mail to a mailing list) anon messages > >> encrypted with someone's PGP key? It makes it easy for the receiver to > >> obtain it, but how irritating is it to people? > > Fairly. In fact, it's considered downright rude. It's like sitting > >around a table of, say, 3 people, and whispering with someone next to you. > >The first person is you -- you're sending the message. The second person > >is your friend -- he's recieving it. The third is me -- I'm just watching > >two people whispering. Further, newsgroups are a very inappropriate place > >to send private mail for propogation. > > Might it be appropriate, though, to create an alt group for that purpose? > Sort of the digital equivalent of putting "coded" messages in the personals > section of your favorite newspaper's classified section. You know--"John, > you have five days to pay up" means to meet at the Ritz for dinner next > Thursday, and "I love you, Sally" means to run for the border. > > But far, far more effective digitally. > > Could be especailly useful for people "in the field," considering how many > universities and other places permit Usenet posting without an account, so > long as your IP is considered local--easier to get access. > > > --Jeff > > b& > > -- > Ben.Goren(a)asu.edu, Arizona State University School of Music > net.proselytizing (write for info): Protect your privacy; oppose Clipper. > Voice concern over proposed Internet pricing schemes. Stamp out spamming. > Finger ben(a)tux.music.asu.edu for PGP 2.3a public key. > > That is a good idea, creating a special USENET group for coded messages. Alt.security.coded.messages would be a good moniker. Personally, I am not familar with gopherholes or message havens, so I do not know how good they are, and can log telnets in. It is harder to log nntp reads of alt.security.coded.messages or such. If an admin is very nosy, they could be snooping your terminal and packets as well, though... Another idea could be an anonymous FTP site, but someone can go and delete all the messages on there, and ftps are logged as well... Any better ideas on being able to anon-post and anon-read with as few ways for a third party to log as possible? (This is for my curiosity only, as I rarely have anything worth saying that needs this much protection.)

2 1

Test; please ignore
by whitaker＠dpair.csd.sgi.com 17 Dec '03

17 Dec '03

Test; please ignore TEST Mon Jun 13 12:58:52 PDT 1994 -- Russell Earl Whitaker whitaker(a)csd.sgi.com Silicon Graphics Inc. Technical Assistance Center / Centre D'Assistance Technique / Tekunikaru Ashisutansu Sentaa Mountain View CA (415) 390-2250 ================================================================ #include <std_disclaimer.h>

1 0

Re: Anon posts (was irritating posts...)
by analyst＠Onramp.NET 17 Dec '03

17 Dec '03

Why not just use alt.test (with appropriate IGNORE subject line), alt.binaries.pictures.erotica with your data steagonograpically hidden in a JPEG or any other agreed upon group. Many anon posts would be quite irritating, esp. on a high volume list such as this one. -- Benjamin McLemore analyst(a)onramp.net

1 0

Telco snooping ... (fwd) "every time you fire up a modem" ??
by Stanton McCandlish 17 Dec '03

17 Dec '03

[Sounds like a load to me, but what the heck might as well pass it on, just in case. :] Forwarded message: From: c.zeps(a)genie.geis.com Date: Sun, 12 Jun 94 11:34:00 UTC Subject: Telco snooping ... [...] >From : ROGER CRAVENS Number : 296 of 296 To : ALL Date : 06/06/94 18:46 Subject : Big Brother Still Listeni Reference : NONE Read : [N/A] Private : NO Conf : 048 - GN - RadioTalk ********************************************************************* ======================================================================== As someone involved in the telephone industry on the level of security and data integrity... I would like to inform everyone that uses modems and/or are bbs operators of some information. The first thing that everyone that uses a modem should know is that every time you fire up your modem your activating monitoring equipment somewhere in the U.S. I have worked for several large telephone networks that routinely monitor and reroute modem and fax transmissions through devices that allow them to view what is being transmitted and even decodes encrypted data and fax packets used by major corporations and governmental agencies. This is allowed under the heading of "Maintenance Monitoring" and may be continued for up to 6 months without the need of any legal paperwork being generated. Under an obscure pre-WWII ruling by the agency that is now the FCC... "No information may be encoded or transmitted over PUBLIC or PRIVATE forms of telephony or radio with the exception of those agencies involved in the National Security" a further designation goes on to say "with the exception of the MORSE system of 'transmittal', any communication that is not interpretable by the human ear is forbidden and unlawful." The information gathered goes to 3 seperate database facilities...1 is codenamed Diana and is located in Brussels, the 2nd is named Fredrick and is located somewhere in Malaysia, the 3rd is named Elizabeth and is located in Boulder, Colorado. The information stored in these systems is accessable by the US Government, Interpol, Scotland Yard and various other such agencies. Your credit rating is also affected by your modem usage... if you ever get a copy of your credit history and find a listing that has HN06443 <--= this is a negative risk rating. or a code 87AT4 <---= an even more negative risk rating.... these will usually have no description on them... and if you inquire about them they will tell you that it just comes from the system that way. I am currently working for another major carrier as a consultant and have been able to watch these systems operate...at one unnamed long distance carrier here in Columbus Ohio in their NCC, Network Control Center, you can see several rows of computer terminals which have approximately 30 to 40 separate windows in each... these windows have data transmissions that are being monitored... banks of 9 track tapes are going constantly to record everything. Everyone should realize that even if a sysop posts a disclaimer at the beginning of his bbs about no access to governmental agencies or law enforcement...that it isn't worth the time it takes to type it in... looking forward to hearing reactions to this. --- * SLMR 2.0 * * My Castle BBS 614-236-4015 10pm to 10am M-F 6pm-6pm S-S -- Stanton McCandlish * mech(a)eff.org * Electronic Frontier Found. OnlineActivist F O R M O R E I N F O, E - M A I L T O: I N F O @ E F F . O R G O P E N P L A T F O R M O N L I N E R I G H T S V I R T U A L C U L T U R E C R Y P T O

1 0

Re: Remailer REORDER not DELAY
by fnerd＠smds.com 17 Dec '03

17 Dec '03

i wrote- > > Delay--time--isn't what matters. It's confusion about which message is > > which that matters. So if I get 10 messages in one minute, I can scramble > > the order and send them out the next minute, and I've done my job--at > > least the order-scrambling part. (You also need to pad or packetize > > messages.) > > > > So use serial numbers, not times! Send a message for every one you get, > > keep a fixed number of messages queued, and add dummies if necessary > > to keep things moving. Jim replies. > Wrongo...the random time stamp does randomly re-order then. As to bogus > messages, not on my system you won't.... Okay, first I'll go over the case where delay without dummies does NOT reorder. Then I'll go over the case where delay simply adds needless, well, delay. Then I'll talk about the cost of dummy messages. Assumption: Your remailer assigns each message a number from 0 to 59 and remails it at that minute of the hour. Whether it's hours in the day, minutes in the hour or seconds in the minute only changes which of the following two cases is more likely: Case 1: The remailer receives no messages for 61 minutes, then one message, then no messages for 61 minutes. Result: In the hour following receipt of that one message, only one message is sent. Guess which message it was. Case 2: 60 messages arrive in one minute. Result: The last one(s) go out about an hour later. They could have all been sent in the next minute with equivalent reordering. P.s., if 60 messages arrive *every* minute, under the assumption above, you have to save an average of 3600 messages. So, with this method, you can adjust the delay time down to guarantee delivery time, or up to make reordering *more likely*, but you can't guarantee reordering. If you want 1/N reordering to be likely, you need to set the response time to N times the inter-arrival time for the *quietest* traffic periods. To guarantee reordering you have to either wait indefinitely for enough messages, or after a while insert some of your own. To get over the problem of needless delay, you either need to invent some kind of tricky variable-delay scheme, or turn your attention away from clock time and focus on ordering. > I have a system which runs of a SLIP feed and bandwidth is sacrosanct. > If you would like to pay for an additional line to handle the added > load then fine but my pocket book won't support it. Say the worst turnaround you want is 24 hours, and you want to get 1-out- of-10 reordering. Then on a day where you receive only one message (for this you got a SLIP connection?) you would need to generate 9 dummies. Assuming 10Kbyte messages, the bandwidth required is... 10.4 baud. For a turnaround of 2.4 hours ... 104 baud. 15 minutes ... 1040 baud. And remember, you generate only enough dummies to keep up the minimum *total* traffic, so in reasonable-traffic periods, you generate no dummies and the amount of real traffic you can handle isn't affected. > the consideration of the future where there will be many small systems > with minimal bandwidth and monetary resources then I realy doubt they > will be interested in any system which slows down or otherwise wastes > a precious and critical resource. I guess this sentence, which you quote, wasn't clear: > > Plus, if the remailers only generate > > dummies when necessary, the total dummy traffic is self-regulating, since > > multi-hop dummies are x-lax for every remailer they pass through. In other words, in a world of communicating forwarders, a dummy message from one just looks like regular traffic to any others it goes through, and serves to keep their traffic levels up--the more remailers the fewer dummy messages each remailer has to generate. > I also oppose the implied synchronicity of your methods as well. I am > looking at a resonably secure asynchronouse method of making the > traffic analysis difficult (the real reason for all this mumbo jumbo > in the first place). Traffic analysis is difficult when the order of messages is sufficiently scrambled. If you don't reorder, then delay doesn't help. If you do reorder, then added delay doesn't help. Whether one message is "synchronized" or not with a random other message isn't useful information to an outsider. > Why should I provide a potential monitor with the > information that a certain amount of information going out will be > bogus? How might this information help analyze traffic? Also, as I mentioned, if you send your dummies to yourself indirectly, then pretty soon the level of input will match the level of output, and the ratio of bogus to real messages *won't* be visible. As far as I can see, dummy messages are simply necessary if you want to guarantee both reordering and response time. Please explain if you believe differently. > You obviously don't pay all the costs for your feed or else you are very > rich... Are you charged per byte or just a flat rate? -fnerd - - - - - - - - - - - - - - - the snack that eats like a food -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE-----

1 0