what is GPG's #1 objective: security or anti-patent stance ( Re: on the state of PGP compatibility (2nd try))
Hi I've trimmed the Cc line a bit as this is now focussing more on GPG and not adding any thing new technically for the excluded set. On Sun, Mar 31, 2002 at 06:08:14PM -0500, David Shaw wrote: > The OpenPGP spec handles compatibility issues quite well. > The catch, of course, is that PGP 2.x isn't OpenPGP and PGP 5.x > isn't OpenPGP. PGP 6 and 7 aren't really OpenPGP either, but > they're generally close enough for all practical purposes. I don't see how this is a useful distinction. They are self-evidently not close enough for practical purposes as evidenced by the fragmented user base and ongoing problems you experience if you try using PGP. Back in the days of pgp2.x I used to receive and send a fair proportion of mail encrypted with pgp; these days it is a much lower proportion, and a rather high proportion of those fail. It's not like I'm using old software or failing to try what is reasonable to get messages to work. Even with my fairly complete collection of PGP versions you saw the results. Imagine how much worse it will be between people who do not upgrade frequently or take such defensive strategies. So you say upgrade already. However as I think I have demonstrated, I follow this strategy myself and as you can see it doesn't work either. > PGP 7 or GnuPG with the IDEA plugin can handle messages from any > version of PGP, OpenPGP or not. I can't speak of PGP 7's behavior in this discussion as it is not available for the operating system I primarily use (linux) as far as I am aware. > I doubt it's intentionally hidden, though it's certainly a pain to > find. I would characterise the situation as intentionally frustrating attempts to use IDEA. The whole point of the little exercise of stripping out the idea.c, making it a separate dynamically loadable module, tucking it away in a FAQ where you are pointed to lectures about how software and algorithm patents are bad is _specifically, and explicitly_ to discourage use of patented algorithms (and in this case of the idea.c implementation) and to encourage people to do lobby about the patent madness. Campaigning against patent madness is a good cause in itself but not when it gets in the way of privacy to the point that people are sending messages in plaintext. After all what is GPG's primary purpose: is it an email security software package focussing on security, or a platform for promulgating political views. I view the exclusion of idea.c from GPG as basically a security bug of higher severity than for example PGP2.x's manipulable fingerprint, or pgp5.something's (before it got fixed) unsigned ADK bug packet, or the potential buffer overflow in ZLIB. This bug is worse because it reproducibly and frequently causes people to send mail in clear text. The other bugs are by comparison less dangerous, yet they (the two more recent ones) were fixed by NAI, and GPG and other PGP software maintainers with rushed over-night hot fixes. I would suggest this bug would be best fixed in GPG by: a) including IDEA as a default option in GPG -- the ASCOM patent license is really very liberal for non-commercial use, and b) if that goes against the GNU philosophy to the extent that it is worth causing hinderance to hundreds of thousands of users who practically are _going_ to want it they could at least make it a configuration file option and ship it as other crypto libraries such as openSSL do. (I'm not sure how it hurts the anti-patent stance to do this -- gnupg.org is after all _already_ distributing idea.c, just separately). Adam
Re: Babel (Re: on the state of PGP compatibility)
-- On 31 Mar 2002 at 10:03, Tim May wrote: > And so now PGP (or GPG) use is utterly balkanized, utterly > useless. > > [...] > > Is there a solution? I would think that a "keep it simple, > stupid" strategy is needed: Forget the hooks into popular > mailers (Eudora, Outlook, Entourage), forget the "OS X versions > of GPG," forget the Red Hat, Mandrake, SuSE, Windows XP, etc. > versions. If PGP options have grown beyond human comprehension, perhaps everyone could use my software, which is as simple as you can get with a windows interface. http://www.echeque.com/Kong However, I predict that most people will wind up using RFC2440 (OpenPGP) compliant code. An RFC and source code is far from "utter balkanization" and utter uselessness. In due course, the best standard will win. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG uR++DP8NV5KuKFCaDraZEp6VTZQcmTqZI5aotgTD 4KXzf6dt2b3+U2MX665Iy8h+EFpHj6Vw0HKjMhvoy
Re: E-Gold
Tim May: > > > My contention is that physical gold sitting in a warehouse > > > in, say, the Bank of Bermuda, is no different from a stack > > > of $20 bills sitting in that same bank. James A. Donald: > > The difference comes when the physical stuff has to move in > > and out of the bank in Bermuda. > > > > The gold does not carry serial numbers, and if it does the > > bank can melt it down. Tim May: > I must be grossly misunderstanding something here. When I > "transfer" $1000 to an account in Bermuda, no "serial numbers" > are involved. In that case, the bank or co-conspirator doing the transfer now can connect your american identity and number of the beast, to your Bermuda identity and account number. Perhaps you would be considerably better off if serial numbers *were* involved. > > This important difference gives the issuer of that stack of > > $20 bills more power to meddle if the bank in Bermuda is > > carrying $20 bills than if the bank in Bermuda is carrying > > bars of gold. Tim May: > But it _doesn't_ store stacks of $20 bills. If it does not, then it has to have an intimate connection with a bank that does, and pressure is applied to it via that connection.
Re: IWAR Threat Model
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 lurker wrote: > from our collegues at metatempo---neither villifying nor praising > crypto/remailers etc.. in the operational world of information warfare. > > http://www.metatempo.com/IWARThreatModel.pdf Seems awfully dated and rudimentary. Current online books which go a lot deeper and put crypto its due place, dead center: Networks and Netwars: The Future of Terror, Crime, and Militancy John Arquilla, David Ronfeldt (editors) http://www.rand.org/publications/MR/MR1382/ Strategic Appraisal: The Changing Role of Information in Warfare Zalmay Khalilzad, John P. White, Andrew W. Marshall http://www.rand.org/publications/MR/MR1016/ The Emergence of Noopolitik: Toward an American Information Strategy, John Arquilla and David Ronfeldt, MR-1033-OSD,1999 http://www.rand.org/publications/MR/MR1033/ If only Tim had it in him to expand his chapter in the Vigne into a full-blown, full-length magnum opus. Failing that, I think this is about as good as it gets. ~~Faustine. *** He that would make his own liberty secure must guard even his enemy from oppression; for if he violates this duty he establishes a precedent that will reach to himself. - --Thomas Paine -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 (C) 1997-1999 Network Associates, Inc. and its affiliated companies. (Diffie-Helman/DSS-only version) iQA/AwUBPKd+sfg5Tuca7bfvEQJ7XQCfTeJPJPwwryp0CCEVGOHuM9MyN1YAn07h D5eX1QF3GFxmWNCuxbjaU0iN =JScS -END PGP SIGNATURE-
RE: IWAR Threat Model
Faustine wrote: > > http://www.metatempo.com/IWARThreatModel.pdf > > Seems awfully dated and rudimentary. Current online books which go a lot > deeper and put crypto its due place, dead center: Well, it says it's an old paper, and the audience could be general. Anyway, I enjoyed one of his other papers, and somebody else considered it worthy enough to pass along. The source that passed it along probably wouldn't ever read a RAND publication, and view the relevance of their materials the same way I view lint. I don't know Mr. Wilson's situation, but some people with operational mind-sets are "awfully dated and rudimentary," but damn good in operational contexts, whereas some people with contemporary analytical mind-sets couldn't drive a cow out of a barn unless it was a theoretical cow in a theoretical barn, the entire situation transpired on paper, and adhered to game theory, graphs and flow-charts. In contrast, operational mind-sets work best in a continual state of mistake and against the laws of gravity. Even though they might not be especially rigorous, they are especially relevant, and prone to decision-making and risk-taking, rather than analysis and hedging. :P Again, I don't know his bio, but one of his papers kind of struck me that way, and you run across it a lot in military theory. I found his style refreshing and conversational. I have great respect and appreciation for RAND people, (not just for their work, but for their approachability). My comments aren't slurring the authors you cited, nor their works, nor you. I appreciate the references of interest. ~~Aimee
Re: on the state of PGP compatibility (2nd try)
On Sun, Mar 31, 2002 at 06:08:51PM +0100, Adam Back wrote: > [This is actually slightly more accurate and even worse than my first > mail which bounced to some of the lists as I had a typo, _and_ > separately encountered a mail hub outage at cyberpass.net -- apologies > to those who get duplicates]. > > So I was trying to decrypt this stored mail sent to me by a GPG user, > and lo pgp6.x failed to decrypt it. > > So I try an older gpg I had installed, and it fails because it doesn't > support RSA or IDEA, and this GPG user it seems installed the RSA and > IDEA patches. > > So I go fetch GPG from www.gnupg.org, but it still doesn't contain > IDEA by default due to the anti-patent religion thing gone-to-far over > at GNU land, so I try to download the idea.c plugin -- except they > seem to have removed it (accidentally? hmm -- I fire off a mildly > brusque email to webmaster at gnupg.org -- and hit google.com but all > the first few hits are pointing at the gnupg.org faq with labyrinth of > links ending eventually in the same dud link.) I sympathize with your problems, but frankly (and I suspect you know this, despite your justified irritation) some of the problems you had are well beyond the scope of "PGP compatibility". It's not a flaw in PGP compatibility that PGP5.x won't compile cleanly any longer because of changes to your build platform, nor is it a flaw in PGP compatibility that some buggy program you were working with ate your PGP 2.x keyring files. The OpenPGP spec handles compatibility issues quite well. The catch, of course, is that PGP 2.x isn't OpenPGP and PGP 5.x isn't OpenPGP. PGP 6 and 7 aren't really OpenPGP either, but they're generally close enough for all practical purposes. PGP 7 or GnuPG with the IDEA plugin can handle messages from any version of PGP, OpenPGP or not. > Either way _even_ if idea.c were still where they claimed it would be > it seems intentionally very well hidden, which I think is > unconscionable for a security product: to _intentionally_ frustrate > users attempts to interoperate with secure previous versions and > alternate implementations. The IDEA plugin is available at: ftp://ftp.gnupg.dk/pub/contrib-dk/idea.c ftp://ftp.gnupg.dk/pub/contrib-dk/idea.c.sig I doubt it's intentionally hidden, though it's certainly a pain to find. David -- David Shaw | [EMAIL PROTECTED] | WWW http://www.jabberwocky.com/ +---+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson
Re: on the state of PGP compatibility (2nd try)
Adam, See Crypt::OpenPGP. http://rhumba.pair.com/ben/perl/openpgp/ It reads/writes PGP 2.x, 5.x and GNUPG compatible packets, autodetects formats, contains support for almost all ciphers present in various implementations of PGP. cheers, vipul. On Sun, Mar 31, 2002 at 06:08:51PM +0100, Adam Back wrote: > [This is actually slightly more accurate and even worse than my first > mail which bounced to some of the lists as I had a typo, _and_ > separately encountered a mail hub outage at cyberpass.net -- apologies > to those who get duplicates]. > > So I was trying to decrypt this stored mail sent to me by a GPG user, > and lo pgp6.x failed to decrypt it. > > So I try an older gpg I had installed, and it fails because it doesn't > support RSA or IDEA, and this GPG user it seems installed the RSA and > IDEA patches. > > So I go fetch GPG from www.gnupg.org, but it still doesn't contain > IDEA by default due to the anti-patent religion thing gone-to-far over > at GNU land, so I try to download the idea.c plugin -- except they > seem to have removed it (accidentally? hmm -- I fire off a mildly > brusque email to webmaster at gnupg.org -- and hit google.com but all > the first few hits are pointing at the gnupg.org faq with labyrinth of > links ending eventually in the same dud link.) > > Either way _even_ if idea.c were still where they claimed it would be > it seems intentionally very well hidden, which I think is > unconscionable for a security product: to _intentionally_ frustrate > users attempts to interoperate with secure previous versions and > alternate implementations. > > So then I try pgp5.x but the binary is using dynamic libraries that > are no longer on my shiny new redhat7.1 installation, so I try to > compile it but it no longer compiles. Tinker briefly fixing up > things, but the errors are multiple, and I haven't got time for this. > > So my last hope is pgp2.x, but some buggy pgp variant has left my > pgp2.x key ring empty, and you can't use it directly on pgp6.x > keyrings as it will barf on the new key formats. So then I ponder > exporting my private key out of pgp6.5.8 which isn't going to do it > compatibly without some serious thought -- openPGP's salted key > stretching maybe being used -- do I want to export it without a > password (not really), so figure out how do I turn the salted key > stretching off, will pgp6.5.8 even let you export private keys, or is > it easier to just extract it with a binary editor? Fortunately I > finally find a pgp2.x keyring secring.bak file (thanks PRZ), and move > it back and lo pgp2 can't decrypt it because of some unsupported > packetry. I take a look at it with Mark Shoulsen's pgpacket and it > seems that _even_ pgpacket thinks there is some unsupported packets at > the end, so dig out another packet analysis program -- pgpdump by Kazu > Yamamoto and it doesn't seem to realise it's ascii armored or is > expecting to find an external program to de-armor which is missing -- > I don't care, so use emacs and mmencode -u to produce a binary > version, and then it plays. And there lies the problem: gpg encrypted > it with IDEA using the new openPGP streaming options to encode the > message in chunks despite it being encrypted with idea (presumably the > sender forget to invoke --rfc1991 not realising my potential future > predicament). Thus sprach Kazu's analyzer: > > New: Symmetrically Encrypted Data Packet(tag 9)(512 bytes) partial start > Encrypted data [if pub/sym session key not present, sym alg - IDEA] > New: (201 bytes) partial end > > So, for now, give up. I guess it's cheaper to just send the original > author an email ask him if he remembers that idea he sent me 4 months > ago and have him send me it in clear text to be sure! > > What a nightmare! Try that sequence on a novice user and they give up > before they get past the first GPG faq with rant about algorithm > patents. > > We've really got to do something about the compatibility problems. > > Adam > -- > http://www.cypherspace.org/adam/ > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Vipul Ved Prakash Software Design Artist http://vipul.net/
Re: on the state of PGP compatibility (2nd try)
Getting caught in the upgrade scam is bad in itself. Doing this with crypto software is sin. There are no advances beyond 2.6.2 worth upgrading. If you must, use 5.5.3i and enable only IDEA and RSA/compatible. 2.6.2 runs on dos, integrates with pegasus on windoze, runs on unix and macs. Also, always keep copies of "old" software. You never know when a "feature" will be quietly introduced or dropped from the new release. For instance, try to find eudora 3.05 freeware today on the net (the last one that does everything without ads). It can be done, but it's not easy. = end (of original message) Y-a*h*o-o (yes, they scan for this) spam follows: Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/
Internet is dead (Was Re: Celsius 451 -the melting point of Cat-5)
This may sound obvious, but sometimes it's important to review the basics. There are two major issues in network connectivity: accessing and addressing. Both have to be taken care of if one is looking to build an infestation-free network. First, access, as in path between two nodes. As long as this is under centralised control (read chokable) little can be done. Current schemes seem to rely on last decade's capabilities of ISPs, NSPs and people that control the Switch. Using odd ports, stego (going via 80) will not help asymmetric bandwidth. Bear in mind that bona fide consumers do not need more than 10 kbit/sec upload speeds (CC number and product ID). It will also not foil the new generation of routers that will do full content-based switching on the fly. Clandestine content would have to be REGEX and MUST (mauhrer's universal stat test, very fast in HW) indistinguishable from legitimate traffic. The only way around this is disintermediation of routing - no ISPs, no NSPs. Self-discovering wireless (hello, Jonathan) is the first step in that direction. I don't know what will be the next one, but fucking with "Internet" is a waste of time. Addressing - as in translation from a piece of known information to the working pointer to the rest. What I use today come from three sources that I can do something about and the fourth that I cannot do anything about. 1. My bookmarks - text strings to host names or IP numbers. About 90% of lookups go through these. 2. Search engines - again, text strings to URLs, but not under my control. I could run my own spider engine and build my own database, were I not too lazy (and Google so good.) 3. DNS - name to IP. I could easily do away with this one by running my own host tables with occasional nuisance of having to update them, but considering the number of sites I visit and the rate of IP change (yes, I do keep host tables for visited hosts just in case) this is not a big deal. 4. Routing tables - since demise of forward routing, I have no control of whatever ISP/NSP chooses to do. Like sending all suspect requests via certain host in Maryland. This is basically an access issue. The issue here is not how to just REPLACE the current hierarchical addressing schemes. The issue is how to construct a new addressing mechanism which will prevent some future internic or ICANN from ever coming into existence. A choke-point free addressing (CPFA). The first requirement is counter-intuitive: the addressing must not be fully automatic. The user will HAVE to burn a number of brain cycles for each addressing operation. This is because any automated process can be subverted and eventually will lead to ICANN. Compare this with going to restaurant and ordering "meat" or "vegetables" without ever being presented with the menu. The second requirement is that authority must be completely distributed, in effect non-existent in the traditional sense. I think that the only workable solution is the one that maps on informal social structures - friends and relatives providing address pointers and routes to each other (no, this does not work for shopping at amazon - that is the whole point.) Or using principles of some other existing informal schemes - like hobos and homeless do in urban areas. If you walk close to bridges and places that they use for shelters, you will often see elaborate markings with chalk and sometimes even paint. Someone wrote a paper on this, there is a whole signalling language used to inform about many important issues - like places good to overnight at and places never to be found at. If a relatively unsophisticated population of travelling vagabonds can develop universally understood signalling that does not rely on anyone else to work, I am sure that engineers can do it as well. = end (of original message) Y-a*h*o-o (yes, they scan for this) spam follows: Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/
Re: E-Gold
On Sunday, March 31, 2002, at 10:13 AM, [EMAIL PROTECTED] wrote: >>> Even if e-gold had no anonymity and pseudonymity capabilities, >>> it is still a necessary infrastructure to support real e-cash, >>> as there is no other internet medium that supports reasonably >>> irrevocable and instant payments. > > Tim May: >> My contention is that physical gold sitting in a warehouse in, >> say, the Bank of Bermuda, is no different from a stack of $20 >> bills sitting in that same bank. > > The difference comes when the physical stuff has to move in and > out of the bank in Bermuda. > > The gold does not carry serial numbers, and if it does the bank > can melt it down. I must be grossly misunderstanding something here. When I "transfer" $1000 to an account in Bermuda, no "serial numbers" are involved. Shipment of FRNs is relatively rare, except sometimes between FR Banks. If a bank is "holding" either dollars or francs or E-gold, the traceability is at the points of entry and exit to the bank, not because of serial numbers on the dollars or francs. Again, E-gold without physical delivery of gold is just another warehouse receipt, like many other forms of money. It is no more "untraceable" than digits in an accounting book are. > The problem is not that the serial numbers > permit attacks on the customers of the Bank in Bermuda, but that > they permit attacks by the federal reserve on the Bank in Bermuda. Serial numbers on bank notes--which are not even _in_ the Bank of Bermuda except for the convenience of customers showing up at the bank's door--are NOT why FINCEN and other such entities are able to pressure Bermuda, Switzerland, etc. > > This important difference gives the issuer of that stack of $20 > bills more power to meddle if the bank in Bermuda is carrying $20 > bills than if the bank in Bermuda is carrying bars of gold. But it _doesn't_ store stacks of $20 bills. --Tim May
Re: node discover & searching (Re: Celsius 451 -the melting point of Cat-5)
At 03:25 PM 3/30/2002 +, you wrote:
>As an aside, it seems that google (and other search engines) are vying
>for first place as replacement for URLs as first line content
>location. I looked recently at the web logs on my web pages over the
>last year or so and I think > 50% of queries came from search engines
>(from referrer field). The search terms (also in the referrer field
>with google) mostly looked purposeful ("hashcash adam", "perl-rsa"
>etc, though there were a few ill-thought out or name-clash search
>terms "making hash" who probably didn't find what they were looking
>for ;-)
>
>This seems like a success factor for a would be storage-surface with
>ambitions to replace and subsume the web -- any such system has to
>have a really good google competitive search mechanism, or have a way
>for it's content to be indexed by google.
Bingo! I brought this up with the Mojo team. One of the nice features of
MN was that content was addressed as a URL. I thought that if we built a
web site that detected the presence of a spyder from Google or other major
search engine it could dynamically generate content pages for subsequent
indexing. Non-spyder visitors would get a simple greeting page. Other
would be free to do likewise, as some had done to offer Web access to P2P.
The way MN URLs were constructed, if a user had MN SW installed the URL
would directly invoke a search. If they didn't have MN SW they would be
taken to the download page.
steve
RE: IWAR Threat Model
At 10:52 AM 3/31/2002 -0600, Aimee Farr wrote: >Tim wrote: >> Says it's "7pillars," which should ring a few bells. >I like his stuff. But then, I'm partial to T.E. Lawrence. >Coincidentally, I think "Michael Wilson" was the name of the guy who wrote the movie script to Lawrence Of Arabia. That Michael Wilson was blacklisted, and never received credit for what many viewed as one of the greatest scripts of all time. You're correct. IMDB does show him as originally uncredited. He didn't work much after that. http://us.imdb.com/Credits?0056172 What an ignominious end to a promising career. Hollywood can be a star chamber. They effectively ended his career and livelihood by fiat. I certainly would not have taken that lying down. A bullet in the head of a few studio execs would have given them something else to think about besides what others thought of the Red Scare or what was for lunch at the commissary. Hush provide the worlds most secure, easy to use online applications - which solution is right for you? HushMail Secure Email http://www.hushmail.com/ HushDrive Secure Online Storage http://www.hushmail.com/hushdrive/ Hush Business - security for your Business http://www.hush.com/ Hush Enterprise - Secure Solutions for your Enterprise http://www.hush.com/ Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople
Re: E-Gold
> > Even if e-gold had no anonymity and pseudonymity capabilities, > > it is still a necessary infrastructure to support real e-cash, > > as there is no other internet medium that supports reasonably > > irrevocable and instant payments. Tim May: > My contention is that physical gold sitting in a warehouse in, > say, the Bank of Bermuda, is no different from a stack of $20 > bills sitting in that same bank. The difference comes when the physical stuff has to move in and out of the bank in Bermuda. The gold does not carry serial numbers, and if it does the bank can melt it down. The problem is not that the serial numbers permit attacks on the customers of the Bank in Bermuda, but that they permit attacks by the federal reserve on the Bank in Bermuda. This important difference gives the issuer of that stack of $20 bills more power to meddle if the bank in Bermuda is carrying $20 bills than if the bank in Bermuda is carrying bars of gold. Whether or not this is the reason that e-gold seems to be functioning in a more cashlike fashion than Paypal or any of its clones, the fact is that it *is* functioning in a more cashlike fashion than Paypal or any of its clones. Of course it might be that a bunch of gold nuts are just more likely to believe in real cashlike money than banking types, but whatever the reason, e-gold is right now the nearest thing to money you can use on the internet. > > But, in fact, it does have some limited anonymity and > > pseudonymity capabilities > > > > e-gold does not provide an anonymization mechanism, unlike > > Chaum's e-cash. But it does allow money that has been > > anonymized or pseudonymized in real space to then be moved > > electronically. Tim May: > No more so than "dollars" are moved electronically. First get your pseudonymous dollars. If you have already created a large supply of pseudonymous dollars, then naturally e-gold looks rather silly to you. But when you withdraw those pseudonymous dollars, they will have serial numbers, instantly creating a problem if you wish to make a large purchase of a good that will be associated with another identity. Thus when time comes to withdraw those pseudonymous dollars, e-gold will not look quite so silly. > Without physical delivery, who cares about actual form? Without physical delivery, who cares about whether the thing to be delivered exists or not? But private systems for moving value do sometimes have to make physical delivery. > > Let us suppose that someone takes his physical bag of gold, > > and opens an account. How can they connect the identity > > owning that account, to that person's other identities. Tim May: > The same is true of FRNs carried to a bank and deposited. > > (Yes, I know that such deposits would be nearly impossible to > make in the U.S. or in many other countries. Ditto for gold, > too. If the claim is that once dollars have been converted to > gold in an offshore bank then the offshore funds can be moved > more freely, this is so. But the same applies to dollars > converted to dollars or marks or francs in an offshore bank. The > actual _form_ of the money, whether in gold or platinum or marks > or dollars, is not even of _secondary_ importance.) In principle, offshore dollars could be moved around as easily as offshore gold. In practice it is not so. Perhaps one of the fans of offshore banking and financial structuring should set up an e-dollar that works as e-gold does. But reality is, so far they have not. > The _form_ of the money is not important. Only the trust that > delivery will happen (belief about the future behavior of > actors). > > There is nothing "magic" (pun intended) about the putative > denomination having the word "gold" in it. Your points about > untraceability would apply just as well if the units were > nominally in "dollars." Possibly. But such an e-dollar is merely potential, while the e-gold is actual. For example, if one wishes to purchase a domain name untraceably, one does so with e-gold. > > ...Absolutely true, but e-cash does need an underlying thing > > of value. At present interfacing to federal reserve notes is > > being made more and more difficult. Tim May: > The crackdown on money movements apply to all forms of money, in > all currencies or objects of value. If the underlying thing of value is federal reserve notes, then at some fairly recent point in the chain of ownership, those physical notes were in the hands of the federal reserve. If one dines with the devil, one needs a long spoon.If the underlying thing of value is gold, it probably was not in the hands of the federal reserve at any recent time. Thus the fed has a lot more leverage to crack down on the movement of notes than of gold. An offshore bank moving e-dollars has to deal the the feds directly, or through a bank that has to deal with the feds. An offshore bank moving e-gold does not have to. This may w
Re: Babel (Re: on the state of PGP compatibility)
Tim writes: > I used to think that most of the "Cypherpunks program" outlined in the > first several meetings in 1992 was still unaccomplished, with only the > most trivial of the building blocks available. Now not even those > trivial building blocks are truly available, as Adam's rant so > dramatically shows. I use PGP 2.62, under DOS, on a machine not connected to the Net. Just because Bloatware PGP for Bloatware OS is the latest version, doesn't mean one cannot use the reliable uncomplicated earlier versions. And since Bloatware OS is the weak security link here, it really doesn't matter if you had a decent PGP to run on it, does it? Later bad code does not make earlier good code unavailable. -- Eric Michael Cordian 0+ O:.T:.O:. Mathematical Munitions Division "Do What Thou Wilt Shall Be The Whole Of The Law"
Babel (Re: on the state of PGP compatibility)
(All addresses except Cypherpunks elided.) On Sunday, March 31, 2002, at 09:08 AM, Adam Back wrote: > So I was trying to decrypt this stored mail sent to me by a GPG user, > and lo pgp6.x failed to decrypt it. > > So I try an older gpg I had installed, and it fails because it doesn't > > So I go fetch GPG from www.gnupg.org, but it still doesn't contain > ... > So then I try pgp5.x but the binary is using dynamic libraries that > So my last hope is pgp2.x, but some buggy pgp variant has left my > So, for now, give up. I guess it's cheaper to just send the original > author an email ask him if he remembers that idea he sent me 4 months > ago and have him send me it in clear text to be sure! > > What a nightmare! Try that sequence on a novice user and they give up > before they get past the first GPG faq with rant about algorithm > patents. > > We've really got to do something about the compatibility problems. A good rant/summary about the current Tower of Babel situation. The beauty of the early days (perhaps two years) of early versions of PGP was that all versions basically interoperated well. Of course, people wanted more features, more integration with popular mail packages, more flexibility in choosing algorithms, and more compliance with the shifting sands of the patent world. Creeping feature-itus plus the perceived need to be "fully legal" added to the confusion. (The fact that PGP became a commercial product added in many ways to the chaos and babelization. Others can speak to the exact reasons for this, but I would offer these: NAI's requirement that algorithms and patents be free of entanglements, the proliferation of new versions without full backward compatibility, the on again/off again availability of inexpensive personal use versions, and the "diaspora" of developers once they departed NAI. Very ironic that one of the main "Down with RSADSI--RSA should be free!" chants of the early years of PGP had to do with RSA allegedly charging too much for products like MailSafe. Hence the irony of the new exorbitant pricing structure for what's left of PGP.) And so now PGP (or GPG) use is utterly balkanized, utterly useless. I used to think that most of the "Cypherpunks program" outlined in the first several meetings in 1992 was still unaccomplished, with only the most trivial of the building blocks available. Now not even those trivial building blocks are truly available, as Adam's rant so dramatically shows. Is there a solution? I would think that a "keep it simple, stupid" strategy is needed: Forget the hooks into popular mailers (Eudora, Outlook, Entourage), forget the "OS X versions of GPG," forget the Red Hat, Mandrake, SuSE, Windows XP, etc. versions. Just concentrate on a simple engine, using the cleanest C code possible. Use utterly standard I/O. (I never minded cutting an encrypted message to the clipboard--something now available in all systems, I believe--and then decrypting the clipboard contents, etc. This meant there didn't need to be "Eudora 3.1" and "Outlook Express 2.5" versions.) Drop the flexible palette of crypto algorithms. Get back to basics. And release programs which don't have to be compiled by users! Just some thoughts, from someone who no longer even tries to decrypt GPG or PGP or Bass-O-Matic messages sent to him. --Tim May "A complex system that works is invariably found to have evolved from a simple system that worked ...A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system." -- Grady Booch
on the state of PGP compatibility (2nd try)
[This is actually slightly more accurate and even worse than my first mail which bounced to some of the lists as I had a typo, _and_ separately encountered a mail hub outage at cyberpass.net -- apologies to those who get duplicates]. So I was trying to decrypt this stored mail sent to me by a GPG user, and lo pgp6.x failed to decrypt it. So I try an older gpg I had installed, and it fails because it doesn't support RSA or IDEA, and this GPG user it seems installed the RSA and IDEA patches. So I go fetch GPG from www.gnupg.org, but it still doesn't contain IDEA by default due to the anti-patent religion thing gone-to-far over at GNU land, so I try to download the idea.c plugin -- except they seem to have removed it (accidentally? hmm -- I fire off a mildly brusque email to webmaster at gnupg.org -- and hit google.com but all the first few hits are pointing at the gnupg.org faq with labyrinth of links ending eventually in the same dud link.) Either way _even_ if idea.c were still where they claimed it would be it seems intentionally very well hidden, which I think is unconscionable for a security product: to _intentionally_ frustrate users attempts to interoperate with secure previous versions and alternate implementations. So then I try pgp5.x but the binary is using dynamic libraries that are no longer on my shiny new redhat7.1 installation, so I try to compile it but it no longer compiles. Tinker briefly fixing up things, but the errors are multiple, and I haven't got time for this. So my last hope is pgp2.x, but some buggy pgp variant has left my pgp2.x key ring empty, and you can't use it directly on pgp6.x keyrings as it will barf on the new key formats. So then I ponder exporting my private key out of pgp6.5.8 which isn't going to do it compatibly without some serious thought -- openPGP's salted key stretching maybe being used -- do I want to export it without a password (not really), so figure out how do I turn the salted key stretching off, will pgp6.5.8 even let you export private keys, or is it easier to just extract it with a binary editor? Fortunately I finally find a pgp2.x keyring secring.bak file (thanks PRZ), and move it back and lo pgp2 can't decrypt it because of some unsupported packetry. I take a look at it with Mark Shoulsen's pgpacket and it seems that _even_ pgpacket thinks there is some unsupported packets at the end, so dig out another packet analysis program -- pgpdump by Kazu Yamamoto and it doesn't seem to realise it's ascii armored or is expecting to find an external program to de-armor which is missing -- I don't care, so use emacs and mmencode -u to produce a binary version, and then it plays. And there lies the problem: gpg encrypted it with IDEA using the new openPGP streaming options to encode the message in chunks despite it being encrypted with idea (presumably the sender forget to invoke --rfc1991 not realising my potential future predicament). Thus sprach Kazu's analyzer: New: Symmetrically Encrypted Data Packet(tag 9)(512 bytes) partial start Encrypted data [if pub/sym session key not present, sym alg - IDEA] New:(201 bytes) partial end So, for now, give up. I guess it's cheaper to just send the original author an email ask him if he remembers that idea he sent me 4 months ago and have him send me it in clear text to be sure! What a nightmare! Try that sequence on a novice user and they give up before they get past the first GPG faq with rant about algorithm patents. We've really got to do something about the compatibility problems. Adam -- http://www.cypherspace.org/adam/
RE: IWAR Threat Model
Tim wrote: > Says it's "7pillars," which should ring a few bells. I like his stuff. But then, I'm partial to T.E. Lawrence. Coincidentally, I think "Michael Wilson" was the name of the guy who wrote the movie script to Lawrence Of Arabia. That Michael Wilson was blacklisted, and never received credit for what many viewed as one of the greatest scripts of all time. ~~Aimee
Re: E-Gold
> The crackdown on money movements apply to all forms of money, in all > currencies or objects of value. > > --Tim May Right. Control the transfer of value and in some sence you control the value itself. The value of an object is substantially and in some cases wholely dependent on its liquidity. Control the liquidity and you control its value. Control the value of an object and its owner will forever be your slave. Home ownership is a classic example. An object that's very costly for the owner to liquidate but easy for someone else to if you don't behave. -- Julian Assange|If you want to build a ship, don't drum up people |together to collect wood or assign them tasks and [EMAIL PROTECTED] |work, but rather teach them to long for the endless [EMAIL PROTECTED] |immensity of the sea. -- Antoine de Saint Exupery
Re: Celsius 451 -the melting point of Cat-5 Re: networktopology
Steve Furlong wrote: > A list of "address servers", using any IP address and port, would be > written up in a text or binary file. This text file would be XORd with a > couple of random 128kB pads, and then sent to a newsgroup. A client who > wished to retrieve the list would read the result pad, then fetch the > random pads from any of a bunch of "pad servers". XOR them together and > read off the list. None of the sites hosting the random pads would be > holding any "restricted" information, so there'd be no justification for > closing them down. Why bother with the pads? Just post to a newsgroup in plain, surely? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: IWAR Threat Model
On Saturday, March 30, 2002, at 11:23 PM, xganon wrote: > From: ye ol lurker > > Reply to: no reply address > > from our collegues at metatempo---neither villifying nor praising > crypto/remailers etc.. in the operational world of information warfare. > > http://www.metatempo.com/IWARThreatModel.pdf > It's that old paper that looked like background notes for a Steve Jackson Games game. Sure enough, at the end is a reminder that it's a "re-release" of a 1996 paper. Says it's "7pillars," which should ring a few bells. --Tim May -- Timothy C. May [EMAIL PROTECTED]Corralitos, California Political: Co-founder Cypherpunks/crypto anarchy/Cyphernomicon Technical: physics/soft errors/Smalltalk/Squeak/agents/games/Go Personal: b.1951/UCSB/Intel '74-'86/retired/investor/motorcycles/guns
IWAR Threat Model
From: ye ol lurker Reply to: no reply address from our collegues at metatempo---neither villifying nor praising crypto/remailers etc.. in the operational world of information warfare. http://www.metatempo.com/IWARThreatModel.pdf Warning - this message generated from an anonymous web form < http://www.reachus.at/sneakypete >, senders name and email address may not be valid or may be forged
