[Cryptography] psyops
Bumber sticker: Remember, the NSA is Backing You Up ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: Linux-based wireless mesh suite adds crypto engine support
At 03:25 PM 9/30/04 -0700, John Gilmore wrote: Crypto hardware that generates random numbers can't be tested in production in many useful ways. My suggestion would be to XOR a hardware-generated and a software-generated random number stream. If one fails, whether by accident, malice, or design, the other will still randomize the resulting stream. Belt AND suspenders will keep your source of randomness from being your weakest link. A good idea, but also: consider that hardware based RNGs are not so hard to make. An FM radio soundcard, audio digitizer, and some homebrew (perhaps standard-crypto-hash-based) software suffices for moderate bandwidth true RNG construction. Using an evaluation metric like Diehard and/or a Shannon or Mauer entropy measure ices the cake (as well as being required for initial and continuing monitoring). (Insert the usual caveats about PRNGs being undetectable, OS subversion, white vans driving your FM hiss, etc.) Very cheap and if you can master a hash function component, not tricky. Obviously too much trouble for Joe Sixpack, but I think that certain online gambling houses (not US of course) have made their own sources, and definately not too hard for anyone who codes and has crypto-clue. OTOH Joe can benefit from his radio-tuner card plus off the shelf inspectable software since he ought not to trust Bigcorp's embedded nominal RNG. Joe Sixpack might also be an abbreviation for a foreign government. Should the Pakis really trust Intel's RNG? PS: your belts and suspenders argument also applies to trusting cipher algorithms. Best to chain a few. Also useful to twiddle a few S-box bits, even if you get suboptimal properties, so as to deter cheap crackers using COTS cipher chips. (Doing dictionary regexp search, not the impractical exhaustive search, of course.) This works particularly well in large random-S-box constructs like Blowfish (et al) compared to the more spartan (thus degradable) DES S-boxes. The weakest link will be bipedal for the forseeable future. = 36 Laurelwood Dr Irvine CA 92620-1299 VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP ICBM: -117.7621, 33.7275 PGP PUBLIC KEY: by arrangement Send plain ASCII text not HTML lest ye be misquoted. Really. -- Don't 'sir' me, young man, you have no idea who you're dealing with Tommy Lee Jones, MIB - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: An interesting new computer security problem
At 12:58 PM 9/27/04 -0600, Anne Lynn Wheeler wrote: At 11:03 PM 9/24/2004, Peter Gutmann wrote: A few days ago I was chatting with some people working on a government IT project who had a rather complex security problem that they needed help with. They have a large number of users with Windows dumb terminals (think Xterms but for Windows) connected to a central ASP server, which runs various mutually untrusted apps from different vendors. Their problem was that they needed a means of securing the individual apps from each other. I told them that they were in luck, and this exact problem had already been addressed before. I'd drop off the detailed technical specs for the solution when I next saw them, they could recognise it by its bright orange cover. Put each app on a separate machine, and don't put any networking equiptment in the machines. Simple. = 36 Laurelwood Dr Irvine CA 92620-1299 VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP ICBM: -117.7621, 33.7275 PGP PUBLIC KEY: by arrangement Send plain ASCII text not HTML lest ye be misquoted. Really. -- Don't 'sir' me, young man, you have no idea who you're dealing with Tommy Lee Jones, MIB - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Approximate hashes
At 06:02 PM 9/1/04 +0300, Marcel Popescu wrote: From: Marcel Popescu [EMAIL PROTECTED] Hence my question: is there some approximate hash function (which I could use instead of SHA-1) which can verify that a text hashes very close to a value? So that if I change, say, tabs into spaces, I won't get exactly the same value, but I would get a good enough? This is completely what secure hashes are supposed to prevent. *Any* change in the input will flip half the hash-bits on average. Just like a block cipher. There is no input nearness preservation. That's part of the point of the algorithm. I just had an idea. Would this work? - let S be the input string, whose hash I want to verify - make S uppercase - remove everything but A-Z, 0-9, and common punctuation (!;:',.?) - calculate the SHA1 hash of the result This should keep any insignificant changes out of the final result. You can encode your message in some format which is not subject to mangling, and use a hash of that encoding. You can then decode the encoding back into unicode or whatever funky but net-fragile character set you like. This is somewhat like ascii-armoring of PGP-encrypted messages. = 36 Laurelwood Dr Irvine CA 92620-1299 VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP ICBM: -117.7621, 33.7275 HTTP: http://68.5.216.23:81 (back up, but not 99.999% reliable) PGP PUBLIC KEY: by arrangement Send plain ASCII text not HTML lest ye be misquoted -- Don't 'sir' me, young man, you have no idea who you're dealing with Tommy Lee Jones, MIB No, you're not 'tripping', that is an emu ---Hank R. Hill - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: titles
At 12:34 AM 8/27/04 +0100, Ian Grigg wrote: David Honig wrote: Security Engineer, according to Schneier... I don't like that term for 3 reasons: firstly, when we build stuff, security should be top-to-bottom, integrated in, and not seen as an add-on, an after-thought. That is, the overall engineer should build in the security as required from the beginning, so it is a skill that all need, and not something thrown over the wall to the guy with security in his title. It should be, but usually isn't. In fact, the security dude often has to make recommendations out of his prescribed niche, to others. Often on a project which is already under way. E.g., I recently contracted to implement a crypto protocol. When I suggested that, if a pad of paper be provided for folks to write their passphrases down, it be a single glass-backed sheet (lest impressions be taken), much laughter ensued. But if its worth encrypting, it must be interesting, right? Secondly, anything to do with security has a very strong hype-to-value ratio, so much so that it's quite hard to find a security company selling good security stuff. Security is much more than crypto, I've learned, so I don't have a problem with the word. Security includes human and physical security, and although they're not cool comp sci or math, they are vital. Crypto being fairly refined, its not the weakest link any more. And a 'security' mindset (being able to think like the adversary, much like in tic-tac-toe or chess) is important, but not so common. Its not like things titled crypto aren't often marianated in snake oil... :-) Thirdly, good security engineering, as it should be done, doesn't necessarily involve crypto. The art is in using as little crypto as possible - in precise and well placed doses. IMHO. Yes. Applications can't be any more secure than their operating system. -Bram Cohen Oftentimes, however, security engineers start from the pov that crypto is a hammer, and their job is to go find a nail to encrypt. I'll admit to this tunnel vision when I started my interest, over a decade ago when I learned how the IP worked and got into dissecting crypto algorithms to find the magic. Since then I've learned that other things are more important to understand; crypto components are just black boxes to an engineer, like a sorting routine or the like. Cryptoplumber is cute, in a self-depreciating way, but its all engineering, albeit less mature than say civil engineering, which stopped building bridges that collapse some time ago. The ultimate in paranoia is not when everyone is against you but when everything is against you. --PKD = 36 Laurelwood Dr Irvine CA 92620-1299 VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP ICBM: -117.7621, 33.7275 HTTP: http://68.5.216.23:81 (back up, but not 99.999% reliable) PGP PUBLIC KEY: by arrangement Send plain ASCII text not HTML lest ye be misquoted -- Don't 'sir' me, young man, you have no idea who you're dealing with Tommy Lee Jones, MIB No, you're not 'tripping', that is an emu ---Hank R. Hill - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RPOW - Reusable Proofs of Work
At 04:34 PM 8/20/04 -0500, Matt Crawford wrote: I'm wondering how applicable RPOW is. If you think of POW as a possible SPAM mitigation As spam mitigation, it might work better than hashcash. As cash, it lacks the anonymity of bearer-documents (tm) since there is one clearing house. This might be improved via support for a system of mostly independent clearing houses which also interchange at interchange places. However, those would likely be regulated by the Powers That Be, ergo not alleviating my concerns about anonymity. My 2 dinars. = 36 Laurelwood Dr Irvine CA 92620-1299 VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP ICBM: -117.7621, 33.7275 HTTP: http://68.5.216.23:81 (back up, but not 99.999% reliable) PGP PUBLIC KEY: by arrangement Send plain ASCII text not HTML lest ye be misquoted -- Don't 'sir' me, young man, you have no idea who you're dealing with Tommy Lee Jones, MIB No, you're not 'tripping', that is an emu ---Hank R. Hill - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: should you trust CAs? (Re: dual-use digital signature vulnerability)
At 02:09 PM 7/28/04 -0400, Adam Back wrote: The difference is if the CA does not generate private keys, there should be only one certificate per email address, so if two are discovered in the wild the user has a transferable proof that the CA is up-to-no-good. Ie the difference is it is detectable and provable. Who cares? A CA is not legally liable for anything they sign. A govt is not liable for a false ID they issue a protected witness. The emperor has no clothes, just a reputation, unchallenged, ergo vapor. = 36 Laurelwood Dr Irvine CA 92620-1299 VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP VOX: (949) 462-6726 (work -don't leave msgs, I can't pick them up) mnemonic: WIZ GOB MRAM ICBM: -117.7621, 33.7275 HTTP: http://68.5.216.23:81 (back up, but not 99.999% reliable) PGP PUBLIC KEY: by arrangement Send plain ASCII text not HTML lest ye be misquoted -- Don't 'sir' me, young man, you have no idea who you're dealing with Tommy Lee Jones, MIB - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is finding security holes a good idea?
At 08:40 AM 6/16/04 -0700, Eric Rescorla wrote: the search patterns used by blackhats - we are all human and are likely to be drawn to similar bugs. Prof Nancy Levenson once did a study where separate teams coded solutions to the same problem. The different teams' code often erred in the same places (eg corner cases). This was taken as an argument against N-version programming IIRC. It supports the argument that H. saps are succeptible to common cogntive flaws. While this was a code *generation and test* experiment, it does bear on the evaluate for bugs question too. As far as whether finding holes is a good idea, remember that the Pros do not report what they find. No means or methods, remember? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: my periodic rant on quantum crypto
At 03:37 PM 4/12/04 -0400, Perry E. Metzger wrote: QC can only run over a dedicated fiber over a short run, where more normal mechanisms can work fine over any sort of medium -- copper, the PSTN, the internet, etc, and can operate without distance limitation. Nice essay. I especially liked the discussion of authentication. Its also the case AFAIK that the quantum-carrying fiber can only carry one photon at a time. (Perhaps you can multiplex different frequencies, if your demultiplexor doesn't change the quantum properties). Now while there *is* a lot of dark fiber, sending one photon at a time is a pretty good way to keep the construction crews digging up roads :-) Similar quantum-hype is sometimes argued in RNG discussions by those with very narrow views of what an RNG needs and consists of. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Microsoft publicly announces Penny Black PoW postage project
At 09:13 AM 12/26/03 -0800, Steve Schear wrote: http://news.bbc.co.uk/2/hi/technology/3324883.stm Mr Wobber and his group calculated that if there are 80,000 seconds in a day, a computational price of a 10-second levy would mean spammers would only be able to send about 8,000 messages a day, at most. Spammers are sending tens of millions of e-mails, so if they had to do that with all the messages, they would have to invest heavily in machines. Replace invest with trojan and remind Mr. W. that he works for the major facilitator of trojaned machines. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
At 07:11 PM 10/22/03 -0400, Perry E. Metzger wrote: Indeed. Imagine if we waited until airplanes exploded regularly to design them so they would not explode, or if we had designed our first suspension bridges by putting up some randomly selected amount of cabling and seeing if the bridge collapsed. That's not how good engineering works. No. But how quickly we forget how many planes *did* break up, how many bridges *did* fall apart, because engineering sometimes goes into new territory. Even now. You start using new composite materials in planes, and wonder why they fall out of the sky when their tails snap off. Eventually (though not yet) Airbus et al will get a clue how they fail differently from familiar metals. Even learning about now-mundane metal fatigue in planes involved breakups and death. (Safety) engineering *is* (unfortunately, but perhaps by practical necessity) somewhat reactive. It tries very hard not to be, but it is. dh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
At 03:38 PM 10/6/03 -0400, Ian Grigg wrote: I'm asking myself whether anonymous DH is confusingly named. Perhaps it should be called psuedonymous DH because it creates psuedonyms for the life of the session? Or, we need a name that describes the creation of psuedonyms, de novo, from an anonymous starting position? Think of an identity is one endpoint of a communication link. Identities can have varying degrees of persistance and varying degrees of association with meatspace/bank accounts. These are orthogonal dimensions. An endpoint can maintain a reputation (persistant identity) but need not be linked to meatspace entity. A nom-de-plume is a traditional example. By itself, DH exchange only assures that the endpoints remain constant (plus, via the typical symmetric key exchange, also provides confidentiality) for the session. If there is a MITM, the endpoints are not what the distal endpoints (Alice Bob) might think. RSA-certs as administered by Verislime have very little meatspace linkage --you can't sue Verislime if their signed-claims about a meatspace entity are untrue, and the certholder ran off with your money, or if the cert was copied and your DNS cache poisoned. Similarly, publishing a RSA public key and email address does not guarantee anything. And since trust is *not* transitive, the so-called web of trust does little to help, because your personally trusted associates may have been compromised. And of course single meatspace entities may have several RSA keys which others do not know have a common user. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can Eve repeat?
At 08:34 AM 9/24/03 -0400, Greg Troxel wrote: A consequence of the infinite CPU assumption is that ciphers like AES, hash functions like SHA-1, etc. are all considered useless by the purist QC community. Thus, people talk about doing authentication with families of universal hash functions. This has the practical problem that the original (courier-transported) secret keying material for authentication is used up, and the typical scheme talked about is using some of the agreed-upon QKD bits to replenish the authentication keying material. This does not seem very robust. Those couriers are carrying one-time pad CDs, in a QC world. Do not try to pet their dogs, BTW. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Code breakers crack GSM cellphone encryption
At 05:04 PM 9/8/03 -0400, Trei, Peter wrote: Why the heck would a government agency have to break the GSM encryption at all? The encryption is only on the airlink, and all GSM calls travel through the POTS land line system in the clear, where they are subject to warranted wiretaps. Breaking GSM is only of useful if you have no access to the landline portion of the system. You forget that some regimes want to listen to GSM calls in places that they don't control. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Code breakers crack GSM cellphone encryption
At 03:32 PM 9/7/03 -0400, R. A. Hettinga wrote: If the cellphone companies in 197 countries want to correct the code errors that expose them to trickery and abuse, they will have to call in each customer to make a change in the cellphone's programming, or replace all of the cellular phones used by their subscribers. I've read that the lifecycle of a cell phone is about 2 years, FWIW. During a kids-channel TV show, I saw that if you buy 4 dolls you get a prepaid phone free. Took me a while to get over that future-shock. A copy of the research was sent to GSM authorities in order to correct the problem, and the method is being patented so that in future it can be used by the law enforcement agencies. Laughing my ass off. Since when do governments care about patents? How would this help/harm them from exploiting it? Not that high-end LEOs haven't already had this capacity ---Biham et al are only the first *open* researchers to reveal this. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: U.S. seeks OSCE pact on biometric passports
At 04:50 PM 9/2/03 -0400, Duncan Frissell wrote: Anyone have any pointers to non destructive methods of rendering Smart Chips unreadable? Just curious. DCF Perhaps I'm being dense but how could this be non-destructive? Do you mean non-obvious? Or reversible? If the usual microwave games don't apply, perhaps sufficient acceleration or ionic fluids would work. Thermal stress for the liquid nitrogen folks? The flash unit from a $4 disposable camera does a nice job of vaporizing a spot of metal from a coin or screwdriver shorting the cap. Do any europeans have experience leaving smartcards in the laundry? One question would be how to discretely test/verify the new read-not mode :-) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: traffic analysis (was: blackmail / stego)
At 01:01 PM 8/27/03 -0700, Jim McCoy wrote: While IANL, it seems that the whole anonymity game has a flaw that doesn't even require a totalitarian regime. I would direct you to the various laws in the US (to pick a random example :) regarding conspiracy. Subscribing to an anonymity service might not become illegal, but if anyone in your crowd was performing an illegal action you may be guilty of conspiracy to commit this action. Ok, so you have a EULA in which you prohibit offensive behavior. A crowd-member might violate this, but any chaff crowd-member would have a legal defense ---Hey, I used the foobar service to avoid hackers finding my IP, its not my fault if someone threatened the king A real police state would just Tomahawk the servers. After rubber hosing the operators. Anything less than a Total Police State would have to acknowledge innocent subscribers. Kinda like (ca. 1980) yeah, I have a cell phone, its because I am on the road ---I'm not a pharmdealer, even if half the carrier's traffic is dubious. Or, moving into this century, yeah, I use KaZaa++, but its to download unrecognized indie bands, not MetalliMadonna (assuming K++ were anonymous..) Of course, its becoming easier and easier to be a total police state.. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Information-Theoretic Analysis of Information Hiding
At 12:30 AM 7/15/03 -0400, Don Davis wrote: An electrical engineer at Washington University in St. Louis has devised a theory that sets the limits for the amount of data that can be hidden in a system and then provides guidelines for how to store data and decode it. Contrarily, the theory also provides guidelines for how an adversary would disrupt the hidden information. But the theory answers the questions, what is the optimal attack.. There are ways of preventing any modification (attack) of the carrier. E.g., sign the carrier (with the private half of a widely published public key). Although this technique would attract attention until widespread. Note that Disney has to do this as well as Osama, lest someone post Disney content, with the not ok to copy freely watermark mutated. Otherwise a downloader would protest, but the file said it was free, and the included-file-hash said it was intact! (Because the mutator also provided a new hash.) (Disney's situation is worse, of course, because even the pristine, Disney-signed content is copyable at the analog (etc) level. And Osama can use multiple images as carriers for a single message.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: basic question: semantics of map, tie, etc in PKI
At 11:40 AM 7/8/03 -0600, Anne Lynn Wheeler wrote: A hardware token that requires a PIN/password to operate can be considered two-factor authentication (something you have and something you know). I was going to comment on how a simple plastic debit card that includes a photo provides the third something you are. (More reliably than the signature, which is also something you are, but readily forged/ignored.) Then it occurred to me: as cameras become ubiquitous (e.g., in cell phones) some extra security could be obtained by sending a trusted photo of the account holder plus a live picture of the card user. A picture glued into the card could be forged, but a smartcard (with more data area than a magstripe) could include a picture of the account holder, so a thief has no idea what to look like. But the vendor can check the encrypted smartcard face to the face on the phone or webcam. For high-value remote transactions, this might be viable in a few years. This is already standard practice on high-security building-entry cards (and passports?), with the guard comparing the card-embedded face to the one before him. Ubiquitous cameras will bring that to remote transactions, reducing cost due to lower fraud. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Keyservers and Spam
At 03:41 PM 6/13/03 -0700, Bill Frantz wrote: The HighFire project at Cryptorights http://www.cryptorights.org/research/highfire/ is planning on building a web of trust rooted in the NGOs who will be using the system. Each NGO will have a signing key. A NGO will sign the keys of the people working for it. In this manner, we have way of saying, The John Jones who works for Amnesty International. A NGO may decide to sign another NGO's signing key. Now we have a way to say to someone in Amnesty, Send a message to Steve Smith in Médecins Sans Frontières. The plan is to show the trust relationship in the UI as a path of keys. I would appreciate your comments. Threat model: NGO_Alice is compromised and signs GESTAPO key, leading to NGO_Bob's demise. Possible counters: NGO_Alice's NGO key is a split key, so 1 person needs be rubber hosed. I don't know if PGP supports this, I don't think so. Short key expirations, in the limit trusted for just 1 day. Already possible, just document this. Also, how do you counter the GESTAPO from seeing queries to the key servers? It might be enough to jail anyone making such an inquiry. Possible solutions would include having the keyserver perform some innocuous function, and use SSL for all connections to it. Also SSL proxying and stego of course. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: An attack on paypal
At 03:38 PM 6/11/03 -0600, Anne Lynn Wheeler wrote: even before e-commerce, the real BBB process was that people called up the BBB and got realtime information i.e. it was an online, realtime process. the equiivalent for an online, internet paradigm (as opposed to something left over from the offline email genre of at least 10--15 years earlier) was that the browswer tab;e pf trusted entities were of online authorities (as opposed to certificate manufacturing) and if you cared, you clicked thru to the BBB and got realtime information about the merchant in question (being equivalent to when people call the BBB to actually get some level of real input as opposed to just a fuzzy comfort fealing). When I buy $20 of gas with non-bearer credentials (ie, credit card), the vendor does a real-time check on me. Seems fair/useful to be able to do same on them. I suppose eBay's feedback suffices... if their last N feedbacks are negative, I might go elsewhere. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Keyservers and Spam
At 05:47 PM 6/11/03 -0700, Bill Frantz wrote: To try to reflect some of David's points with a real-world situation. I was at work, with a brand new installation of PGP. I wanted to send some confidential data home so I could work with it. However I didn't have my home key at work, so I didn't have a secure way to send either the data, or the work key. I didn't even have the fingerprint of the home key. My solution was to pull Carl Ellison's business card out of my pocket. It had his key fingerprint on it, and I remember getting it directly from him, so I could trust the fingerprint. Now Carl had signed my key, so when I downloaded it from the key server, I could verify that it was indeed mine (to the extent I trusted Carl). Carl's signature, and the key server allowed me to bootstrap trust into my own key. But with a key server, I didn't have to bother Carl to send me my key. Or depend on him being online when I needed it. True, although: 1. you could have had your own key-fingerprint on your own bizcard and done the same. 2. you needn't have had your valid email address there (going back to the spam-thread), perhaps just your regular name. In fact you could have your key on your home server, not in a public server which serves as spambait. Your home server could be unlisted by using an alternate port. (I do this to get around ISP blocking, but then I'm not trying to publish papers on my home server.) Or use CGI, or a password mechanism, to deter spam-spiders. The point with spam and publishing your email address is that its like having a public physical storefront: anyone can pay the price of a cigarette to a stream of homeless people to clog your physical store. Or form a huge line if you have bouncers at the door. That's what having a public interface means. 3. I think you also trusted that Carl has not been compromised and re-signed a bogus key *after* he first signed it. (Not picking on Carl here :-) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Keyservers and Spam
At 12:43 PM 6/10/03 -0400, Jeffrey Kay wrote: number (which I now use Call Intercept to avoid telephone solicitors). But for privacy reasons, some folks will not automatically forward their phone number. You either deny them access or require them to jump through extra hoops (redial w/ special control codes that send their ID). Analogy w/ email PGP left as an exercise.. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
