Re: Can we copy trust?
Bill Frantz wrote: really used for strangers. For people we know, recognition and memory are more compelling ways of trusting. We can use this recognition and memory in the online world as well. SSH automatically recognizes previously used hosts. Programs such as the Pet Names Toolhttp://www.waterken.com/user/PetnameTool/ recognize public keys used by web sites, and provide us with a human-recognizable name so we can remember our previous interactions with that web site. Once we can securely recognize a site, we can form our own trust decisions, without the necessity of involving third parties. that was one of the business case problems early in SSL for electronic commerce ... namely majority of ecommerce was with repeat sites ... while design point of digital certificates is for first time communication between strangers. the other factor that bounded what merchants would pay was liability in electronic commerce ... there were already paying significant interchange fees as part of protecting the consumer. certification authorities weren't looking at taking on any of that aspect. the combination has been pushing digital certificates into the no-value market segment ... which, in turn, further limits what would could be charged for. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
Ed Gerck wrote: Ben Laurie wrote: But doesn't that prove the point? The trust that you consequently place in the web server because of the certificate _cannot_ be copied to another webserver. That other webserver has to go out and buy its own copy, with its own domain name it it. A copy is something identical. So, in fact you can copy that server cert to another server that has the same domain (load balancing), and it will work. Web admins do it all the time. The user will not notice any difference in how the SSL will work. Obviously. Clearly I am talking about a server in a different domain. -- http://www.apache-ssl.org/ben.html http://www.links.org/ 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fwd: Protection mail at rest
I agree with you, that this is not nearly fast enough. However, this is 10 times faster then our original results, where we were searching 100 emails in about the same amount of time. With production code, some more optimization, esp. client side optimizations (i.e. message caching when possible), and increased parallelism, it may just be possible to reach the 4x faster searches a heavy user like yourself would need. I am just not a good enough coder to write it myself, but I believe that it can be done. adam On Mon, Jun 2, 2008 at 10:42 PM, Greg Black [EMAIL PROTECTED] wrote: On 2008-06-02, Adam Aviv wrote: I recently implemented SSARES directly in python and also added parallelism to the searching. We can now search the a large inbox (1000+) messages in about 2-4 minutes. Not to rain on your parade, but 1,000 messages is *not* a large inbox and 2 to 4 minutes is a very long time to wait. You'd need to make this two orders of magnitude faster before it would have a hope of being interesting. (And for me, it would have to be at least four orders of magnitude faster before I could consider it to be useful.) Greg -- Adam Aviv Ph. D. Candidate Computer and Information Science University of Pennsylvania - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
[Moderator's note: Please do not top post. --Perry] I am thinking that trust is a relationship. A trusts B. So if you start with A trusts B and you do some operation that results in C trusts B then you have not copied anything because A trusts B is not equal to C trusts B. You can't call that operation a copy. I can't think of any scenario where it even makes sense to talk about copying trust. The closest thing I can think of would be a document, or record in a database, or a certificate, or similar thing that reminds me that I trust X. That is consistent with Bill Frantz's comment on memory. (hi Bill) I can copy the reminder, but that doesn't copy the trust. The trust exists, it seems to me, with or without the reminder (even if I have temporarily forgotten about it). Kind regards, -Bill On Jun 2, 2008, at 6:24 PM, Ed Gerck wrote: Bill Frantz wrote: [EMAIL PROTECTED] (Ed Gerck) on Monday, June 2, 2008 wrote: To trust something, you need to receive information from sources OTHER than the source you want to trust, and from as many other sources as necessary according to the extent of the trust you want. With more trust extent, you are more likely to need more independent sources of verification. In my real-world experience, this way of gaining trust is only really used for strangers. For people we know, recognition and memory are more compelling ways of trusting. Recognition = a channel of information memory = a channel of information When you look at trust in various contexts, you will still find the need to receive information from sources OTHER than the source you want to trust. You may use these channels under different names, such as memory which is a special type of output that serves as input at a later point in time. The distinguishing aspect between information and trust is this: trust is that which is essential to a communication channel but cannot be transferred from a source to a destination using that channel. In other words, self-assertions cannot transfer trust. Trust me is, actually, a good indication not to trust. We can use this recognition and memory in the online world as well. SSH automatically recognizes previously used hosts. Programs such as the Pet Names Tool http://www.waterken.com/user/PetnameTool/ recognize public keys used by web sites, and provide us with a human-recognizable name so we can remember our previous interactions with that web site. Once we can securely recognize a site, we can form our own trust decisions, without the necessity of involving third parties. Yes, where recognition is the OTHER channel that tells you that the value (given in the original channel) is correct. Just the value by itself is not useful for communicating trust -- you also need something else (eg, a digital sig) to provide the OTHER channel of information. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
Bill Soley wrote: I am thinking that trust is a relationship. A trusts B. So if you start with A trusts B and you do some operation that results in C trusts B then you have not copied anything because A trusts B is not equal to C trusts B. You can't call that operation a copy. Trust is indeed expressed by relationships. And those relationships can be transmitted with proper consideration -- just not in your example. In the case of SSL certs, a simple file copy is enough. Cheers, Ed Gerck Addendum: Did you have a chance yet to read Kelly's paper? In that paper, he is looking for stuff that can't be copied -- because he hopes that such stuff is scarce and valuable. When copies are free, you need to sell things which can not be copied. Kelly says that we can't copy trust. So, if I have 100 servers for the domain example.com does this mean that I have to buy 100 trusted SSL certs from the CA? Or, is any copy of the SSL cert as trustworthy as the original? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
Ed Gerck wrote: Bill Frantz wrote: [EMAIL PROTECTED] (Ed Gerck) on Monday, June 2, 2008 wrote: To trust something, you need to receive information from sources OTHER than the source you want to trust, and from as many other sources as necessary according to the extent of the trust you want. With more trust extent, you are more likely to need more independent sources of verification. In my real-world experience, this way of gaining trust is only really used for strangers. For people we know, recognition and memory are more compelling ways of trusting. Recognition = a channel of information memory = a channel of information When you look at trust in various contexts, you will still find the need to receive information from sources OTHER than the source you want to trust. You may use these channels under different names, such as memory which is a special type of output that serves as input at a later point in time. It is useful and efficient to get trust from third parties, but not essential, imho. If you find yourself meeting someone for the first time in random circumstances, you can get to know them over time, and trust them, fully 2nd party-wise. Trust comes from events of risk and reward, not from channels. It just so happens that the best expressions of risk and reward are over independent therefore 3rd party channels. The distinguishing aspect between information and trust is this: trust is that which is essential to a communication channel but cannot be transferred from a source to a destination using that channel. Trust is an expression of something you may rely on. It has risks, liabilities, obligations, etc. Information does not (yet). In other words, self-assertions cannot transfer trust. Trust me is, actually, a good indication not to trust. Well. Actions speak louder than words. The *act* of a third party is to put their own reputation at risk if they say trust this 2nd person. This works if the two people are independent, but not if the two people are dependent (or the same). If they are independent, the costs incur to one party and the benefits incur to another party. So the independent cost of placing the reputation at risk is a significant event. You can rely on someone who will incur cost on your behalf. Saying trust me carries no risks because the benefits cancel out the risks. We can use this recognition and memory in the online world as well. SSH automatically recognizes previously used hosts. Programs such as the Pet Names Tool http://www.waterken.com/user/PetnameTool/ recognize public keys used by web sites, and provide us with a human-recognizable name so we can remember our previous interactions with that web site. Once we can securely recognize a site, we can form our own trust decisions, without the necessity of involving third parties. Yes, where recognition is the OTHER channel that tells you that the value (given in the original channel) is correct. Just the value by itself is not useful for communicating trust -- you also need something else (eg, a digital sig) to provide the OTHER channel of information. Attempting to cast trust as a aspect of channels is a technological approach, and will lead one astray, just as PKI did; trust is built on acts, of humans, and involves parties and events, risks and rewards. The channels are incidental. You can see this better in the study of negotiation. It is possible using this theorypractice to build trust, or to prove that no trust can be achieved. Negotiation is primarily a paradigm of two parties. (Economists will recognise it as game theory, prisoner's dilemma, perhaps agent-principal theory, etc.) Your comment that someone who says trust me is in fact signalling that they cannot be trusted ... is more clearly explained in negotiation. Often, someone will state up front that they want to find the win-win; which is a signal that they are in the win-lose, because real win-win is about actions not words, and words in this case would lead to a false sense of security. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
On Mon, Jun 2, 2008 at 12:37 PM, Ed Gerck [EMAIL PROTECTED] wrote: In the essay Better Than Free, Kevin Kelly debates which concepts hold value online, and how to monetize those values. See www.kk.org/thetechnium/archives/2008/01/better_than_fre.php Kelly's point can be very useful: *When copies are free, you need to sell things which can not be copied.* The problem that I see and present to this list is when he discusses qualities that can't be copied and considers trust as something that cannot be copied. Kelly says trust cannot be copied at the top of his missive then doesn't list it as one of the eight generatives (I may be missing something but I think generative is the wrong word for something that cannot be copied but Kelly makes up his own definition for generative as something generated uniquely in place). Well, in the digital economy we had to learn how to copy trust and we did. For example, SSL would not work if trust could not be copied. After this list has destroyed the as implemented SSL model of trust over and over again, I'd be wary of claiming that SSL allows trust to be copied. Even so, SSL doesn't really copy trust, it works by only trusting the root. You don't have to trust the target site's self assertions about its own identity because you trust the root to only validate for sites that are what they claim to be. On Mon, Jun 2, 2008 at 3:29 PM, Ed Gerck [EMAIL PROTECTED] wrote: A copy is something identical. So, in fact you can copy that server cert to another server that has the same domain (load balancing), and it will work. Web admins do it all the time. The user will not notice any difference in how the SSL will work. Copying server certificates isn't copying trust either. In this case all servers with the same certificate are the same entity - at least to whatever needs to trust it. This whole thing with SSL and certificates is a red herring when it comes to copying trust. When I trust a site, that site doesn't have the trust, I do. To copy that trust, albeit with low fidelity, I merely have to communicate that trust to some other person. There are sites on the net that allow me to communicate my trust to others. eBay is probably making the most money at it with their seller reputation system. Sellers with a better reputation will attract more business and sell quicker and at higher prices. eBay makes more money when more product moves at higher prices but it cannot inflate seller's reputations because that would instantly be recognized by buyers and eBay would become a pariah and some other site would take over. Other sites like Amazon, Bizrate, and Angie's List provide similar trust distribution services with different underlying business models. This is a trust model that appears to work. If a eBayish/Verisigny company did an OCSP-like service that returned a current eBay-like reputation number for the trustworthiness of the site in question, I don't think we would need band aids like PetNames or even a hierarchical PKI. Sites could just use self-signed certificates with a field pointing to their reputation responder. Instead of trusted root certificates, browsers could have trusted reputation responder certificates. Microsoft would charge reputation responders to include their certificates, reputation responders would charge companies to maintain their reputations, everybody would make money. When a reputation responder goes bad, slashdot would have fun, Microsoft would pull their cert, there will be some vulnerable users that don't ever get updated responder certificate lists, and the entities that had trust housed at the bad responder will have to generate new certs and rebuild their reputation elsewhere. This, of course, doesn't have a chance of occuring because SSL works good enough and people will ignore the bad reputation warnings just like they ignore SSL warnings now. -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The perils of security tools
Hi, It is not an implementaion issue but a requirement of the C standard. To avoid buffering use setvbuf (fp, NULL, _IONBF, 0); right after the fopen. Ah! Thanks a lot! Ok, I think that should be written into the man-pages of /dev/random and fgetc/fread and other related howtos. Best regards, Philipp Gühring - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fwd: Protection mail at rest
On 2008-06-02, Adam Aviv wrote: I recently implemented SSARES directly in python and also added parallelism to the searching. We can now search the a large inbox (1000+) messages in about 2-4 minutes. Not to rain on your parade, but 1,000 messages is *not* a large inbox and 2 to 4 minutes is a very long time to wait. You'd need to make this two orders of magnitude faster before it would have a hope of being interesting. (And for me, it would have to be at least four orders of magnitude faster before I could consider it to be useful.) Greg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fwd: Protection mail at rest
Greg Black wrote: On 2008-06-02, Adam Aviv wrote: I recently implemented SSARES directly in python and also added parallelism to the searching. We can now search the a large inbox (1000+) messages in about 2-4 minutes. Not to rain on your parade, but 1,000 messages is *not* a large inbox and 2 to 4 minutes is a very long time to wait. You'd need to make this two orders of magnitude faster before it would have a hope of being interesting. (And for me, it would have to be at least four orders of magnitude faster before I could consider it to be useful.) Thunderbird, at least, downloads imap mail locally for searching. So all I need is the automatic public key encryption on the server side (no searching). Is there such an application already? -- Nate - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fwd: Protection mail at rest
[Moderator's note: Please don't top post. --Perry] Depending on the level of protection you want, you could just add a script to your .forward to encrypt your email before delivery using PGP/GPG. However, this will leave the headers in the clear, so you will likely want to create an entirely new envelope for the message with the original message encrypted as the body or an attachment. But then you will need a thunderbird extension to unwrap the encrypted original email out of the body, and store the message locally unencrypted so that you can search. The problem comes when you start accessing your email from multiple locations. At one place you have built up a large cache of unencrypted messages and you can use them in the normal way, but when you access from another machine or a blackberry, the lack of cache will greatly hinder your performance. This is the reason we wanted to not only have the client cache capability to searching, but also a server side mechanism to compensate when accessing from multiple locations. adam On Tue, Jun 3, 2008 at 11:34 AM, Nate Lawson [EMAIL PROTECTED] wrote: Greg Black wrote: On 2008-06-02, Adam Aviv wrote: I recently implemented SSARES directly in python and also added parallelism to the searching. We can now search the a large inbox (1000+) messages in about 2-4 minutes. Not to rain on your parade, but 1,000 messages is *not* a large inbox and 2 to 4 minutes is a very long time to wait. You'd need to make this two orders of magnitude faster before it would have a hope of being interesting. (And for me, it would have to be at least four orders of magnitude faster before I could consider it to be useful.) Thunderbird, at least, downloads imap mail locally for searching. So all I need is the automatic public key encryption on the server side (no searching). Is there such an application already? -- Nate -- Adam Aviv Ph. D. Candidate Computer and Information Science University of Pennsylvania - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
Ben Laurie wrote: Obviously. Clearly I am talking about a server in a different domain. And we (Kelly and I) were talking about copying trust, where a copy is (as usual) a reproduction, a replication of an original. If you are copying trust from a domain, as represented by a SSL cert signed by a trusted CA, it should be a reproduction of /that/ trust -- not trust on a different domain. If you want to copy trust to a different domain, then we need to transfer the trust. This is also /possible/, as you know, as long as the issuing CA has set the CA bit in the SSL certificate. Object Signing CA certs must have the Object Signing CA bit set. In summary, in SSL you can both copy and transfer trust. Without further evidence, which can be provided in pvt if desired by anyone, (1) SSL is not such only example in the Internet; and (2) we can likewise copy and transfer trust in our social interactions, not just in our digital interactions. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
IanG wrote: Ed Gerck wrote: When you look at trust in various contexts, you will still find the need to receive information from sources OTHER than the source you want to trust. You may use these channels under different names, such as memory which is a special type of output that serves as input at a later point in time. It is useful and efficient to get trust from third parties, but not essential, imho. If you find yourself meeting someone for the first time in random circumstances, you can get to know them over time, and trust them, fully 2nd party-wise. Yes, and the OTHER channels needed for trust are exactly those time-defined channels that you set up as you get to know them over time. Each interaction, each phrase, each email exchanged is another channel. Still, you can be talking to Doris in a p2p interaction over months and never realize it's actually Boris. This can happen in personal meetings as well, not just online. The point being that (1) you need those other channels and can recognize them even if you are just in a p2p interaction; and (2) be careful because whatever channels you have, they will only span a certain, limited extent in the interaction that you want to trust, so your reliance space must be contained within that extent. Attempting to cast trust as a aspect of channels is a technological approach, and will lead one astray, just as PKI did; trust is built on acts, of humans, and involves parties and events, risks and rewards. The channels are incidental. Shannon's information theory is a general approach that, even though it has limitations as any other model, has allowed researchers to deal with both social and technical aspects of trust. The important point, contrary to what PKI did, is to base the technical definition of trust on the social mediation of trust that we have learned over thousands of years. Thus, when we look at linguistics and other areas where we find expressions of social experience and communication in a culture, we see that the unique, defining aspect of trust is that trust on something or someone needs /OTHER/ channels of information (where memory is also a channel) than the information channel we want to trust. This social-linguistic observation transfers directly to the definition we can use with information theory for the technical aspect of trust, allowing the /same/ model of trust to be used in both worlds, as: trust is that which is essential to a communication channel but cannot be transferred from a source to a destination using that channel. From this abstract definition, you can instantiate a definition that applies to any desired context that you want -- social and/or technical -- while assuring that they all have the same model of trust. Examples are provided at the top of http://mcwg.org/mcg-mirror/trustdef.htm As usual, information is defined as: information is that which is transferred from a source to a destination. If the same information is already present at the destination, there is no transfer. That's why information is surprise; there's no surprise if the information already exists at the destination. You can see this better in the study of negotiation. It is possible using this theorypractice to build trust, or to prove that no trust can be achieved. Negotiation is primarily a paradigm of two parties. You can use different models. I believe that trust is a more fundamental model than negotiation, as we can have trust without negotiation. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
[EMAIL PROTECTED] wrote: You don't have to trust the target site's self assertions about its own identity because you trust the root to only validate for sites that are what they claim to be. From the viewpoint of the user (which is the viewpoint used by Kelly), we see that trust can be copied when different users, accessing different servers for the same domain, do not know that they are using different copies of the /same/ SSL cert. In fact, no copy is less of an original than the original itself! We see that the trust relationship represented by that SSL cert can be copied without any loss, as many times as you wish (for the possible dismay of the CA). If the CA bit is set, trust can even be transferred to multiple domains, and the trust represented by each such SSL cert in each domain can be copied without limit as well. As to another point of your comment, the problem most people have with PKI is not that SSL does not work. SSL does not even need PKI. The problem can be explained in terms of extent of trust. If you don't define your extent of trust in a CA, for example in your acceptance policy of records signed by certs from a CA, you may run into difficulties. The difficulties are /solved/ (within your risk model) when you correctly define the extent of trust -- rather than just taking a trust in all matters attitude. For example, even though I do not trust a CA's CRLs, I may trust that CA to prevent rogue use of its private-key for signing end-user certs. This trust, limited by this extent, can be used in automating use of certs from that CA -- for example, only accept signatures from end-user certs of that CA if the cert is less than 31 days old (or, 15 days -- whatever your risk model says). Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
$20 bounty for errors in _Disappearing Cryptography_
I'm working on the third edition of _Disappearing Cryptography_ right now. If anyone knows of any technical errors in the second edition, I'm willing to pay $20 for the first person to report each technical error. The bounty can't apply to grammatical errors because of the complexity of the language. I reserve the right to (1) decide on whether something is a legitimate technical error and (2) give out more than one award if several people send in the same bug report and seem to be genuinely independent. The limit is just meant to stop people from minting money. Thanks, -Peter Wayner [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
On Tue, Jun 3, 2008 at 1:05 PM, Ed Gerck [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: We see that the trust relationship represented by that SSL cert can be copied without any loss, as many times as you wish My understanding is that an SSL certificate is only a method to carry the assertion that the holder of the private key is the the subject named in the certificate (with possible limitations on the allowed uses of the private key). By using the certificate, one does not trust the subject - one does trust the signer of the certificate as an entity that verified the subject named in the certificate represents the actual subject (this is true even for self signed certificates grin/). Copying the SSL certificate does not copy trust but sometimes copying some certificates do copy trust. Say Alice browses around the web looking to buy a widget and when her browser hits a particular HTTPS protected site, it pops up an untrusted certificate warning. Alice goes and moves on to another site. Bob goes to the same site and his browser doesn't pop up the warning because Microsoft has automatically updated his computer's trusted CAs list. Bob's browser trusts the site and Bob trusts his browser so Bob buys the widget. Alice's browser didn't trust the site, and Alice, being a remarkable woman, actually paid attention to her browser and moved on. So we see, the trusted CA certificates do carry trust (heck, trusted is part of the name), and, when Microsoft copied the new trusted CA certificate into Bob's computer, Microsoft managed to copy trust. IT departments put corporate trusted CA certificates in employees computers. The US DoD puts their trusted root certificates in DoD computers. All these actions copy trust with high fidelity. But this method rings of an edict from on high, Thou shalt trust These methods still don't have the: // copy Alice's trust in Charlie to Bob Copy(Alice[trust--Charlie], Bob) capability. The low fidelity ways of Epinions and eBay seem to be the only examples I can come up with that allow for that type of trust copying. For example: // copy the trust in Charlie a large group of eBayers has to Bob MaybeCopy(eBayClaim.LargeGroup[trust--Charlie], Bob) The copy may or may not happen depending on Bob's feelings about the size of the group or the extent of the trust. Of course, the eBayesque trust copying happen in wetware. To move it to hardware would require an online protocol and method to register trust. I can see shades of the old PGP web-of-trust with added subtleties for timeliness and dispute resolution. As to another point of your comment, the problem most people have with PKI is not that SSL does not work. SSL does not even need PKI. I meant SSL as we use it - I believe the vast majority of SSL use involves a hierarchical PKI. I have rarely seen the use of pre-shared keys or self-signed certificates (which is technically still a PKI). -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
ADMIN: end of Can we copy trust discussion
I don't think anything new is being said in the Can we copy trust discussion, so I'm calling a halt to it. Perry -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
fyi: Traitor Tracing for Anonymous Attack in AACS Content Protection
From:Adam Barth [EMAIL PROTECTED] Subject: TOMORROW 3 Jun - Hongxia Jin - Traitor Tracing for Anonymous Attack in AACS Content Protection To: [EMAIL PROTECTED] Date:Mon, 02 Jun 2008 18:48:48 -0700 Title: Traitor Tracing for Anonymous Attack in AACS Content Protection Speaker: Hongxia Jin, IBM Almaden Abstract: Broadcast encryption and traitor tracing are two active problems in cryptography community. In this talk I will give an overview on how broadcast encryption and traitor tracing can be used for content protection. My focus of the talk is on tracing traitors for anonymous attack. It is a way to trace the source of unauthorized copies of the content or content encrypting keys when the system is broadcasted. I will give the talk in the context of AACS, the new industry content protection standards for next generation high definition DVDs, It is the first large-scale commercial deployment of a traitor tracing technology. Along the way we have had to solve both practical and theoretical problems that had not been apparent in the literature to date. In this talk I will focus on addressing some of those problems in our process of bringing a theoretical solution to practice. 3 Jun (Tuesday) at 1630 hrs Gates 4B (opposite 490) Stanford Security Seminar on Google Calendar: http://www.google.com/calendar/embed?src=98e49qo62mapd82qi9468tahls%40group.cal endar.google.com - --++**==--++**==--++**==--++**==--++**==--++**==--++**== security-seminar mailing list [EMAIL PROTECTED] https://mailman.stanford.edu/mailman/listinfo/security-seminar -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
ADMIN: What is top posting, and why should you avoid it?
A3: Please. Q3: Should I avoid top posting on this mailing list? A2: Because, by reversing the order of a conversation, it leaves the reader without much context, and makes them read a message in an unnatural order. Q2: Why is top posting irritating? A1: It is the practice of putting your reply to a message before the quoted message, instead of after the (trimmed) message. Q1: What is top posting? Perry -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Protection mail at rest
On Jun 3, 2008, at 11:51 AM, Adam Aviv wrote: Depending on the level of protection you want, you could just add a script to your .forward to encrypt your email before delivery using PGP/GPG. However, this will leave the headers in the clear, so you will likely want to create an entirely new envelope for the message with the original message encrypted as the body or an attachment. Does anybody have a recipe for this first mode handy? plain text e- mails seem simple enough, but there needs to be a bit of MIME unwrapping and rewrapping to correctly handle attachments so that the client sees/decrypts them correctly I think. I've searched from time to time and never found a good HowTo... Thanks, Eric PGP.sig Description: This is a digitally signed message part
Re: Can we copy trust?
Ben Laurie wrote: Ed Gerck wrote: Ben Laurie wrote: But doesn't that prove the point? The trust that you consequently place in the web server because of the certificate _cannot_ be copied to another webserver. That other webserver has to go out and buy its own copy, with its own domain name it it. A copy is something identical. So, in fact you can copy that server cert to another server that has the same domain (load balancing), and it will work. Web admins do it all the time. The user will not notice any difference in how the SSL will work. Obviously. Clearly I am talking about a server in a different domain. Up until recently, you could buy a cert for one domain, use *it* to issue a cert for another domain, and the major web browsers wouldn't kick at the traces provided you sent both certs in the ssl handshake. Thankfully, they fixed that before *too* many phishers figured it out. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]