December 2003 - cypherpunks-legacy

Re: e$: The Book-Entry/Certificate Distinction
by Alan Penny 17 Dec '03

17 Dec '03

> Date: Wed, 23 Aug 1995 23:30:27 -0700 > From: tcmay(a)got.net (Timothy C. May) > Subject: Re: e$: The Book-Entry/Certificate Distinction > > At 4:10 AM 8/24/95, Alan Penny wrote: > >The other night I heard that some of the rules for selling stock have > >been changed to allow companies to sell stock directly to investors. > >I have been thinking that this may have the potential to support an > >interesting system. > > My company sold stock to me directly, through a Stock Participation Plan > and an Incentive Stock Option Plan. I think that the point of the news report was that in the past companies were limited in the type of investor they could sell to (e.g., employee, stock-broker). I assume what they meant by the report was that a company under the new rules could sell stock to anyone who asked. > > >Imagine "Portfolio Accounts" with a debit-card like access method. > > I use a debit card which directly accesses my stock account. More on this > in a moment. > > >Instead of paying for an item at a store with money or credit you use > >your Portfolio-Account card and buy the item with shares/micro-shares > >of stock. Stock brokers may offer this type of service in response the > >competition of companies bypassing them. Stock brokers could setup > >services that mediate between transactions calculating trades and values > >"on-the-fly" (anonymity could be tricky to build into this system). > > This is where it breaks down. Stock prices are denominated in dollars (or > the local currency, as applicable). And local purchases are denominated in > dollars. Nobody pays "one microMicrosoft" for a loaf of bread. They pay $1. > And Microsoft stock sells for $100, not 100 loaves of bread. Prices could still be denominated in dollars, but the actual transaction could be executed with stock value (at the current market price). There would be an element of risk in these transactions since after the transaction a stock's value might go down, but it might also go up as well. I would think that if a merchant had a large volume of transactions and a varied stock "intake" a merchants portfolio would tend to balance out in terms of stock increases and decreases. > > >If the company you worked for paid you with stock instead of money this > >would complete the loop. > > The IRS and other tax authorities have this one figured out: barter > economies are not generally a way to avoid taxes. > Oh well, you win some and you loose some :-) > >This also has the interesting feature of avoiding all taxes. Until you > >"cash out" your account you would not have to pay taxes, if you never > >need cash out your account, you never need to pay taxes. I suspect that > >our friendly governments would try to "correct" this "problem" in the > >long run if they can. > > If you are paid in barter for some service, taxes are still owed, based on > the estimated value of services rendered. > > By the way, a simpler example than all this talk of partial shares of > companies is simply to talk about paying each other in gold, or oil, or any > other commodities. Hmmm, a "micro-spot" commodity market? Cordially, [-------------------------------------------------------------------------] [ Public pgp-key: email penny(a)tyrell.net with subject as 'send pgp-key' ] [ My opinions are mine. I have scored 90% on the the Turing Test. ] [ Alan Penny, penny(a)tyrell.net ]

1 0

Thanks for all your efforts ... you can stop now ...
by Piete Brooks 17 Dec '03

17 Dec '03

The actualy attempt is now over. See http://www.brute.cam.ac.uk/brute/ (which is being updated from time to time). Thanks for your patience. Could people running old versions please kill any looping clients. Anyone wanting to try to sort out any remaining problems (NB: the load has dropped, so only the "hard faults" will remain) should contact me.

3 3

Source Code for New Encryption Algorithm
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Source Code for the Dick TruthMeasure Encryption Algorithm: (c) "The Hoff-Center of Virtual Math" ==============> |<eight inches>| + DOOM = DICK + DEATH = 2" + NULL = Nine Inch Nails ## Proof of Theorem: ## ## If she says "I want nine inches, and I want to bleed." and you give ## her two inches, four times and stab her to death, using a 6" knife, ## then 4(DICK) + 6" = 8" + 6" = Nine Inch Nails. ## ## Therefore, Nine Inch Nails band members have 14" Dicks. ## ## Basing the Private Key on Nine Inch Nails private parts, and the ## Secret Key on the secret location where the dead woman's body is ## buried, the sick, twisted creators of the "Dick TruthMeasure ## Encryption Algorithm" have produced a cryptography product which ## cannot be broken by normal people, using normal math. ## This has been confirmed by the independent research of Carol Anne ## Cypherpunk, who reports that Kent Crispin has always claimed that ## this, ================>, is eight inches, while Tim C. May claims ## this, ================>, is fourteen inches. ## Her research methods have been approved by TruthMonger, who ## states, "Give her two inches, and she takes a mile. She never ## judges an encryption algorithm until she's fucked a mile with ## your Dick in a 'rubber boot'." ## In response, Carol Anne Cypherpunk said of TruthMongers sexual ## prowess, "He claims that his Dick was the inspiration for the ## Eternity Server, but it is a forgery, like his posts to the list. ## It just _seems_ like it never ends when you are subjected to ## abuse of either of them. A mile, my ass..." <EOC> (I mean, <EOF>)

1 0

Re: PGP for pine and other Unix programs
by Jaeson.M.Engle＠dronf.org 17 Dec '03

17 Dec '03

I'd like to be added to your list of people wanting the 1.0 version. By then I should have MachTen running on my PowerPC Mac, and I would like to make sure that it works for that. Thanks Jaeson At 2:19 AM 8/23/95, Bryce Wilcox wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >> Does anyone know of an addon to the Pine mailer that supports PGP? >> the only PGP software i could find required me to first compose a >> letter in an editor then run it through a pgp signature program >> then finally read it into my favorite mailer. >> >> I'm looking for something that is hopefully transparent, or if not >> relatively quick to do. > > >My "Bryce's Auto-PGP" fits the bill. It is an sh script so it can be >integrated without too much trouble into Pine, Elm, trn, tin, mh, etc etc. >I have personally tested it with Pine so I know it'll work. You can e-mail >me for a beta copy, or you can ask for a v1.0 copy if you don't mind waiting >an unspecified amount of time for beta-testing to finish. > > >Regards, > >Bryce > >-----BEGIN PGP SIGNATURE----- >Version: 2.6.2 >Comment: Auto-signed with Bryce's Auto-PGP v1.0beta > >iQCVAwUBMDrWWfWZSllhfG25AQEpXQP+ISF5DNtNa/SbceUTPzFkHLO7YFoV01+S >t91Tt488GplyFQrimqbJpRTRtdxNjt4fR7o23F9kbRkPRtD3zQPxi0/jjT29JrNU >Oi0eiteq2FpgAoevMdkfwdsVKupW2fb78jNnz2490JHM/Zr1CvOH+2bwziQ1i8hR >5y48rjUrLTE= >=DQYq >-----END PGP SIGNATURE----- -- Jaeson M. Engle http://www.dronf.org Coordinator of the Jourvian Group PGP Mail Encouraged -> jme.pub.key(a)dronf.org Project List -> programs(a)dronf.org

1 0

Platypus and the kangaroos
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

? the Platypus {aka David Formosa} <dformosa(a)st.nepean.uws.edu.au> writes: > > E.g. read the Net.Scum page for Debbie Taylor to read > > how the homos tried to censor the Web site called "www.godhatesfags.com" > > I have no problems with that web site's existence. I haven't looked at the site (I conclude from the name that it's probably not something I care to see), but I will fight for its free speech. Apparently a number of people listed at the Net.Scum site do want to shut down this site because they don't like its name and/or contents. Agis's troubes with the (largely homosexual) Net.Cabal started before they signed up Stanford Wallace. > [1] Demitri A little bit of resurch would of established what my > sexualiaty is. For the record most of my parteners have been femail[2] David, with all due respect, I got more interesting things to research than your sexuality! :-) [2] Have any of the "others" been kangaroos? --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

2 2

Re: Demagnetizing
by alt＠iquest.net 17 Dec '03

17 Dec '03

At 04:26 PM 8/27/95 -0500, Buford Terrell wrote: > >>Reply-To: dr261(a)cleveland.Freenet.Edu (Tobin T Fricke) > >> >>Where exactly is the r/c circuit? Is it very small and in >>a label? Book publishers don't put them in, do they? >>Also, if the thing gets "burned out" by the magnet in the >>pad, what do libraries and such do where materials are >>reused? Just slap on another label thing? >> >It's much more low-tech than that. Libraries and book stores just >put a strip of magnetized material (it's much like audio tape, >about 1/8 inch wide and comes on rolls) inside the book and then >put detectors at the doorway. It the detector feels a magnetic field, >it buzzes; if the tape has been deguassed, nothing happens. > >For libraries, it's usually mounted on sticky tape and put down >inside the book spine. Bookstores usually just snip off a 4 - 5" >segment and slip it inside the book. Music stores frequently tape >a small section on the outside of CD jewel boxes. > >Sorry, there's no real mystery or exciting tech here. There's still some mystery. For instance, how does it differentiate between the magnetic field of their strip, and the magnetic field of the strip on your credit card, or the speaker on your cell phone?

1 0

Re: REPOST : Un-forgeable Cancels
by jbaber＠mi.leeds.ac.uk 17 Dec '03

17 Dec '03

Glad that the mail got through that time - not forged cancels though I am sure, more likely a cock up with my mail sppol..... > Adam Back <aba(a)dcs.ex.ac.uk> writes: > Sounds good to me. I thought there was someone doing something like > this with hashes. But then I never really looked into any of the > systems. What does Greg Rose's PGPMoose do? (One presumes it > involves PGP sigs?) I must admit that not being a news admin and rarely posting to news I have not realy looked at what is being worked on. I was just reading the 'forged cancels' thread when I though of the hash idea. >From what I can see (the full README is unavailable) PGPMoose is designed to Cancel messages in a moderated newsgroup that have not been approved by the moderator - by using PGP sigs to authenticate the approval. see http://people.qualcomm.com/ggr/pgpmoose.html This could be modified for general cancels but would then involve PGPMoose having access to every authors Public Key. > > This does assume that message IDs are available by the news program > > and are not allocated after sending. If this is not the case then it > > would be necessary to use other header information to calculate the > > hash such as the date/time and subject, or to store some kind of key > > at the authors end in order to reference the message (although in > > this case X may as well just be generated randomly and stored). > > I think you don't even need this much uniqueness of hashing > material... Personally I would prefer a unique value for every message, especially if I was a prolific sender of news. > Say you just chose a random R and store it in ~/.news-preimage, and > HASH( R ) in ~/.news-image. > > Now you post all of your posts with HASH( R ) in a header as you are > suggesting. > > Now if you didn't want to be coerced in to cancelling your own posts > you just remove .news-preimage instantly. > > You have to update your preimage for each cancel you do, but how many > cancels do people do anyway? (Not many for their own benefit I > reckon). This would work well but would allow an attacker to cancel any message sent using that value of R as soon as the author sent a message. Generally the more messages that you sent the more vulnerable you would be to this (as more of your articles would still be in the news feed) - exactly how much of a problem this would be depends on whether archivers accept cancels (which I doubt) and how long the news group in question is stored in the news spool before timing out. > This is a low security application, and ease of use over user typed > passwords will win I think. This I completely agree with, I was initally thinking of leaving the password as an Environmental variable set when the user logged on (.cshrc, .login, AUTOEXEC.BAT etc as appropriate). It makes very little difference if this is the case or if it was stored in a file, however a good news program could offer the option of using a different random/secret for any particular message if the author wanted it to be [more] secure from their systems manager. > Conceivably you could cope with the above by making .news-image > readable to the news system on your local net news service. This > could transparently do the job without needing to update any clients > -- only an INN patch required. Sounds like a phun project for > someone. This is far simpler than if you calculate a unique hash for each new message and may be the part that wins the day. > Issueing cancels would be more manual, but you could easily knock up a > perl script to instruct the NNTP server to do that. (Or windows > program, or whatever). I think that issueing cancels should be more complex than just clicking on a button - after all once you have said something there is very little reason to try to cover it up - in most cases a simple correction would do. > If you really wanted to integrate cancels without updating clients, > for those that support them you'd have to give the NNTP news server > access to your preimage, R. Not sure this is a good idea, as now your > ISP can be coerced into cancelling your message for you without your > cooperation. This would generally be a bad idea, however you should remember that the NNTP news server could simply be modified to overwrite yor Cancel_Ref: header with their own value of Y anyway or even just not forward your article, just as any news admin could (any news admin can only change those 'down the path' from them). > Course all these problems go away if you do update clients, but it's > usually nice to offer an easy interim migration path, else no-one will > use it. > > Adam Again true, however this is true for any cancel checking mechanism. As far as I can see the advantage to this idea over digital signatures is that the NNTP program that has to decide whether to accept the cancel or not does not need access to the public key of the sender. Another thing is that the modification to the NNTP program is the same whether you use a unique hash per message or a stored ~/.news-preimage as all that it has to do is check that the value included in the cancel message hashes to the value in the original message. This would allow quick updates to both NNTP and the news-reader (probably originally using the stored preimage) and later versions of the news-reader to be updated to include the unique hash (which can still operate transparently to the user, using either a file or environmental variable) without having to make any changes to the NNTP program. Thanks for the comments, Jon http://chem.leeds.ac.uk/ICAMS/people/jon/

2 1

Announcing SecureDrive 2.4
by edgar＠highnrg.sbay.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This is to announce the availability of Version 1.4 of SecureDrive. SecureDrive Version 1.4 replaces version 1.3d and previous versions. Changes for 1.4 have added significant new function. New features include ability to use a keyfile either instead of or in addition to a passphrase, the /ADD function and the option to specify a drive letter, which is remembered, when specifying manual partition parameters to LOGIN. /ADD allows you to LOGIN multiple hard disk partitions (with the same key) at the same time. The subroutine which "finds" a physical hard disk partition based on the DOS drive letter has been improved, so hopefully situations where manual partition parameters must be used will be rare. Releases 1.3, 1.3a, 1.3d and 1.4 of Secure Drive are based on releases 1.0 and 1.1, mostly written by Mike Ingle <mikeingle(a)delphi.com> and version 1.2, with significant new code by myself. The code which we wrote is not copyrighted, but the program contains GNU Copylefted code, and therefore may be freely distributed under the terms of the GNU General Public Licence. See file COPYING for legalese. SecureDrive provides strong encryption via the IDEA cypher (The same symmetrical cypher used by PGP) for your files on diskettes or up to four hard disk partitions. You encrypt your diskettes and/or HD partitions with CRYPTDSK. Then you can access the data by using LOGIN and SECTSR. This provides "on-the-fly" decryption (and re-encryption) as disk sectors are accessed by your applications. Entering LOGIN /C or powering off your PC clears the crypto keys from memory and your encrypted disks are "instantly" secure. Mike Ingle and I have different opinions on the distribution of SecureDrive. Under the GNU General License (copyleft) I do not need Mike's permission to distribute version 1.4 and I have not asked for same. My policy on distribution is in the version 1.4 doc: Exporting this program. Cryptography is export controlled, and sending this program outside the country may be illegal. Don't do it. The "author" of versions 1.2 and 1.3, Edgar Swank, says that the export ban should not prevent you from placing this program on public BBS's and anonymous FTP sites in the US and Canada. If individuals outside the US/Canada use the internet or international long distance to obtain copies of the program, THEY may be breaking US law. Any such foreign individuals should be aware that US law enforcement may legally (under US law) apprehend individuals who break US laws even if such individuals are not on or even have never been on US soil. Such apprehension may remove such individuals directly to US jurisdiction without benefit of extradition proceedings in such individuals' home country(ies). SecureDrive Version 1.4 is already available for download on the following public BBS's as SECDR14.ZIP: Flying Dutchman (408)294-3065 Colorado Catacombs BBS, 303-772-1773 (up to 28,800 bps, log in with your own name, answer the questions, and download SECDR14.ZIP). ftp://ftp.csn.net/mpj/I_will_not_export/crypto_???????/disk/secdr14.zip see ftp://ftp.csn.net/mpj/README for the ??????? ftp://miyako.dorm.duke.edu/mpj/crypto/disk/secdr14.zip See ftp://miyako.dorm.duke.edu/pub/GETTING_ACCESS for access instructions. Here is the contents of SECDR14.ZIP Length Method Size Ratio Date Time CRC-32 Attr Name ------ ------ ----- ----- ---- ---- -------- ---- ---- 18321 DeflatX 6914 63% 06-14-93 22:27 0767480b --w- COPYING 2022 DeflatX 789 61% 08-06-95 00:00 dd3e9e64 --w- COPYSECT.C 12542 DeflatX 7670 39% 08-06-95 00:00 c089888f --w- COPYSECT.EXE 152 Stored 152 0% 08-06-95 00:00 17b02bc2 --w- COPYSECT.SIG 19664 DeflatX 4183 79% 11-19-93 21:42 22c2502c --w- CRYPT2.ASM 19622 DeflatX 4594 77% 08-06-95 00:00 14940d0b --w- CRYPTDSK.C 41834 DeflatX 19854 53% 08-06-95 00:00 2e5664b8 --w- CRYPTDSK.EXE 152 Stored 152 0% 08-06-95 00:00 484719f3 --w- CRYPTDSK.SIG 4353 DeflatX 1724 61% 08-06-95 00:00 b4e99e6a --w- FPART.C 15450 DeflatX 9790 37% 08-06-95 00:00 44c4a0e7 --w- FPART.EXE 152 Stored 152 0% 08-06-95 00:00 0b345a16 --w- FPART.SIG 2998 DeflatX 2113 30% 04-22-95 13:23 1a54cbe5 --w- KEY.ASC 18447 DeflatX 4526 76% 08-06-95 00:00 d9f91a8e --w- LOGIN.C 43476 DeflatX 20274 54% 08-06-95 00:00 39b32d3d --w- LOGIN.EXE 152 Stored 152 0% 08-06-95 00:00 cb182e12 --w- LOGIN.SIG 1554 DeflatX 568 64% 08-06-95 00:00 3589f489 --w- MAKEFILE 11557 DeflatX 3277 72% 05-09-93 19:38 e71f3eea --w- MD5.C 3407 DeflatX 1097 68% 05-11-93 12:49 f1f58517 --w- MD5.H 1355 DeflatX 629 54% 01-21-94 08:44 db63ade4 --w- RLDBIOS.ASM 14757 DeflatX 4050 73% 08-06-95 00:00 2142bf7c --w- SDCOMMON.C 52175 DeflatX 18701 65% 08-06-95 00:00 da0e2c45 --w- SECDRV.DOC 3656 DeflatX 1094 71% 08-06-95 00:00 6ed75bcc --w- SECDRV.H 32595 DeflatX 8860 73% 08-06-95 00:00 1c7d2225 --w- SECTSR.ASM 2000 DeflatX 1326 34% 08-06-95 00:00 ba1568d1 --w- SECTSR.COM 152 Stored 152 0% 08-06-95 00:00 3817512c --w- SECTSR.SIG 11519 DeflatX 2801 76% 08-06-95 00:00 060d33e8 --w- SETENV.ASM 1254 DeflatX 541 57% 05-09-93 19:39 182978aa --w- USUALS.H 276 DeflatX 248 11% 08-06-95 00:00 20880832 --w- FILE_ID.DIZ ------ ------ --- ------- 335594 126383 63% 28 Also note that the ZIP file contains PGP detached signatures (*.SIG) for the executable files. Finally here is my public key, also available on many public keyservers; note who has signed it. (HighNRG is only address currently valid) Type bits/keyID Date User ID pub 1024/DA87C0C7 1992/10/17 Edgar W. Swank <edgar(a)HighNRG.sbay.org> Edgar Swank <edgar(a)Garg.Campbell.CA.US> Edgar W. Swank <edgar(a)spectrx.sbay.org> Edgar W. Swank <edgar(a)spectrx.saigon.com> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAirfypkAAAEEAKe2jziPeFw6hY19clR2GtQ4gtGCSSVOTgPKEJzHfuC74Scf 9PEuu1kebLhHk43A9wo1vr52o4jpH/P/tnFmRtBQOMzLUzAt5rMucswtSVviMQS2 hBuc9yGJKWHVcyfA79EARKEYTdhx+2qKI+hFJcPE+rmD8wVoF94nNf3ah8DHAAUR tClFZGdhciBXLiBTd2FuayAgIDxlZGdhckBIaWdoTlJHLnNiYXkub3JnPokAlQMF EC+W0kveJzX92ofAxwEB1rsEAIsfe/gJas0E9Ky+oA6I13Z4sjuECt+B9ouHFQ5m hvS5pVXCl4FM5ymMS9BaASK4nh1NK89bTtP0syGQId6G9K4YYphhuhNmIuoi6YCF G9DZo1ZseDMMcBwKMN1IMK06YhBFZXaaZGnAD9q+8IEwphqUCKQhZ+kz9np1DXI+ WleBtClFZGdhciBTd2FuayAgIDxlZGdhckBHYXJnLkNhbXBiZWxsLkNBLlVTPokA lQMFEC+SO/jeJzX92ofAxwEBCcwD/05FhVGTxYOsRjXjuEEWtndNhgX1fCpEKrtH 2kj7vnNLjZHYKqgFJhKKuu4T0RxYHweoM5zwMD0TaUlMZeeUHJTrCnS6MACf9UMS x5wdcNqptGL/LsErJudGXfEfiCtSyMtWchAuKHgE0Gxgac1yjx6LwB6RR32Mo39u V1rO3ncLtCdFZGdhciBXLiBTd2FuayA8ZWRnYXJAc3BlY3RyeC5zYmF5Lm9yZz6J AJUDBRAvTcc16RnkL8BZX5EBAc3hA/sH117w/Wk0k4dJf0QiaBpg1s1aoipl1Qg8 bmOEuKuv7jfsxHIU1b5Lge2nA1tYgWuLOe8riNwJ5fFOgiBOx8ZfZWMpsZzzdEsp 3XZ+6zjIe0Yx+vHcwDNrLANHrhO50tL9vnU3Vn3iszpwGEWH/F4Jccv/JuD9pHIp lRGrTOHkDokAlQMFEC7KUw2GKKqoYRMKGwEBG7kEANXdWUGwnnEtW7mLd02nYozA 759qDHaVx3QtM5YYB8bDV7iZh7F+/XYnoPj9hzF4Ha0nLcISPXDHBHhtq7CscYJn 8DetJ71CMAe8Zd/+W/vOqCmUqORaMU/L1tqnvpOWUNnswOkzROzOmNpw+Kq4L+oq BFuqJPDXQYYEFKOsvB9LiQCVAgUQLiSVP18k3sEYI56RAQG5TgQAnw9Wtc+GdGSc Z48hvMWZABnUiAXThw+Tq79HdPu+IySNi7aRfkSeppn9QD6v2OS8ELatgkTSuGt4 CpME6hLHB46fTiTdoXMdw+z092mOuqVF2qVKtswnFar5Fy4j0XK/4lEx2d2/1Ipa TQ+sbicGH9CqCoWOKAy1j2Ly9Jf7ZgeJAJUCBRAt1dNBocE4X0qvAOUBAQdhA/kB 2vTXCIjZGtOw/bC6gOTHnMPBVTQeXHIZ3BZ4xYRdMfdKsxN3gTezOI8QixQoHzhv NGB02fB5EdB8+Ulw9kn08AR2b+mTwkgeNtlytvNZ52E7UpWEVtznxlGeiwRMbOFI aGKJFsGXFSRw3F89ZqoUnoeRvRgL0kJIQOZCLF62ZYkAlAIFEC2o/S8YM6FlCLcH xQEBHcsD9i0o2d7Q2rsG/iRRwapxGKQbHPxgQXCB6MLVNDEa3c/png8r2PA9cOeR cwx2xY/XxNuZo7lHXNp/j5xwYhooq+yTBJIL8DZqW99QT8+c05vw7M1UCEpy7NT1 exkMzoVR/Y3jKbIa4X1tX1ZrdmoozxW0T3DwCcCZ7dR26eZXlx2JAJUCBRAtmw+u NlaXxjLdmNkBAULKA/4wqdMn2GCApAq+5kJT+iJmLvVeNZj0JVjWspGDcd+1cjCK 9XWVTATVtRAfWbDukoJ2wNzNuz7gbqVHHcrV7nvcQt3KUsxWRyahREklc75PtXBm 0PKpr5TNTM2J/Kql28GXQQyL+PHawTDQVE8ybCPj+WUgK5qd1o/2QPxnb4EAmYkA lQIFEC2bGrAPRy9bNNdNwQEBhLAD/3vWoDu4msz4YA8BcnfuovI0ApDL5ekSu447 ByXgIcqNRe4oDtGdvrqXvJhpyuj5t7vVDGtzgQE0jU8H6u+Ocpj1nBlOXL36DASS aJuLErByNCzqTaGVya5WGxmK2m+pKS6UVIXitF2tGxrKu+Pdp3rkv3oPHTWVgFT5 eGRvfJIKtClFZGdhciBXLiBTd2FuayA8ZWRnYXJAc3BlY3RyeC5zYWlnb24uY29t PokAlQIFECsRFxzidd4O/2f3CwEBsmID/2qXL/VdjGxxYFNIZdA+DC6howUXlHw6 6MUArILE2/9J69VvcpbQTKmD4A+04SwH9q8SDzWxsg+1VANuy08EE0up9pm7ZBzr xkFcOydhsEwOt9fRn9EJ3tDNYe1SVoxV9Fc47of55Om7cTNrky0hdp1LA13uf/Te V3nrBYa21zaz =LWNj - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMD9Snt4nNf3ah8DHAQFVOAP5AQPD3TESTabv35I7yBtmMFYS5VDoQB5M 7Lxz3YbDDLr15vCzKcCe58KbCit+XqL11YjQcWXFjlYY83ouIxwIWRb0AEOQq2NC MRxIC61DGLcb2ry0UCKhD5Szj9QCJE/sF3Zx9EiuKDYu0Xbx8zKv4zTpdyO1CMQS sw/NA3PbzX8= =jv0o -----END PGP SIGNATURE----- --- edgar(a)HighNRG.sbay.org Keep Freestyle Alive!

1 0

Re: Query on cookies
by Peter Trei 17 Dec '03

17 Dec '03

> Date: Thu, 7 Aug 1997 23:24:28 -0400 (EDT) > From: Declan McCullagh <declan(a)pathfinder.com> > To: "Dr.Dimitri Vulis KOTM" <dlv(a)bwalk.dm.com> > Cc: cypherpunks(a)toad.com > Subject: Re: Query on cookies > Reply-to: Declan McCullagh <declan(a)pathfinder.com> > I believe this is what the folks at Netscape tried to eliminate in 4.0, > which I'm told features four cookie settings. One rejects "third party > cookies." > > -Declan Well, I'm using version 4.01a for NT. There are three settings for cookies: 1. Accept all cookies. 2. Accept only cookies which get sent back to the originating server. 3. Disable cookies. There's also a checkbox labled: "Warn me for accepting a cookie." I've been fairly unhappy with this version - the cookie management and the "Personal Toolbar" (user specified buttons for frequently visited sites) are the only new features that seem useful. It tends to crash frequently, and the usenet news (aka "Collabra Discussion Groups") seems to be broken (some of the earlier versions had a fairly useful newsreader). It's also a disk hog. Note: This is a beta version. Peter Trei trei(a)process.com PS: I have it set on 'disable cookies'. DISCLAIMER: The above is my personal opinion only, and not neccesarily representative of my employer.

2 1

DNS key distribution/keyservers
by root 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- A while ago, Peter Trei <trei(a)toad.com> said: >Don Eastlake has actually done a draft RFC on >using the DNS for key distribution. > >It may be found at > >ftp://ietf.cnri.reston.va.us/internet-drafts/draft-ietf-dnssec-secext-04.txt [snip] I'm sure everyone agrees that a 5 meg keyfile is a bit big, but has anyone considered working on the QUALITY of the keyfile instead of making it easier to retrive QUANTITIES of keys.. Ie: What about creating one big web of trust out of current keys. Or maybe allowing keys only if they have some connection to some other key previously submitted, or simultaneously submitted. Currently, having one big keyfile creates the impression that keys distributed over a keyserver are more valid. In a sense they are, but only because someone who's being spoofed could learn of the key that is supposedly theirs. However, there's really no reason to trust a key as anything but a nym unless it's signed by someone in _your_ web of trust. I believe that modifying keyservers to accept only keys that are linked to currently known keys would encourage everyone to become part of that web of trust. After all, the public key of a nym can be obtained from the nym themself. Anybody have any thoughts on this? Don -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMEF2psLa+QKZS485AQHo/QL9GIEsboNghINgrzE5mnW/2d9i/sn4tgzw 5Ne9zerIdT0QcUWOI/ETw4pYMf8CBPD7iSU1oHxv+qoa/vgxGJCPW9fKYKPURYzE Aev2zw5Js4BnQqYKhhvPpnEEsGqnuuAd =0h+o -----END PGP SIGNATURE----- <don(a)cs.byu.edu> fRee cRyPTo! jOin the hUnt or BE tHe PrEY PGP key - http://bert.cs.byu.edu/~don or PubKey servers (0x994b8f39) June 7&14, 1995: 1st amendment repealed. Death threats ALWAYS pgp signed * This user insured by the Smith, Wesson, & Zimmermann insurance company *

1 0