Fwd: [gsc] Digital cache with extended features
[Some interesting thinking going on. Wasn't there some similar ideas presented/published at a past FC conference?] Subject: [gsc] Digital cache with extended features Date: Sun, 06 May 2007 12:57:08 +0300 From: George Hara [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] It seems that, finally, the pieces fit together, and although the design is not as good as for account based systems, it's good enough. I have been pondering for some time about digital cash, but the pieces never fit. However, with a special design, it's possible to integrate the necessary features in digital coins. Basically, it's necessary for the owner of a coin to create the coin (core), blind it and send it to the mint for signing. In the core, the user must include a hash for a coin appendix. The coin appendix includes various information, but the most important is the asymmetric public key pair of the recipient. The coin appendix is not sent to the mint so that it would not serve later to associate exchanges. However, when a coin is exchanged, the coin appendix must be sent to the mint. And since its hash is already in the signed coin, it's certain that the correct coin appendix is associated with the coin. The mint guarantees to exchange the coin only if the signature of the exchange request is verified by the key pair which is in the coin appendix. This way, the spender can be sure that only the intended recipient can later spend the coin, and also have the best thing next to a proof of payment. If an online store publishes its public key pair, then even if the store claims to never have received the coin, the spender can simply publish coin (note that only the store can spend the coin, so everyone can see the coin) and tell the store to take it. This methods provides two features in one step: proof of payment and ability of organizations to secure every coin they receive with the public identity of the organization (not of individual members). A problem of this method is that the mint can monitor how much currency a specific digital identity exchanges. Of course, the mint can't know the total amount of currency received by a digital identity because there is no need to reissue a coin, and the recipient might never exchange some coins he received. Of course, everybody can just change their asymmetric key pair, but since they need to publish it, it can still be monitored. Now, there is certainly no need to use identities for recipients, but in practice most people would do it. The coin appendix could also contain a descriptor of its inheritors. But the problem here is that the coin would have to be put in an escrow service. It's not a problem if anybody sees it, because only it's current owner can exchange it, and in the future (after a date specified in the descriptor) only its intended inheritors can exchange it. The owner has to consider that if he still lives when the coin is about to enter its inheritable time frame, he must exchange it before that time and set a new date for inheritance. The coin appendix could also include an escrow identity. The mint must then guarantee to exchange the coin only if it's accompanied by a signed certificate from the escrow service. The coin appendix could also include a recovery identity, usually that of the original owner. This way, if the recipient never uses the coin because he dies, for example, the spender can take it back after a specified date. But this means that users must reissue the coins (for themselves) they receive, before the recovery date comes. Sure, the recovery date could be a year after the payment, but that still means that there has to be a reissue. The actual implementation of this design, requires two independent parts of the coin appendix, and therefore two hashes: * One part which contains the identity of the owner of the coin. This part is sent to the mint when the owner spends the coin. * One part which contains the identities of the inheritors of the coin. This part is sent to the mint when an inheritor reissues the coin. This way, inheritors are visible to the mint only when they actually inherit. All nice and cozy, but this design means that each transaction would take on average 1 to 2 seconds for the mint, plus about 8 times more traffic than for account based systems. (This considers that coin denominations are power of 2, so as to minimize the number of coins from each transaction.) One thing I am still unable to solve is how to hide coins. With account based systems it is simple: each visible account from the identity manager application had, automatically created, a hidden account (well, rather data which looked random to anyone without the right passphrase). I still have to think about these things to see if it's a path worth pursuing. (http://www.gardenerofthoughts.org/ideas/axiomaticid/digitalcache.htm) - The Cryptography Mailing List
PRZ going in for heart surgery
Phil Zimmermann is going in tonight (7 May) for heart bypass surgery. He's not in immediate danger -- he's not having a heart attack, he's not no in immediate danger, but they're pushing him into the hospital quicker than any reasonable person would like. Obviously, that makes for worries. He meets with his surgeon tomorrow morning, and likely will have surgery tomorrow (8 May). Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Forwarded: Public comments on the hash algorithm requirements and evaluation criteria posted online
From: Shu-jen Chang [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Public comments on the hash algorithm requirements and evaluation criteria posted online Date: Tue, 08 May 2007 12:13:58 -0400 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 FYI Public comments on the hash algorithm requirements and evaluation criteria (see Federal Register Notice Vol. 72, No. 14, January 23, 2007) are now available for review at http://www.csrc.nist.gov/pki/HashWorkshop/Public_Comments/2007_May.html . For other information related to NIST's hash algorithm competition, please visit http://www.nist.gov/hash-function . Regards, Shu-jen - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Was a mistake made in the design of AACS?
Well, there's an idea: use different physical media formats for entertainment and non-entertainment content (meaning, content created by MPAA members vs. not) and don't sell writable media nor devices capable of writing it for the former, not to the public, keeping very tight controls on the specs and supplies. This approach was rejected by the computer industry, in particular with respect to DVDs. Computer companies like Intel, HP, Dell, and Sony wanted to be able to compete to be a consumer electronics platform, playing music, video, photos, etc. Indeed, many of the advances in consumer electronics have come from computerization, such as digital music (DATs and CDs), MP3 players, digital video, fax machines, digital cameras and digital photo storage, color photo printers, ... I do recall that it took most of a decade for computer CD-ROM drives to be able to digitally read audio CDs, and then later to record them. Silicon Graphics gets major kudos for breaking that artificial barrier. Then finding, say, a Disney movie on an HD-DVD of the data format would instantly imply that it's pirated. False. It's like saying Then finding a record album on a cassette tape would instantly imply that it's pirated. No, it would instantly imply that it's been copied onto a medium of the consumer's choice. Consumers are (and should be) free to record copyrighted works onto media of their own choice, for their own convenience, without needing the permission or concurrance of the copyright owner. Congratulations, Nico, you fell into Hollywood's favorite word: pirated. It takes discipline to stop thinking in the grooves that they have worn in your brain. John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
IEEE International Conference on Intelligence and Security Informatics 2007
* IEEE International Conference on Intelligence and Security Informatics 2007 May 23-24, 2007 Hyatt Hotel New Brunswick, New Jersey ** DEADLINE FOR EARLY REGISTRATION IS ALMOST HERE ** Hosted by: Rutgers, The State University of New Jersey DIMACS-CAIT Laboratory for Port Security Center for Discrete Mathematics and Theoretical Computer Science (DIMACS) Center for Interdisciplinary Studies in Information Privacy and Security Sponsored by: Institute of Electrical and Electronics Engineers (IEEE) IEEE Systems, Man, and Cybernetics Society IEEE Intelligent Transportation Systems Society National Science Foundation Intelligence Technology Innovation Center Department of Homeland Security * Informatics research has emerged as a key scientific discipline and applications domain supporting counterterrorism and homeland security's missions of anticipation, interdiction, prevention, preparedness and response to terrorist acts. ISI 2007 provides a forum for discussions among these vital communities: academic researchers (in information technologies, computer science, public policy, and social studies), local, state, and federal law enforcement and intelligence experts, and information technology industry consultants and practitioners. Security informatics is a rapidly growing multidisciplinary area that crosscuts numerous disciplines, including computer science, information technology, engineering, public policy, medicine (medical informatics), biology (bioinformatics), social and behavioral sciences, political science, and modeling and analysis. The combination of intelligence and security informatics strives to integrate computational social science, advanced information technologies and algorithms to support counterterrorism and homeland security policies, organizations and operations (both domestically and internationally). Because of the conference's location near major New York - New Jersey ports, one of its key themes is port security, where the term port is used here in its broad sense, namely, as a point of entry/exit for secure flows of people and cargo. Other themes cover the components of effective counterterrorism, dynamic data analysis, and critical-infrastructure protection technologies. This conference aims to foster the development and growth of a counterterrorism and homeland-security community by providing a forum and podium for diverse communities: academia, government (local, state, federal law enforcement, intelligence experts, etc.) and industry (consultants and practitioners etc.). We solicit contribution of long or short papers, and proposals for panel discussions on both the science and the practice of intelligence and security informatics. The conference proceedings will be published as an IEEE publication. Several satellite conferences will also be held before ISI-2007. The upcoming IEEE International Conference on Intelligence and Security Informatics 2007 (ISI 2007) will be held May 23-24, 2007, in New Brunswick, New Jersey, at the Hyatt Hotel. There will also be two satellite conferences: The 2007 Conference on Interdisciplinary Studies in Information Privacy and Security. This conference will be held on May 22nd, 2007 from 9 a.m to 5 p.m. at the University Inn, Douglass Campus, Rutgers, New Brunswick. The second event is the NSF Workshop on Biosurveillance Systems and Case Studies, May 22, 2007, New Brunswick, New Jersey. The two previous symposia on ISI (ISI-2003, ISI-2004) were held in Tucson, Arizona; the third (ISI-2005) in Atlanta, Georgia; the fourth (ISI-2006) in San Diego, California. These meetings provided a stimulating intellectual forum for discussions among previously disparate communities: academic researchers (in information technologies, computer science, public policy, and social and behavioral studies), local, state, and federal law enforcement and intelligence experts, and information technology industry consultants and practitioners. Proceedings of these past ISI meetings were published in Springer Lecture Notes in Computer Science (LNCS). * Registration Fees: (Pre-registration deadline: May 15, 2007) For complete registration information, please see: http://dimacs.rutgers.edu/ISI2007/registration.htm Your conference fee will entitle you to: - Entrance to all conference presentations - Breakfast on both conference days (May 23-24) - Entrance to the Conference Reception, held in conjunction with the Poster and Demonstration Session, where ample food will be served (evening, May 23)
Re: More info in my AES128-CBC question
On Fri, Apr 27, 2007 at 05:13:44PM -0400, Leichter, Jerry wrote: Frankly, for SSH this isn't a very plausible attack, since it's not clear how you could force chosen plaintext into an SSH session between messages. A later paper suggested that SSL is more vulnerable: A browser plugin can insert data into an SSL protected session, so might be able to cause information to leak. Hmm, what about IPSec? Aren't most of the cipher suites used there CBC mode? If it doesn't key each flow seperately, and the opponent has the ability to generate traffic over the link, which isn't unreasonable, then this would seem feasible. And then there's openvpn, which uses SSL for the point-to-point link, thus probably vulnerable, more vulnerable than a browser. I am also aware of SSL being used many places other than browsers and openvpn. -- Kill dash nine, and its no more CPU time, kill dash nine, and that process is mine. -- URL:http://www.subspacefield.org/~travis/ For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpvjZwMdNcnK.pgp Description: PGP signature
Re: Public key encrypt-then-sign or sign-then-encrypt?
On Wed, May 02, 2007 at 09:29:39AM -0600, Anne Lynn Wheeler wrote: where there is possibly the suggestion that if the only thing being performed is authentication (and doesn't require either integrity and/or privacy) ... then possibly a totally different protocol by utilized (rather than digital signature) This reminds me a bit of a suggestion I once heard for protocol designers that the messages of the various steps of the protocol include a step number or something like it to prevent cut-and-paste attacks (presumably each message has some redundancy to protect the integrity/authenticity as well, like a running hash covering all the previous messages (in this direction)). I wonder if something similar couldn't be done with digital signatures, where the input is padded with data that indicates the semantics of the signature; not unlike the forms which say by signing here I agree that... This also makes it very difficult for the opponent to do any kind of chosen-plaintext trickery since the plaintext will be framed with this data that the opponent does not control, but that is also true with other padding options and such. -- Kill dash nine, and its no more CPU time, kill dash nine, and that process is mine. -- URL:http://www.subspacefield.org/~travis/ For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpnvBUihZ9Sw.pgp Description: PGP signature
Enterprise Right Management vs. Traditional Encryption Tools
I was recently asked why not just deploy a Enterprise Right Management solution instead of using various encryption tools to prevent data leaks. Any thoughts? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Public key encrypt-then-sign or sign-then-encrypt?
Travis H. wrote: This reminds me a bit of a suggestion I once heard for protocol designers that the messages of the various steps of the protocol include a step number or something like it to prevent cut-and-paste attacks (presumably each message has some redundancy to protect the integrity/authenticity as well, like a running hash covering all the previous messages (in this direction)). I wonder if something similar couldn't be done with digital signatures, where the input is padded with data that indicates the semantics of the signature; not unlike the forms which say by signing here I agree that... This also makes it very difficult for the opponent to do any kind of chosen-plaintext trickery since the plaintext will be framed with this data that the opponent does not control, but that is also true with other padding options and such. re: http://www.garlic.com/~lynn/aadsm26.htm#65 Public key encrypt-then-sign or sign-then-encrypt? some aspects of this was discussed in old dual-use attack thread ... it possibly isn't enuf to encapsulate all scenarios where the person intends to use the digital signature in manner analogous to human signature (indicating intent, having read, understood, authorizes, agrees, and/or approves) then if there is ever a digital signature applied for pure authentication purposes ... say random data from a server (as countermeasure to replay attacks) ... then all such signed data should always also be bracketed by disclaimer saying that such signatures are in no way met to imply agreeing, approving, and/or authorization any message content. the problem is that digital signatures are an authentication and integrity mechanism, and except for possible semantic confusion resulting from both digital signature and human signature containing the same word (signature) ... there is no relationship. a danger of any mis-use of digital signatures as representing human signatures ... is if they are also used for authentication ... where the human doesn't actually physically examine and understand every bit that a signature might be applied to. if the human doesn't actually physical examine and understand every bit that they might apply a signature too ... then it becomes a requirement that all such (signed and unexamined) bits are wrapped with strong disclaimer about any existence of a digital signature is not met to imply read, understood, approves, agrees, and/or authorizes. ... aka any random data not examined, but signed ... could in fact contain padding and comments about aggreement ... to appear as if the signer actually wrapped it (instead of the attacker). lots of past posts discussing signatures ... included having been called in to help word-smith the cal. state electronic signature legislation. http://www.garlic.com/~lynn/subpubkey.html#signature related and slightly facetious posting here: http://www.garlic.com/~lynn/aadsm26.htm#69 survey of RFC S/MIME signature handling as part of this thread http://www.garlic.com/~lynn/aadsm26.htm#67 survey of RFC S/MIME signature handling - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Enterprise Right Management vs. Traditional Encryption Tools
On May 8, 2007, at 10:16 AM, Ali, Saqib wrote: I was recently asked why not just deploy a Enterprise Right Management solution instead of using various encryption tools to prevent data leaks. Any thoughts? What problem are you trying to solve? If you're dealing with a rights-management problem, such as how do you give someone a document that they can read on the screen but not print, you aren't going to solve that with a cryptosystem. However, rights management systems have characteristics that are different. Rights management systems work against polite attackers. They are useless against impolite attackers. Look at the way that entertainment rights management systems have been attacked. The rights management system will be secure so long as no one wants to break them. There is tension between the desire to break it and the degree to which its users rely on it. At some point, this tension will snap and it's going to hurt the people who rely on it. A metaphor involving a rubber band and that smarting is likely apt. One way this fails is the good old analog hole. People can still take pictures of their screens. Another way this fails is for people to rely upon rights management as a cover for sloppiness, anger, or mendacity. If you think you can revoke a message or send Mission Impossible documents, you will. Someday, someone on the receiving end will use the analog hole. Oops. Imagine the case where a tech support person tells off an obnoxious customer, who takes a picture of the screen. Furthermore, there are subtle problems with rights-management and policy. Let's suppose that I run an organization that needs to archive documents. I therefore *must* reject documents that I cannot archive. I have personally stuck more to having crypto be a form of access control (once you get to a document, you have it) than as use control because: * The former problem is hard enough * We know that DRM of any sort will untimately fail * Human nature will lead people to get into trouble *because* of rights management. I think that the operational issue -- that rights management *cannot* work -- trumps everything else, and turns the social issues (if you can tell someone off and deny it, will you?) into -- into nothing other than a information bomb. You're going to end up looking like Wile E. Coyote, with a blackened face and stunned, blinking eyes. Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More info in my AES128-CBC question
On Wed, 9 May 2007 15:35:44 -0400 Thor Lancelot Simon [EMAIL PROTECTED] wrote: On Wed, May 09, 2007 at 01:13:36AM -0500, Travis H. wrote: On Fri, Apr 27, 2007 at 05:13:44PM -0400, Leichter, Jerry wrote: Frankly, for SSH this isn't a very plausible attack, since it's not clear how you could force chosen plaintext into an SSH session between messages. A later paper suggested that SSL is more vulnerable: A browser plugin can insert data into an SSL protected session, so might be able to cause information to leak. Hmm, what about IPSec? Aren't most of the cipher suites used there CBC mode? ESP does not chain blocks across packets. One could produce an ESP implementation that did so, but there is really no good reason for that, and as has been widely discussed, an implementation SHOULD use a PRNG to generate the IV for each packet. Mostly right. RFC 2405 stated: Implementation note: Common practice is to use random data for the first IV and the last 8 octets of encrypted data from an encryption process as the IV for the next encryption process; this logically extends the CBC across the packets. not as a requirement but as a hint. On the other hand, RFC 3602 says The IV MUST be chosen at random, and MUST be unpredictable. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More info in my AES128-CBC question
| Frankly, for SSH this isn't a very plausible attack, since it's not | clear how you could force chosen plaintext into an SSH session between | messages. A later paper suggested that SSL is more vulnerable: | A browser plugin can insert data into an SSL protected session, so | might be able to cause information to leak. | | Hmm, what about IPSec? Aren't most of the cipher suites used there | CBC mode? | | ESP does not chain blocks across packets. One could produce an ESP | implementation that did so, but there is really no good reason for | that, and as has been widely discussed, an implementation SHOULD use | a PRNG to generate the IV for each packet. I hope it's a cryptographically secure PRNG. The attack doesn't require any particular IV, just one known to an attacker ahead of time. However, cryptographically secure RNG's are typically just as expensive as doing a block encryption. So why not just encrypt the IV once with the session key before using it? (This is the equivalent of pre-pending a block of all 0's to each packet.) -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More info in my AES128-CBC question
| Frankly, for SSH this isn't a very plausible attack, since it's not | clear how you could force chosen plaintext into an SSH session between | messages. A later paper suggested that SSL is more vulnerable: | A browser plugin can insert data into an SSL protected session, so | might be able to cause information to leak. | | Hmm, what about IPSec? Aren't most of the cipher suites used there | CBC mode? If it doesn't key each flow seperately, and the opponent | has the ability to generate traffic over the link, which isn't | unreasonable, then this would seem feasible. And then there's openvpn, | which uses SSL for the point-to-point link, thus probably vulnerable, | more vulnerable than a browser. I am also aware of SSL being used | many places other than browsers and openvpn. Just being able to generate traffic over the link isn't enough to carry out this attack. You have to be able to get the sender to encrypt a chosen block for you as the first thing in a packet. How would you do that? Suppose there was an echo command that would cause the receiver to send back (within the encrypted channel) whatever data you asked. Well, how do you get an echo command inserted into the encrypted, presumably authenticated, flow going back the other way? The browser SSL attack could work because plugin code runs *within* the browser - which knows the key - and it can add material to the red (plaintext) connection data. How do you propose mounting the attack given only access to the black connection data? I'm not saying there couldn't be such an attack, or that it's not worth defending against - just that it appears to be very hard to pull off. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Public key encrypt-then-sign or sign-then-encrypt?
On Thu, May 03, 2007 at 07:57:18PM +1000, James A. Donald wrote: Assume Ann's secret key is a, and her public key is A = G^a mod P Assume Bob's secret key is b, and his public key is B = G^b mod P Bob wants to send Ann a message. Bob generates a secret random number x, and sends Ann X = G^x mod P Ann responds with Y = G^y mod P, where y is another secret random number. Ann calculates [(B*X)^(a+y)] mod P This appears to simplify to: (G^b * G^x)^(a+y) = (G^(b+x))^(a+y) = G^((b+x)(a+y)) Right? This doesn't appear to be anything like the latest rev of the OTR protocol: http://www.cypherpunks.ca/otr/Protocol-v2-3.0.0.html Apparently they key exchange is now a variant of the SIGMA protocol, and relies upon the implementation to disclose MAC keys automagically as the related session keys are destroyed/expired. Apparently this fixes an identity-binding flaw: http://lists.cypherpunks.ca/pipermail/otr-users/2005-July/000316.html And this illustrates a subtlety: For example, if Bob thinks he's talking to Mallory, he may tell her something in confidence he would not want Alice to hear. Note that although Mallory could relate this confidential information to Alice herself, but in the attack scenario Alice has assurance that the message came from Bob rather than having to take Mallory's word for it. Contrast this to sign-then-encrypt, where Mallory could decrypt, then forward to Alice. Compare with encrypt-then-sign. But it brings up an interesting point; that when a party relays a piece of data it may not be equivalent to receiving it directly; that is, authenticity may not be transitive. Put another way, maybe it's not the information that matters, but who says it. The New York Times may say that someone did XYZ, but that's not entirely the same as the person admitting it under oath. In international politics, many believe that admitting to having performed some provocative action can be more provocative than actually the action itself, even if everyone already knows who is responsible. If you believe this, I suppose the official lie can be said to serve the interest of both sides, as the government receiving the provocation can allow the story to go unchallenged, and probably not be forced into taking an overt retaliatory action. Thus it preserves their options, and avoids forcing them into what could be a disastrous confrontation. If they are too weak to confront the provocateur, they aren't likely to shout this from the rooftops. -- Kill dash nine, and its no more CPU time, kill dash nine, and that process is mine. -- URL:http://www.subspacefield.org/~travis/ For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgp2OKJBtiEKs.pgp Description: PGP signature
