Re: Is cryptography where security took the wrong branch?
At 03:39 AM 9/10/2003 -0700, [EMAIL PROTECTED] wrote: There are some other problems w/ using the DNS. No revolkation process. DNS caching third-party trust (DNS admins != delegation holder) Since DNS is a online positive list you change the database ... and voila it is updated. This is the scenario for credit cards going from pre-70s technology with plastic cards and the monthly revokation booklet mailed out to all merchants. The credit card industry transitioned to online infrastructure where it transactions are denied by updating the online database. It eliminates the revokation process, since there aren't an unknown number of copies of static, stale credentials/certificates floating around the world potentially being presented to an unknown variety of relying parties. DNS caching is the closest equivalent of the certificate paradigm of static, stale copies floating around the world. The two slight differences are that cached stale, static entries tend to have very short lifetimes ... they come into creation by activities by the relying-party (not the entity being authenticated) and tend to have very short lifetimes of a few hours to at most a day. However, relying-parties have the choice of going directly to the root and obtaining the current copy a function somewhat filled in the PKI world by OCSP although OCSP is just a check about whether the current, static, stale copy in a relying-party's possession is current ... not what the current entry is.. From information theory standpoint, stale, static certificates are logically a form of long-lived, distributed, replicated, r/o, cache entries. Cache entry semantics have been studied in some detail in areas like distributed file systems and multiprocessor consistent shared memory caches, etc. With short-lived r/o, distributed cache entires (like DNS) ... there is a trade-off involving 1) entry life-time, 2) frequency of change, 3) impact of dealing with stale entry. We ran into a problem with doing consistent database updates over NFS (network filesystem) because while NFS advertises itself as item potent, most client implementations have this 8k cache that can be stale. Given high value /or low trust ... relying parties still have option of directly contacting root authority. And as outline, the root authority is also the root authority for the CA/PKIs. If you attack the root trust authority with false information then all subsequent trust operations flowing from that false information is suspect. Domain name system still has some exploits against the root database resulting in false information but since that is the root for both DNS as well as CA/PKIs generating SSL domain name certificates it is a common failure point for both infrastructures. It needs to be fixed, in order to improve trust on either the DNS side or the CA/PKI side (doesn't matter how thick you make the vault door if somebody forgot to complete the back wall on the vault). random, unrelated refs to past life working on processor cache design, distributed filesystems, and distributed databases http://www.garlic.com/~lynn/subtopic.html#smp http://www.garlic.com/~lynn/subtopic.html#hacmp -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Bear: An Open-Source Virtual Secure Coprocessor based on TCPA
http://www.cs.dartmouth.edu/~sws/abstracts/msmw03.shtml Papers www.cs.dartmouth.edu/~sws/abstracts/msmw03.shtml Last modified: 08/27/03 11:56:52 AM Rich MacDonald, Sean W. Smith, John Marchesini, Omen Wild. Bear: An Open-Source Virtual Secure Coprocessor based on TCPA Technical Report TR2003-471, Department of Computer Science, Dartmouth College. August 2003. Abstract This paper reports on our ongoing project to use TCPA to transform a desktop Linux machine into a virtual secure coprocessor: more powerful but less secure than higher-end devices. We use TCPA hardware and modified boot loaders to protect fairly static components, such as a trusted kernel; we use an enforcer module---configured as Linux Security Module---to protected more dynamic system components; we use an encrypted loopback filesystem to protect highly dynamic components. All our code is open source and available under GPL from http://enforcer.sourceforge.net/ Download PDF Code Back to home page Maintained by Sean Smith ,[EMAIL PROTECTED] -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Code breakers crack GSM cellphone encryption
On Mon, 8 Sep 2003, Dave Emery wrote: Just to amplify this a bit, does anyone seriously think the NSA's satellite and embassy based cellphone interception capability is primarily targeted against - US - GSM calls ? Or that they can routinely get warrants to listen in using the wired tapping infrastructure in say Russia or France or Iran ? Of course the NSA's satellite and embassy based cellphone interception capability isn't primarily targeted against - US - calls; that would be illegal. The snooping in the US is done by others and then handed over to the NSA instead. And of course the NSA does the same for them. This is what the UKUSA agreement is all about. Bluntly, no matter who does the actual interception work, in the modern world every intel agency's analytic and correlative resources are targeted against everybody in the world. To say that some particular agency doesn't do intercepts in some particular country is irrelevant; It's all just data. Remember lawmakers learning that the internet treats censorship as damage and routes around it? Well, we're looking at the same phenomenon here: the worldwide intel community treats privacy laws and operational restrictions as damage and routes around them. It's exactly the same thing. I'd be willing to bet most nations even get intel on their own citizens that's gathered by actively hostile countries: An actively hostile nation, let's say, snoops on american citizens. Then they share the intel product with someone they've got a treaty with, and then that country shares it with somebody they've got a treaty with, and they share it with the US. It's all just routing. Someone has information somebody else wants, somebody else has money or intel to swap for it. It doesn't take a genius to figure out, it's just going to happen. Anything an intel service shares with anybody, it's putting into the network, and it's going to get around to everybody. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 03:39 AM 9/10/2003 -0700, [EMAIL PROTECTED] wrote: There are some other problems w/ using the DNS. No revolkation process. DNS caching third-party trust (DNS admins != delegation holder) Given high value /or low trust ... relying parties still have option of directly contacting root authority. And as outline, the root authority is also the root authority for the CA/PKIs. If you attack the root trust authority with false information then all subsequent trust operations flowing from that false information is suspect. Domain name system still has some exploits against the root database resulting in false information but since that is the root for both DNS as well as CA/PKIs generating SSL domain name certificates it is a common failure point for both infrastructures. It needs to be fixed, in order to improve trust on either the DNS side or the CA/PKI side (doesn't matter how thick you make the vault door if somebody forgot to complete the back wall on the vault). ok... does anyone else want to touch a secured DNS system that has some parts fo the tree fully signed? Its a way to get some emperical understanding of how interesting/hard it is to hammer the DNS into a PKI-like thing. www.rs.net has some information. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[Isig] Re: Boston Linux Meeting Wednesday, September 17, 2003 PGP/GnuPG Keysigning Party
--- begin forwarded text Status: U From: Jerry Feldman [EMAIL PROTECTED] To: BLU [EMAIL PROTECTED], CONE [EMAIL PROTECTED], GNHLUG [EMAIL PROTECTED], ISIG [EMAIL PROTECTED], New England Information Security User Group [EMAIL PROTECTED] Organization: Boston Linux and Unix Subject: [Isig] Re: Boston Linux Meeting Wednesday, September 17, 2003 PGP/GnuPG Keysigning Party Sender: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: http://www.blu.org/mailman/listinfo/isig03, mailto:[EMAIL PROTECTED] List-Id: Boston Internet Special Interest Group(ISIG) isig03.blu.org List-Archive: http://www.blu.org/pipermail/isig03/ Date: Wed, 10 Sep 2003 14:59:24 -0400 When: Wednesday, September 17, 2003 7:00 PM (6:30 for general QA) Topic: PGP/GnuPG Keysigning Party IV Location: MIT Building 4-370 Presented by: BLU Volunteers The purpose of the meeting is to authenticate each other, i.e. verify everybody's key ids and key fingerprints. Participants sign each others' keys offline. It is essential that, before the meeting, you register on the signup form listed in the attachments. You should bring at least one picture ID with you. You must also bring your own printout of the report on that page, so you can check off the names/keys of the people you have personally verified. Please refer to the web site below for further details and to sign up http://www.blu.org/cgi-bin/calendar/2003-sep Register at this URL http://www.blu.org/meetings/2003/09/keypartyregister.php PLEASE remember to register and print out your report BEFORE the meeting. We will not have copies for everyone. -- Jerry Feldman [EMAIL PROTECTED] Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ Isig03 mailing list [EMAIL PROTECTED] http://www.blu.org/mailman/listinfo/isig03 --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Anyone Remember Zero Knowledge Systems?
On Wed, Sep 10, 2003 at 11:32:29AM -0400, R. A. Hettinga wrote: | http://www.cryptonomicon.net/modules.php?name=Newsfile=printsid=455 | | Cryptonomicon.Net - | | Anyone Remember Zero Knowledge Systems? | Date: Wednesday, September 10 @ 11:15:00 EDT | Topic: Commercial Operations / Services | Unfortunately, they never quite made a compelling enough argument | for mass adoption of their system and eventually morphed the company | into a manufacturer or more conventional privacy tools. Freedom still | exists as a product, thought it is aimed at web users, only runs on | Windows clients, and routes requests through proxy servers owned by | Zero Knowledge Systems. Freedom Websecure is a different protocol set from Freedom.net. Websecure runs on linux, see http://websecure4linux.sourceforge.net/ The Freedom.net code is available for non-commercial use, see http://slashdot.org/articles/02/02/16/0320238.shtml?tid=158 or the shmoo group cvs server, http://cvs.shmoo.com/view/projects/freedom-server/ The problem with running Napster over Freedom was bandwidth costs. Users may be more willing to pay today, given the clear risk of paying $10,000 or more in fines. I'm sure that ZKS would be happy to sell someone a commercial use license. Adam -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
