Re: Enterprise Right Management vs. Traditional Encryption Tools
On Wed, 9 May 2007, Ali, Saqib wrote: What about DRM/ERM that uses TPM? With TPM the content is pretty much tied to a machine (barring screen captures etc) Will ERM/DRM be ineffective even with the use of TPM? ERM/DRM/TPM are such poorly defined and implemented products that people have started referring to a "DRM fairy" who people assume will wave her wand and solve whatever problem is at hand. I used to try to draw out the mentioner's claims into a concrete proposal that everyone could objectively examine, but the conversation rarely progressed that far. So now I think that, as with other crypto proposals, the onus should now be on the proposer to clearly delineate what they're proposing and convince us that it's complete and correct, rather than us nodding our heads or lashing out at what we assume it means. So I guess the answer to your question is "We'd better assume that DRM+TPM will be ineffective until we've subjected a specific implementation of it to the same level of scrutiny we apply to other cryptosystems, and since DRM+TPM proposals tend to be much more complicated than other cryptosystems like SSL, that's going to take a very long time." - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Can you keep a secret? This encrypted drive can...
On Sat, 4 Nov 2006, Ralf Senderek wrote: On the unencrypted filesystem: # > time dd if=/dev/zero of=cryptogram bs=1MB count=50 50+0 records in 50+0 records out 5000 bytes (50 MB) copied, 0.216106 seconds, 231 MB/s real0m0.257s user0m0.000s sys 0m0.252s Unless you have a disk array in your laptop, that performance is an artifact of buffering. Here are unbuffered and buffered numbers for my rather new desktop machine: $ hdparm -t /dev/sda /dev/sda: Timing buffered disk reads: 174 MB in 3.01 seconds = 57.79 MB/sec $ hdparm -T /dev/sda /dev/sda: Timing cached reads: 5188 MB in 2.00 seconds = 2595.82 MB/sec The 25MB/sec number for your encrypted partition looks like it's probably right, though: $ openssl speed aes-256-cbc [...] The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256 cbc 52071.66k55008.98k55609.83k55984.13k55776.36k - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Interesting bit of a quote
On Fri, 14 Jul 2006, Travis H. wrote: Absent other protections, one could simply write a new WORM media with falsified information. I can see two ways of dealing with this: 1) Some kind of physical authenticity, such as signing one's name on the media as they are produced (this assumes the signer is not corruptible), or applying a frangible difficult-to-duplicate seal of some kind (this assumes access controls on the seals). 2) Some kind of hash chain covering the contents, combined with publication of the hashes somewhere where they cannot be altered (e.g. publish hash periodically in a classified ad in a newspaper). My MS Thesis was on this topic: http://lunkwill.org/cv/logcrypt_update.pdf If you store a value with a TTP (say, an auditor), and follow the protocol honestly, it's impossible to go back later and falsify records. The symmetric version uses hash chains, and was invented several times before I came along. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Use of TPM chip for RNG?
On Thu, 29 Jun 2006, "Hal Finney" wrote: A few weeks ago I asked for information on using the increasingly prevalent built-in TPM chips in computers (especially laptops) as a random number source. I got some good advice and want to summarize the information for the benefit of others. Thanks for the useful summary! For the sake of completeness, let me also add that RNGs in tamper-proof hardware are potentially rather controversial, since there are several known ways to produce output which looks very random to anyone who doesn't know some secret, but allows those who do to predict what future outputs will be. I believe one straightforward way to do this would be to simply use a symmetric encryption function outputting "random" data blocks r_i=Encrypt(key, r_(i-1)) If you don't know the secret key, the output will look at least somewhat random, but if you do, you can use any block to predict all subsequent and prior ones. (This topic has been discussed in the literature, and my off-the-cuff example may not be particularly strong.) I believe it's a fair summary to say that hardware RNG is a neat and useful feature, but may be unsuitable for the sufficiently paranoid when it comes in a tamper-proof package. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Voice phishing
http://www.theregister.co.uk/2006/06/26/voice_phishing/ Hi-tech fraudsters have begun using recorded telephone messages in a bid to trick users into handing over confidential account information. The tactic has been adopted as a variant of recently detected phishing attacks targeting customers of the Santa Barbara Bank & Trust. ... - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Linux RNG paper
On Thu, 04 May 2006 18:14:09 +0200, markus reichelt <[EMAIL PROTECTED]> wrote: Agreed; but regarding unix systems, I know of none crypto implementation that does integrity checking. Not just de/encrypt the data, but verify that the encrypted data has not been tampered with. There's also ecryptfs: http://ecryptfs.sourceforge.net/ -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Paper summarizing new directions in protecting web users
On Mon, 6 Mar 2006, Amir Herzberg wrote: I've summarized the current directions that our group is working on towards improving security for web users. I'll probably soon post it as HTML, but I'm terribly busy and so far just posted it in eCrypt as PDF, see at http://eprint.iacr.org/2006/083.pdf. [...] Amir will also be appearing next month in a panel I'm moderating on the challenges of practical web security at NIST's PKI conference. Some of the discussions I've seen on this list led to the creation of that panel -- if we as cryptographers sometimes have to wrangle over what's considered trustworthy website behavior, how are users ever supposed to cope? The standard flyer for that conference follows: *** NO ON-SITE REGISTRATION! Last day to register: March 17 *** 5th Annual PKI R&D Workshop at NIST in Gaithersburg, MD "Making Cryptography Easy to Use" April 4-6, 2006 http://middleware.internet2.edu/pki06/ Come join with experts from NIST, NIH, private industry and universities around the world for our fifth workshop! Scheduled topics include: KEYNOTE ADDRESS HAS JOHNNY LEARNT TO ENCRYPT BY NOW? Examining the troubled relationship between a security solution and its users Angela Sasse, University College London REFEREED PAPERS: -How Trust Had a Hole Blown In It. The Case of X.509 Name Constraints -Navigating Revocation through Eternal Loops and Land Mines -Simplifying Credential Management through PAM and Online Certificate Authorities -Identity Federation and Attribute-based Authorization through the Globus Toolkit, Shibboleth, GridShib, and MyProxy -PKI Interoperability by an Independent, Trusted Validation Authority -Achieving Email Security Usability -CAUDIT PKI Federation - A Higher Education Sector Wide Approach INVITED TALKS: -NIST Cryptographic Standards Status Report, Bill Burr, NIST -Trust Infrastructure and DNSSEC Deployment, Allison Mankin, Consultant -Integrating PKI and Kerberos, Jeffrey Altman, Secure Endpoints Inc. -Enabling Revocation for Billions of Consumers, Kelvin Yiu, Microsoft PANELS: - Digital Signatures (Moderator: David Chadwick, University of Kent) - Domain Keys Identified Mail (DKIM) (Moderator: Barry Leiba, IBM) - Browser Security User Interfaces: Why are web security decisions hard and what can we do about it? (Moderator: Jason Holt, Brigham Young University) - Federal PKI Update (Moderator - Peter Alterman, National Institutes of Health) - Bridge-to-Bridge Interoperations (Moderator - Peter Alterman, National Institutes of Health) WORKS IN PROGRESS (WIP) (Contact Krishna Sankar ([EMAIL PROTECTED]) if you have additional WIP topics) Potential topics: - CNRI handle system (brief overview) - International Grid Trust Federation Complete agenda is available at http://middleware.internet2.edu/pki06/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: EDP (entropy distribution protocol), userland PRNG design
On Sat, 4 Feb 2006, Travis H. wrote: Suppose that /dev/random is too slow (SHA-1 was never meant to generate a lot of output) because one of these machines wishes to generate a large file for use as a one-time pad*. That leaves distributing bits. * /dev/random's output is limited by available entropy, not the speed of sha1. You want /dev/urandom instead. * You're talking about a stream cipher, not a OTP, especially since an attacker could see the "plaintext" over the network and would only need to break the cipher to get at the "pad" * It's dangerous to offhandedly propose stream ciphers, especially when we have some tried and tested ones, and it doesn't really make sense to use them as if they were OTPs, since then you get the benefits of neither * Hash functions are comparably fast to ciphers anyway, and are plenty fast for the application you propose: [EMAIL PROTECTED] ~$ openssl speed sha1 Doing sha1 for 3s on 16 size blocks: 1718543 sha1's in 2.99s ... [EMAIL PROTECTED] ~$ dc 1718543 20 *p 34370860 So sha1 generates 34Mbyte/sec, which is enough to saturate a gigabit ethernet link in many installations. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: another feature RNGs could provide
On Mon, 12 Dec 2005, Travis H. wrote: One thing I haven't seen from a PRNG or HWRNG library or device is an unpredictable sequence which does not repeat; in other words, a [cryptographically strong?] permutation. This could be useful in all Rich Schroeppel tells me his "Hasty Pudding" cipher can be used to create PRPs (pseudorandom permutations) of arbitrary size. It even has the ability to let you define external functions to help define set membership (for sets which aren't just composed of the natural numbers). http://scholar.google.com/scholar?q=schroeppel+hasty&ie=UTF-8&oe=UTF-8&hl=en&btnG=Search -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: crypto wiki -- good idea, bad idea?
On Mon, 12 Dec 2005, Paul Hoffman wrote: Or should we just stick to wikipedia? Is it doing a satisfactory job? Also check out the Cryptography Reader: http://en.wikipedia.org/wiki/Wikipedia:WikiReader/Cryptography "Matt Crypto" set up an "article (to clean up) of the day" replete with a bar graph of how "done" he thinks it is. As to accuracy, there are several authors I respect who keep many of the crypto articles on their watchlists, so that we notice when people make changes. I'm quite happy with a number of the pages in the reader, enough that I point my students to them and use the figures in my lecture slides. I like the intersecting planes in the "secret sharing" article particularly: http://en.wikipedia.org/wiki/Secret_sharing of work. I proposed a few weeks ago (in the meta-discussion) to do it, but was concerned that doing so would step on toes and seem invasive. No one has responded to that, not even the people who flagged the article as needing work. An old wikipedia saying is "be bold in updating pages": http://en.wikipedia.org/wiki/WP:BBIUP -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Web Browser Developers Work Together on Security
http://dot.kde.org/1132619164/ Core KDE developer George Staikos recently hosted a meeting of the security developers from the leading web browsers. The aim was to come up with future plans to combat the security risks posed by phishing, ageing encryption ciphers and inconsistent SSL Certificate practise. Read on for George's report of the plans that will become part of KDE 4's Konqueror and future versions of other web browsers. In the past few years the Internet has seen a rapid growth in phishing attacks. There have been many attempts to mitigate these types of attack, but they rarely get at the root of them problem: fundamental flaws in Internet architecture and browser technology. Throughout this year I had the fortunate opportunity to participate in discussions with members of the Internet Explorer, Mozilla/FireFox, and Opera development teams with the goal of understanding and addressing some of these issues in a co-operative manner. Our initial and primary focus is, and continues to be, addressing issues in PKI as implemented in our web browsers. This involves finding a way to make the information presented to the user more meaningful, easier to recognise, easier to understand, and perhaps most importantly, finding a way to make a distinction for high-impact sites (banks, payment services, auction sites, etc) while retaining the accessibility of SSL and identity for smaller organisations. In Toronto on Thursday November 17, on behalf of KDE and sponsored by my company Staikos Computing Services, I hosted a meeting of some of these developers. We shared the work we had done in recent months and discussed our approaches and strengths and weaknesses. It was a great experience, and the response seems to be that we all left feeling confident in our direction moving forward. There was strong support for the ideas proposed and I think we'll see many of them released in production browsers in the near future. I think we were pleasantly surprised to see elements of our own designs in each other's software, and it goes to show how powerful our co-operation can be. The first topic and the easiest to agree upon is the weakening state of current crypto standards. With the availability of bot nets and massively distributed computing, current encryption standards are showing their age. Prompted by Opera, we are moving towards the removal of SSLv2 from our browsers. IE will disable SSLv2 in version 7 and it has been completely removed in the KDE 4 source tree already. KDE will furthermore look to remove 40 and 56 bit ciphers, and we will continually work toward preferring and enforcing stronger ciphers as testing shows that site compatibility is not adversely affected. In addition, we will encourage CAs to move toward 2048-bit or stronger keys for all new roots. These stronger cryptography rules help to protect users from malicious cracking attempts. From a non-technical perspective, we will aim to promote, encourage, and eventually enforce much stricter procedures for certificate signing authorities. Presently all CAs are considered equal in the user agent interface, irrespective of their credentials and practices. That is to say, they all simply get a padlock display when their issued certificate is validated. We believe that with a definition of a new "strongly verified" certificate with a special OID to distinguish it, we can give users a more prominent indicator of authentic high-profile sites, in contrast to the phishing sites that are becoming so prevalent today. This would be implemented with a significant and prominent user-interface indicator in addition to the present padlock. No existing certificates would see changes in the browser. To explain what this will look like, I need to take a step back and explain the history of the Konqueror security UI. It was initially modeled after Netscape 4, displaying a closed golden padlock in the toolbar when an SSL session was initiated and the certificate verification project passed. The toolbar is an awful place for this, but consistency is extremely important, and during the original development phase of KDE 2.0, this was the only easy way to implement what we needed. Eventually we added a mechanism to add icons to the status bar and made the status bar a permanent fixture in browser windows, preventing malicious sites from spoofing the browser chrome and making the security icon more obvious to the user. In the past year a padlock and yellow highlight were added to the location bar as an additional indication. This was primarily based on FireFox and Opera. I was initially resistant to the idea of using colour to indicate security - especially the colour yellow! However the idea we have discussed have been implemented by Microsoft in their IE7 address bar, when I saw it in action I was sold. I think we should implement Konqueror the same way for KDE4. It involves the following steps:
Re: gonzo cryptography; how would you improve existing cryptosystems?
On Fri, 4 Nov 2005, Travis H. wrote: PS: There's a paper on cryptanalyzing CFS on my homepage below. I got to successfully use classical cryptanalysis on a relatively modern system! That is a rare joy. CFS really needs a re-write, there's no real good alternatives for cross-platform filesystem encryption to my knowledge. Take a look at ecryptfs before rewriting cfs: http://sourceforge.net/projects/ecryptfs -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
nym-0.4 released (now includes Javascript) (fwd)
-- Forwarded message -- Date: Fri, 21 Oct 2005 09:22:34 + (UTC) From: Jason Holt <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: nym-0.4 released (now includes Javascript) The most notable feature in this release of nym is that you can now use nym entirely from your web browser: http://www.lunkwill.org/src/nym/javascript/jsnymclient.html Until someone figures out how to create client certificate requests in Javascript, the CA will have to do so instead (or, you could generate the request on a separate machine and paste it in with a trivial hack). This means the CA will know your certificate's private key; this is bad if you want to make sure you can never be impersonated. It's actually good if you want deniability, since you can always claim that the CA chose to impersonate you. There are other miscellaneous bugfixes which break compatibility with earlier versions. Sources (including the javascript client) are available here, as always: http://www.lunkwill.org/src/nym/ -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Hooking nym to wikipedia (fwd)
-- Forwarded message -- Date: Mon, 3 Oct 2005 08:32:44 -0400 From: Paul Syverson <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: cryptography@metzdowd.com Subject: Re: Hooking nym to wikipedia Hi Jason et al, On Mon, Oct 03, 2005 at 11:48:48AM +, Jason Holt wrote: More thoughts regarding the tokens vs. certs decision, and also multi-use: [snip] A related approach that thwarts the network eavesdropper would be to issue a series of certificates which expire one per interval (hour/day/whatever, trading privacy against the hassle of managing lots of certs). Then our dissident uses each cert in turn, securely deleting it after it expires. The CA keeps a list recording all the certs issued to the same user, and when Wikipedia wishes to ban a user, the CA revokes all the unexpired certs for that user. The CA also securely deletes expired certs from its lists, so that if compromised, it has merely the same list of certs found on the client machine, and is likewise devoid of any reference to certs used in prior transactions. Of course, there are nifty cryptographic solutions to the problem of revoking repeat offenders without linking activities of good users. Private Credentials and Idemix are the two best known examples, but both are complicated and patent-ridden. You might want to have a look at our UST (Unlinkable Serial Transactions) It was published in ACM TISSEC http://chacs.nrl.navy.mil/publications/CHACS/1999/1999stubblebine-serial.pdf (or .ps) There was also an earlier version published at Financial Crypto. (It lacks the proofs and some improvements to the protocols) http://chacs.nrl.navy.mil/publications/CHACS/1997/1997goldschlag-FC97.pdf (or .ps) 1. I think it is much less complicated than the other things you raised, but of course has other tradeoffs. 2. The papers are it. There is no current code worth looking at. 3. Thanks for the reminder. It too is patented if not patent-ridden, but we should be able to cope with that. Basically you shouldn't put huge work in assuming that there are no encumbrances to address, but if you are interested given 1 and 2 after you look at it, let me know. I can then explain the issues regarding the patent situation. aloha, Paul - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Hooking nym to wikipedia
More thoughts regarding the tokens vs. certs decision, and also multi-use: * Client certs are a pain to turn on and off. If you select "ask me every time" before sending a client cert, you have to click half a dozen "OK"s per page. (This could be mitigated by having Wikipedia only use the SSL server for edits, since they're not blocking article viewing anyway, just editing.) If you tell the browser to send the certificate automatically and then forget about it, other SSL sites can silently request it, which is particularly bad if you're not using tor just then. * Using tokens directly at site login time avoids the client cert hassles. However, evil web servers could then collect tokens (nyms) for use at other sites, suggesting that each server should run its own token server. But now each server has a (potentially short) list of client IPs, whereas a centralized token server would provide better concealment. Obviously, if wikipedia is the only site that ever bothers to use nym, this is a moot point. * Lack of forward secrecy is indeed an issue, since our metaphorical Chinese dissident must keep around her cert to continue using it, which if discovered links her with all her past activities. This is a problem even if Wikipedia maps each client cert to a particular random value for public display, since the attackers can simply use the stolen cert to make an edit on wikipedia and then check to see if the identifier comes up the same. If Wikipedia generates a new random ID for each edit, then attackers have to access Wikipedia internals to map the IDs back to the cert, but then, so do Wikipedia admins when they want to assess a user's pattern of (bad) behavior. Note that SSL does not (IIRC) encrypt certificates, so a passive network eavesdropper can associate client certs with the random IDs. (Do the ephemeral modes hide the certs?) A related approach that thwarts the network eavesdropper would be to issue a series of certificates which expire one per interval (hour/day/whatever, trading privacy against the hassle of managing lots of certs). Then our dissident uses each cert in turn, securely deleting it after it expires. The CA keeps a list recording all the certs issued to the same user, and when Wikipedia wishes to ban a user, the CA revokes all the unexpired certs for that user. The CA also securely deletes expired certs from its lists, so that if compromised, it has merely the same list of certs found on the client machine, and is likewise devoid of any reference to certs used in prior transactions. Of course, there are nifty cryptographic solutions to the problem of revoking repeat offenders without linking activities of good users. Private Credentials and Idemix are the two best known examples, but both are complicated and patent-ridden. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Hooking nym to wikipedia
Thanks to everyone who has contributed feedback, cyphrpunk in particular. Here are my thoughts on connecting nym to wikipedia. I'll take feedback here first, then approach the WikiMedia folks. * I believe the best solution would be for wikipedia to do the following: - Run an SSL server (optionally using a self-signed cert) which requires client certificates. This is a 4-line addition to the httpd.conf. - Apache (already) automatically sets an environment variable identifying the client certificate used. MediaWiki would map this to a random state variable equivalent to its IP identifier. - When admins wish to block an "IP", they follow the usual procedure, which has a special case for the special identifiers which adds the corresponding cert to a CRL instead of modifying the IP blacklist. The client will no longer be able to connect to the SSL server. - Optionally, wikipedia can also send its list of perma-banned IPs to the (externally operated, but wikipedia-specific) token server, which will then refuse to serve those IPs. * Alternatives to this approach involve someone else setting up such an SSL server as a reverse proxy for en.wikipedia.org and communicating a special identifier to wikipedia along with the proxied data in some combination of HTTP headers and cookies. I quite like the simplicity of these approaches, which could also allow avoiding certificates entirely by allowing users to trade a token directly for a cookie. But now the header/cookie is subject (on the proxy->wikipedia link in particular) to eavesdropping, forgery and all the other things SSL is designed to prevent. So ideally, wikipedia would allow an SSL connection from the proxy, and might as well just accept the client certs or tokens directly. Also, if we eliminate certs, tokens would then have to be kept around and treated as secrets in case the user needs to get cookies issued onto other browsers or refreshed when a browser chooses to delete the cookie. Certs, OTOH, have a public cert that can be passed around, and come in a standardized file that has browser-supported passphrase en/decryption support. * Incidentally, making my apache-ssl (1.3) server reverse-proxy (impersonate, essentially) en.wikipedia.org is ridiculously simple. In the httpd.conf: # Inside the block: ProxyRequests Off ProxyPass / http://en.wikipedia.org/ ProxyPassReverse / http://en.wikipedia.org/ And in the modules.conf: LoadModule proxy_module /usr/lib/apache/1.3/libproxy.so -J (Side note to Damian Gerow: our mail servers refuse to talk to each other; my admin claims pandora.afflictions.org is reporting its IP as 10.9.22.67 (an unroutable IP), which makes a validity test fail. We'll have to find a side channel.) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: nym-0.2 released (fwd)
On Sun, 2 Oct 2005, cyphrpunk wrote: 1. Limting token requests by IP doesn't work in today's internet. Most Hopeless negativism. I limit by IP because that's what Wikipedia is already doing. Sure, hashcash would be easy to add, and I looked into it just last night. Of course, as several have observed, hashcash also leads to whack-a-mole problems, and the abuser doesn't even have to be savvy enough to change IPs. Why aren't digital credential systems more widespread? As has been suggested here and elsewhere at great length, it takes too much infrastructure. It's too easy when writing a security paper to call swaths of CAs into existance with the stroke of the pen. To assume that any moment now, people will start carrying around digital driver's licenses and social security cards (issued in the researcher's pet format), which they'll be happy to show the local library in exchange for a digital library card. That's why I'm so optimistic about nym. A reasonable number of Tor users, a technically inclined group of people on average, want to access a single major site. That site isn't selling ICBMs; they mostly want people to have access anyway. They have an imperfect rationing system based on IPs. The resource is cheap, the policy is simple, and the user needs to conceal a single attribute about herself. There's a simple mathematical solution that yields certificates which are already supported by existing software. That, my friend, is a problem we can solve. I suggest a proof of work system a la hashcash. You don't have to use that directly, just require the token request to be accompanied by a value whose sha1 hash starts with say 32 bits of zeros (and record those to avoid reuse). I like the idea of requiring combinations of scarce resources. It's definitely on the wishlist for future releases. Captchas could be integrated as well. 2. The token reuse detection in signcert.cgi is flawed. Leading zeros can be added to r which will cause it to miss the saved value in the database, while still producing the same rbinary value and so allowing a token to be reused arbitrarily many times. Thanks for pointing that out! Shouldn't be hard to fix. 3. signer.cgi attempts to test that the value being signed is > 2^512. This test is ineffective because the client is blinding his values. He can get a signature on, say, the value 2, and you can't stop him. 4. Your token construction, sign(sha1(r)), is weak. sha1(r) is only 160 bits which could allow a smooth-value attack. This involves getting signatures on all the small primes up to some limit k, then looking for an r such that sha1(r) factors over those small primes (i.e. is k-smooth). For k = 2^14 this requires getting less than 2000 signatures on small primes, and then approximately one in 2^40 160-bit values will be smooth. With a few thousand more signatures the work value drops even lower. Oh, I think I see. The k-smooth sha1(r) values then become "bonus" tokens, so we use a large enough h() that the result is too hard to factor (or, I suppose we could make the client present properly PKCS padded preimages). I'll do some more reading, but I think that makes sense. Thanks! -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
nym-0.2.1 released (live demo available)
I now have a live server available for those of you who want to play with a "real" nym tokenserver/CA/webserver. This process constitutes running three scripts and installing the client cert. Details in the README: http://www.lunkwill.org/src/nym/ (Please be nice to erg.no-ip.org). If enough people email me privately after trying it out, I'll proceed to the next phase, which will be working with the wikipedia guys to create a proxy server which should enable tor users to anonymously contribute but allow admins to block misbehaving IPs. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: nym-0.2 released (fwd)
On Sat, 1 Oct 2005, cyphrpunk wrote: All these degrees of indirection look good on paper but are problematic in practice. As the great Ulysses said, Pete, the personal rancor reflected in that remark I don't intend to dignify with comment. However, I would like to address your attitude of hopeless negativism. Consider the lilies of the g*dd*mn field...or h*ll, look at Delmar here as your paradigm of hope! [Pause] Delmar: Yeah, look at me. Okay, so maybe there's no personal rancor, but I do detect some hopeless negativism. Or perhaps it's unwarranted optimism that crypto-utopia will be here any moment now, flowing with milk and honey, ecash, infrastructure and multi show zero knowledge proofs. Maybe I just need a disclaimer: "Warning: this product favors simplicity over crypto-idealism; not for use in Utopia." Did I mention that my code is Free and (AFAIK) unencumbered? The reason I have separate token and cert servers is that I want to end up with a client cert that can be used in unmodified browsers and servers. The certs don't have to have personal information in them, but with indirection we cheaply get the ability to enfore some sort of structure on the certs. Plus, I spent as much time as it took me to write *both releases of nym* just trying to get ahold of the actual digest in an X.509 cert that needs to be signed by the CA (in order to have the token server sign that instead of a random token). That would have eliminated the separate token/cert steps, but required a really hideous issuing process and produced signatures whose form the CA could have no control over. (Clients could get signatures on IOUs, delegated CA certs, whatever.) (Side note to Steve Bellovin: having once again abandoned mortal combat with X.509, I retract my comment about the system not being broken...) the security properties of the system. Hence it makes sense for all of them to be run by a single entity. There can of course be multiple independent such pseudonym services, each with its own policies. Sure, there's no reason for one entity not to run all three services; we're only talking about 2 CGI scripts and a web proxy anyway. Or, run a CA which serves multiple token servers, and issues certs with extensions specifying what kinds of tokens were "spent" to obtain the cert. Then web servers get articulated limiting from a single CA's certs. In particular it is not clear that the use of a CA and a client certificate buys you anything. Why not skip that step and allow the gateway proxy simply to use tokens as user identifiers? Misbehaving users get their tokens blacklisted. It buys not having to strap hacked-up code onto your web browser or server. Run the perl scripts once to get the cert, then use it with any browser and any server that knows about the CA. There are two problems with providing client identifiers to Wikipedia. The first is as discussed elsewhere, that making persistent pseudonyms such as client identifiers (rather than pure certifications of complaint-freeness) available to end services like Wikipedia hurts privacy and is vulnerable to future exposure due to the lack of forward secrecy. Great, you guys work up an RFC, then an IETF draft, then some Idemix code with all the ZK proofs. In the meantime, I'll be setting up my 349 lines of perl/shell code for whoever wants to use it. Whoops, I forgot the IP-rationing code; 373 lines. Actually, if all you want is complaint-free certifications, that's easy to put in the proxy; just make it serve up different identifiers each time and keep a table of which IDs map to which client certs. Makes it harder for the wikipedia admins to see patterns of abuse, though. They'd have to report each incident and let the proxy admin decide when the threshold is reached. The second is that the necessary changes to the Wikipedia software are probably more extensive than they might sound. Wikipedia tags each ("anonymous") edit with the IP address from which it came. This information is displayed on the history page and is used widely throughout the site. Changing Wikipedia to use some other kind of identifier is likely to have far-reaching ramifications. Unless you can provide this "client idenfier" as a sort of virtual IP (fits in 32 bits) which you don't mind being displayed everywhere on the site (see objection 1), it is going to be expensive to implement on the wiki side. There's that hopeless negativism again. Do you want a real solution or not? Because I can think of at least 2 ways to solve that problem in a practical setting, and that's assuming that your assumption about MediaWiki being limited to 4-byte identifiers is even correct. The simpler solution is to have the gateway proxy not be a hidden service but to be a public service on the net which has its own exit IP addresses. It would be a sort of "virtual ISP" which helps anonymous users to gain the rights and privile
nym-0.2 released (fwd)
-- Forwarded message -- Date: Sat, 1 Oct 2005 02:18:43 + (UTC) From: Jason Holt <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: nym-0.2 released nym-0.2 is now available at: http://www.lunkwill.org/src/nym/ My tor server is currently down, so I can't set up a public trial of this, but perhaps someone else will. This release makes the following improvements: * Tokens are now issued one-per-IP to clients via a "token" CGI script. Tokens are still blindly issued, so nobody (including the token issuer) can associate tokens with IP addresses. The list of already-served IPs could be periodically removed, allowing users to obtain new pseudonyms on a regular basis. (Abusers will then need to be re-blocked assuming they re-misbehave). * A token can be used to obtain a signature on a client certificate from a separate "CA" CGI script (potentially on a different machine). Tokens can only be "spent" to obtain one cert. Code to make a CA, client certs and have the certs signed is included. * The CA public key can be installed on a third web server (or proxy) to require that users have a valid client certificate. Servers can maintain a blacklist of misbehaving client certs. Misbehavers will then be unable to access the server until they obtain a new token and client cert (via a new IP). My proposal for using this to enable tor users to play at Wikipedia is as follows: 1. Install a token server on a public IP. The token server can optionally be provided Wikipedia's blocked-IP list and refuse to issue tokens to offending IPs. Tor users use their real IP to obtain a blinded token. 2. Install a CA as a hidden service. Tor users use their unblinded tokens to obtain a client certificate, which they install in their browser. 3. Install a wikipedia-gateway SSL web proxy (optionally also a hidden service) which checks client certs and communicates a client identifier to MediaWiki, which MediaWiki will use in place of the REMOTE_ADDR (client IP address) for connections from the proxy. When a user misbehaves, Wikipedia admins block the client identifier just as they would have blocked an offending IP address. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Pseudonymity for tor: nym-0.1 (fwd)
On Thu, 29 Sep 2005, Ian G wrote: Couple of points of clarification - you mean here CA as certificate authority? Normally I've seen "Mint" as the term of art for the "center" in a blinded token issuing system, and I'm wondering what the relationship here is ... is this something in the 1990 paper? Actually, it was just the closest paper at hand for what I was trying to do, which is "nymous accounts", just as you say. So I probably shouldn't have referred to "spending" at all. My thinking is that if all Wikipedia is trying to do is enforce a low barrier of pseudonymity (where we can shut off access to persons, based on a rough assumption of scarce IPs or email addresses), a trivial blind signature system should be easy to implement. No certs, no roles, no CRLs, just a simple blindly issued token. And in fact it took me about 4 hours (while the conversation on or-talk has been going on for several days...) There are two problems with what I wrote. First, the original system is intended for cash instead of pseudonymity, and thus leaves the spender a disincentive to duplicate other serial numbers (since you'd just be accused of double spending); this is a problem since if an attacker sees you use your token, he can get the same token signed for himself and besmirch your nym. And second, it would be a pain to glue my scripts into an existing authentication system. Both problems are overcome if, instead of a random token, the client blinds the hash of an X.509 client cert. Then the returned signature gives you a complete client cert you can plug into your web browser (and which web servers can easily demand). Of course, you can put anything you want in the cert, since the servers know that my CA only certifies 1 bit of data about users (namely, that they only get one cert per scarce resource). But the public key (and verification mechanisms built in to TLS) keeps abusers from being able to pretend they're other users, since they won't have the users' private keys. The frustrating part about this is the same reason why I'm getting out of the credential research business. People have solved this problem before (although I didn't know of any Free solutions; ADDS and SOX are hard to google -- are they Free?). I even came up with at least a proof of concept in an afternoon. And yet the argument on the list went on and on, /without even an acknowledgement of my solution/. Everybody just kept debating the definitions of anonymity and identity, and accusing each other of anarchy and tyranny. We go round and round when we talk about authentication systems, but never get off the merry-go-round. Contrast that with Debevec's work at Berkeley; Ph.D in 1996 on "virtual cinematography", then The Matrix comes out in 1999 using his techniques and revolutionizes action movies. Sure, graphics is easier because it doesn't require everyone to agree on an /infrastructure/, but then, neither does the tor/wikipedia problem. I'm grateful for guys like Roger Dingledine and Phil Zimmerman who actually make a difference with a privacy system, but they seem to be the exception, rather than the rule. So thanks for at least taking notice. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Pseudonymity for tor: nym-0.1 (fwd)
-- Forwarded message -- Date: Thu, 29 Sep 2005 01:49:26 + (UTC) From: Jason Holt <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Pseudonymity for tor: nym-0.1 Per the recent discussion regarding tor and wikipedia, I've hacked together an implementation of the basic system from Chaum, Fiat and Naor's 1990 "Untraceable Electronic Cash" paper. This system allows CAs to blindly issue tokens (or "coins") which can then be "spent" elsewhere. It runs in perl, and comprises a CA, nym-maker, client application and auth checker (for the server). The tarball is here: http://www.lunkwill.org/src/nym/ Of course, it's useless at the moment since it gives out tokens indiscriminately (and probably has massive bugs), but if anyone actually cares about this idea, it will be (more or less) easy to do the following: * Put up a sample CA and server that people can use (potentially as hidden services). * Make the CA issue only one token per email address, or one token per IP address, one per computational puzzle, one for every $20 mailed in... * Automatically expire CA keys and generate new ones on a regular basis (rather than bothering with CRLs) * Instead of randomly generated tokens, have the CA sign an actual X.509 cert request, which will then become a perfectly valid X.509 cert useful as a client-side cert in unmodified browsers and web servers * Create some sort of aid for maintaining server-side (or CA) blacklists of improperly behaving users * Check to see if the protocol is actually still secure and properly implemented. Comments welcome. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: PKI too confusing to prevent phishing, part 28
On Mon, 26 Sep 2005, Steven M. Bellovin wrote: This is an important point. When *many* people are doing the "wrong" thing, the problem isn't the people, it's the mechanism they're being asked to use. Once we have a better solution to the problem, I'll agree. But in the meantime, I'd say the problem is mismatched expectations. OS manufacturers have convinced the public that home computers don't require trained administrators, and in my experience this just isn't true. Likewise, it's easy to drive a car, but training is generally required to drive a car safely, and lots of people still get hurt doing it. Your statement is a good way to recognize an Elegant solution to a problem, but some problems don't yet have Elegant solutions, and sometimes the Elegant solution to a problem isn't practical. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
On Mon, 12 Sep 2005, Sidney Markowitz wrote: Does anyone know of an open source crypto package written in perl that is careful to try to clear sensitive data structures before they are released to the garbage collector? [...] Securely deleting secrets is hard enough in C, much less high level languages. I've often considered trying to write a C-based module for secret storage, but it's problematic (although the Taint stuff looks promising) and to my knowledge has never been done. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Query about hash function capability
On Thu, 4 Aug 2005, Arash Partow wrote: ie: input1 : abcdefg -> h(abcdefg) = 123 input2 : gabcdef -> h(gabcdef) = 123 input3 : fgabcde -> h(fgabcde) = 123 I don't have a formal reference for you, but this seems intuitively correct to me: put the strings in a canonical form so that all equivalent strings reduce to the same string, then hash conventionally. Eg., for rotation, the canonical form of a string is the rotation which gives the smallest value when the string is considered a binary number. In other words, alphabetize all the rotations and then take the first one. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: New Credit Card Scam (fwd)
On Mon, 11 Jul 2005, Lance James wrote: [...] place to fend off these attacks. Soon phishers will just use the site itself to phish users, pushing away the dependency on tricking the user with a "spoofed" or "mirrored" site. [...] You dismiss too much with your "just". They already do attack plenty of sites, but they also phish because it has a larger return on investment. Security is the process of iteratively strengthening the weakest links in the chain. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
New Credit Card Scam (fwd)
I remember the first time a site asked for the number on the back of my credit card. It was a Walmart or Amazon purchase, and with no warning they redirected me to some site with a questionable domain. I thought for sure my session was being hijacked, and my bank had given me no idea what the number was for or whether it was something I was supposed to give out. To me, this is closely related to the discussions we have here about web browser security semantics. With a very good understanding of the underlying PKI, we can usually sort out "secure" from "suspicious" site behaviors with some discussion, but how is the average user (or even the average engineer) supposed to cope? Is there a standard or even just a document somewhere that defines best practices for both server and user behavior with respect to SSL web sites and credit card transactions? Or are we leaving them to forward emails to each other warning them not to give out their 3-digit codes over the phone, and that they had better make sure their Dell doesn't have a DHS keylogger installed... -J -- Forwarded message -- Date: Mon, 11 Jul 2005 11:28:50 -0700 To: undisclosed-recipients: ; Subject: New Credit Card Scam I got this from a co-worker today: Apparently, they don't ask for your number, just the 3 digit code on the back. They'll tell you they're calling from your Visa or Mastercard company and that they're trying to verify whether or not you've made a $497.99 purchase from a company in Arizona or something. They'll tell you to call your credit card company if you have any questions, etc, and they never ask for your card number, so it sounds pretty legit, but it's not. If it does happen to you, within a few minutes of the phone call you'll have a charge for $497.99 on your card. You can always call the credit card company yourself and make sure they're the ones wanting to check about fradulent charges, so if you get a call that sounds fishy, just tell them you'll call them back at the number on your card. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: /dev/random is probably not
On Fri, 1 Jul 2005, Charles M. Hannum wrote: Most implementations of /dev/random (or so-called "entropy gathering daemons") rely on disk I/O timings as a primary source of randomness. This is based on a CRYPTO '94 paper[1] that analyzed randomness from air turbulence inside the drive case. I was recently introduced to Don Davis and, being the sort of person who rethinks everything, I began to question the correctness of this methodology. While I have found no fault with the original analysis (and have not actually considered it much), I have found three major problems with the way it is implemented in current systems. I have not written exploits for these [...] You may be correct, but readers should also know that, at least in Linux: /usr/src/linux/drivers/char/random.c: * All of these routines try to estimate how many bits of randomness a * particular randomness source. They do this by keeping track of the * first and second order deltas of the event timings. And then the inputs are run through a SHA hash before being released through /dev/random. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
On Fri, 10 Jun 2005, Rich Salz wrote: I don't want to have to re-implement Apache in order to do an SSL implementation. ... Those analogies aren't apt. XML is a data format, so it's more like I don't want to have to implement ASN1/DER to do S/MIME Which is a nonsensical complaint. Now there's an ironic counterargument. I wrote a pure perl SSL implementation a while back, but ultimately had to shell out to openssl for the X.509 parsing because it was more complicated than SSL itself, and was poorly documented to boot. Niels Ferguson also trashes it in Practical Cryptography. I have friends in ecommerce who consider XML such a tar pit that they're reluctant to even hire people who think it's a good idea. So it's easy for me to believe Peter when he says that they're problematic for crypto. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: encrypted tapes
On Wed, 8 Jun 2005, Perry E. Metzger wrote: Dan Kaminsky <[EMAIL PROTECTED]> writes: 2) The cost in question is so small as to be unmeasurable. Yes, because key management is easy or free. In this case it is. As I've said, even having all your tapes for six months at a time use the same key is better than putting the tapes in the clear. If you have no other choice, pick keys for the next five years, changing every six months, print them on a piece of paper, and put it in several safe deposit boxes. Hardcode the keys in the backup scripts. When your building burns to the ground, you can get the tapes back from Iron Mountain and the keys from the safe deposit box. [...] If in-transit attacks are the real problem, just email/fax/phone the key when you ship the tapes, and have them stick it in the box when it arrives. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about "Algorithm hiding" ?)
On Wed, 8 Jun 2005, David Wagner wrote: [...] That said, I don't see how adding an extra login page to click on helps. If the front page is unencrypted, then a spoofed version of that page can send you to the wrong place. Sure, if users were to check SSL certificates extremely carefully, they might be able to detect the funny business -- but we know that users don't do this in practice. Dan Bernstein has been warning of this risk for many years. http://cr.yp.to/djbdns/bugtraq/[EMAIL PROTECTED] http://cr.yp.to/dnscache/bugtraq/[EMAIL PROTECTED] As far as I can tell, if the front page is unencrypted, and if the attacker can mount DNS cache poisoning, "pharming", or other web spoofing attacks -- then you're hosed. Did I get something wrong? Well, yes. TLS guarantees that you're talking to the website listed in the location bar. Knowing what domain you *wanted* is up to you, and Dan handles that by suggesting that perhaps you have a paper brochure from the bank which lists their domain. So, it's fine to have http://amex.com link to https://amex.com (or whatever.com) for forms requesting anything sensitive as long as amex.com (or whatever.com) is what's printed in the brochure. As Dan points out, examination of the certificate is generally pointless as long as it's signed by a trusted CA, since the attacker can get a perfectly valid cert for hackers-r-us.com anyway. The big question is just whether the domain asking for your account info corresponds with the organization you trust with it. Of course, brochures aren't exactly hard to spoof (cf. Verisign's fraudulent domain renewal postcards). And then there are the dozens of CAs your browser accepts, the CA staff who issue microsoft.com certs to random passersby, international domain names that look identical to, er, national ones. All those gotchas apply even in the "correct" implementation outlined by Dan. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: comments wanted on gbde
On Sun, 6 Mar 2005, David Wagner wrote: [...] > However, I also believe it is possible -- and, perhaps, all too easy -- > to use GBDE in a way that will not provide adequate security. My biggest > fear is that safe usage is just hard enough that many users will end up > being insecure. GBDE uses a passphrase to encrypt the disk. If you can > guess the passphrase, you can decrypt the disk. Now in theory, all we > have to do is tell users to pick a passphrase with at least 80 bits of > entropy. However, in practice, this is a pipe dream. As we know, users > often pick passphrases with very little entropy. Practices vary widely, > but for many users, an estimate in the range of 10-40 bits is probably > reasonable. Consequently, dictionary attacks are a very serious threat. > > GBDE does not take any steps to defend against dictionary attacks. > In GBDE, a passphrase with b bits of entropy can be broken with 2^b AES > trial decryptions. This means that people who are using passphrases > with only 10-40 bits of entropy may be screwed -- their data will not > be secure against any serious attack. 40-bit security is a very weak > level of protection. [...] What would you consider an ideal key management solution for disk encryption, then? It seems like any passphrase-based system will be dictionary-attackable, even with strengthening techniques like iteration, which provide a linear increase in difficulty to both normal use an attack. Is that all you were asking for, or are you thinking of token (or network) based solutions which can handle better keys than the average human? (Or, are there other more exotic techniques which make passphrases harder to break?) -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
MD2 is not one way (!?)
The list of accepted papers for AsiaCrypt: http://www.iris.re.kr/ac04/ Includes one titled "The MD2 Hash Function is Not One-Way". That's the first I've heard about MD2; the other breaks were for md4 and md5. Anyone know details? -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How thorough are the hash breaks, anyway?
On Thu, 26 Aug 2004, Trei, Peter wrote: > While any weakness is a concern, and I'm not > going to use any of the compromised algorithms > in new systems, this type of break seems to be > of limited utility. > > It allows you (if you're fortunate) to modify a signed > message and have the signature still check out. > However, if you don't know the original plaintext > it does not seem to allow you construct a second > message with the same hash. The Wikipedia article on hashes is pretty good on this topic: http://en.wikipedia.org/wiki/Cryptographic_hash_function So far, we know that the affected hashes are not collision resistant. They may still be at least somewhat one way and second preimage resistant, in which case systems which only require those properties might still be safe. But any system which specifies a secure hash in the general sense would have to come under very close scrutiny to see if it makes any assumptions at all about collision resistance. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Question on the state of the security industry (second half not necessarily on topic)
On Sun, 4 Jul 2004, Ed Reed wrote: > I recently had the same trouble with the Centers for Disease Control > (CDC) - who were calling around to followup on infant influenza > innoculations given last fall. > > Ultimately, they wanted me to provide authorization to them to receive > HIPPA protected patient records from my son's pediatrician, and I > couldn't figure out how to get them to definitively pursuade me that > they were really the CDC, who I was willing to be so authorized. [...] I had the same question about the NSA when some friends were interviewing there. Apparently investigators will just show up at your house and want to know all sorts of things about your friends, who you may or may not know to be in the process of looking for work there. As I understand it, the investigators don't even carry NSA badges; they're DSS or private investigators. I eventually found a phone number for the DSS, but AFAICT there's no standard way of authenticating the agents when they show up. Richard Bizarro had the same problem: http://www.salon.com/people/feature/2002/02/20/bizzaro/index.html Someone pointed out that the NSA isn't as concerned about other people (agencies, etc.) compromising your privacy as they are about making sure /they/ know everything about their employees. DSS: Sir, I need to ask you some questions about John Doe. Me: Okay, err, where's that NSA public key... windows registry... you don't have a certificate, I take it? DSS: Well, I have this badge here. Me: Hm, sorry, no. I don't suppose you know anything about zero-knowledge proofs... DSS: ... Me: Right. Okay, look. I'm going to randomly generate a 1024-bit -- no, better make that a 4096-bit integer. We'll run it in blocks through SHA512, and then you can raise it to your private [mumbling]. Do you have a coin? On second thought, better use my own. Lesse, heads... DSS: I have this gun, too. Me: So, what do you want to know? This was also amusing: http://www.penny-arcade.com/view.php3?date=2004-06-25&res=l -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Hiawatha's research
"Hiawatha's Research" Jason Holt <[EMAIL PROTECTED]> June, 2004, released into the public domain. Dedicated to Eric Rescorla, with apologies to Longfellow. ("E. Rescorla" may be substituted for "Hiawatha" throughout.) Hiawatha, academic, he could start ten research papers, start them with such mighty study, that the last had left his printer, ere the first deadline extended. Then, to serve the greater purpose, he would post these master papers, post them with such speed and swiftness, to gain feedback from his cohorts, for their mighty learned comments. from his printer, Hiawatha took his publication paper, sent it to the preprint archive, sent it out to all the newsgroups Then he waited, watching, listening, for the erudite discussion, for the kudos and the errors, that the others soon would send him. But in this my Hiawatha was most cruelly mistaken, for not one did read his papers, not one got past the simple abstract. Still did they all grab their keyboards, writing with great flaming fury of the folly of his venture, of his paper's great misgiving. Of his obvious omissions, of his great misunderstandings, of his utter lack of vision, of his blatant plagiarism. (This last point he found most galling, found it really quite dumbfounding, since for prior art, he'd listed ninety-three related papers.) Now the mighty Hiawatha, in his office still is sitting, contemplating on his research, thinking on his chosen topic. Wondering, in idle moments, if he had not chosen wrongly, the position he had taken as a research paper author And he thinks, my Hiawatha, if he might not have been better served by a more lowly station, as a cashier at McDonalds, as a washer at the car wash, as a cleaner of the bathrooms. Thus departs my Hiawatha. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: more hiddencredentials comments (Re: Brands' private credentials)
On Mon, 10 May 2004, Adam Back wrote: > OK that sounds like it should work. Another approach that occurs is > you could just take the plaintext, and encrypt it for the other > attributes (which you don't have)? It's usually not too challenging > to make stuff deterministic and retain security. Eg. any nonces, > randomizing values can be taken from PRMG seeded with seed also sent > in the msg. Particularly that is much less constraining on the crypto > system than what Bert-Jaap Koops had to do to get binding crypto to > work with elgamal variant. > > > In either case, though, you can't just trust that the server > > encrypted against "patient OR doctor" unless you have both creds and > > can verify that they each recover the secret. > > The above approach should fix that also right? I don't quite get what you're suggesting. Could you give a more concrete example? > > Hugo Krawczyk gave a great talk at Crypto about the going-first problem in > > IPSec, which is where I got the phrase. He has a nice compromise in letting > > the user pick who goes first, but for some situations I think hidden > > credentials really would hit the spot. > > Unless it's signifcantly less efficient, I'd say use it all the time. Well, I wouldn't complain. :) (Although pairings are quite slow, on the order of hundreds of milliseconds.) Hilarie Orman presented it at an IETF meeting to what was reportedly a lukewarm response, and they also raised the patent issue. Dan Boneh is sensitive to the issue of patented crypto, and was quite considerate when I asked about it, but www.voltage.com still has the same vague statement in their FAQ about how they're not going to be evil with the patent, so it's still up in the air whether IBE will be useful in IETF standards. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: who goes 1st problem
[Adam and I are taking this discussion off-list to spare your inboxes, but this message seemed particularly relevant. Perhaps we'll come back later if we come up with anything we think will be of general interest.] -J On Tue, 11 May 2004, Adam Back wrote: > Anyway the who goes 1st problem definition has my interest piqued: I > am thinking this would be a very practically useful network protocol > for privacy, if one could find a patent-free end-2-end secure (no > server trust), efficient solution. Another desirable feature I think > is to not use too much funky crypto, people are justifiably nervous > about putting experimental crypto into standards, even if it has > security proofs until some peer review has happened. Agreed. Ninghui Li's RSA OSBEs might be the answer; they're not quite as elegant as the IBE version, but they work with blinded RSA signatures, and so should be patent-free by next year, assuming Ninghui doesn't seek any patents. Section 4 of his PODC paper describes the RSA implementation. He also has a new paper which does neat things with commitments that I haven't wrapped my mind around yet. Actually, we might also consider contacting Dan Boneh at some point; he seems to be interested in the proliferation of IBE, and might be sympathetic to the needs of the IETF to have free standards, especially considering the exposure it'd get for his system. However, we need to define just what we need to accomplish. Since my lab works in trust negotiation, we think in terms of policies a lot, whereas SSL just assumes you know what certs you want to send to whom. But let's assume the SSL model for simplicity. The second issue, now that I think of it in this context, would be how you actually get your certs to the other guy. Hidden credentials, as Ninghui pointed out, assume you have some means for creating the other guy's cert, eg., a template "(nym):Senior_Agent:(current year)" producing "Bob:Senior_Agent:2004". The OSBE paper, OTOH, assumes we're going to exchange our certificates, just without the CA signatures. Then I can send you messages you can only read if you really do have a signature on that cert. But I've always thought that was problematic, since why would honest people bother to connect then use fake certs? The attacker doesn't need to see the signature - he believes you. So honest users would need to regularly give out fake certs so they can hide their legit behavior among the fake connects. Will Winsborough also suggests this with the notion of ACK policies - you *always* give people something they ask for, so they can't tell what you have and what you don't. So maybe what we really want is some sort of fair exchange or something, where I can show you my valid certs as you show me the valid certs of your own. If one side is guessable, we've discussed this sort of thing with hidden creds: E("Hi Bob, since you're a senior agent, you can see my agent credential: 'Alice:Denver field office agent (apprentice):2004", "Bob:Senior_Agent:2004") E("Hi Bob, since you're a BYU alumnus, you can see my BYU credential: 'Alice:Senior:computer science:3.96 gpa:2004", "Bob:Senior_Agent:2004") etc. So that's an open problem. But let's assume guessable-certs, since that's the only way I know how to really keep certs and policies safe for now. The OSBE-RSA math still works. So we're good so far, except that the RSA approach is interactive. Section 4 says that in the RSA scheme, Alice sends her cert /and blinded signature/ to Bob (which may or may not be bogus), and then Bob can send back an encrypted message. (In HC and IBE-OSBEs, Bob doesn't need the blinded signature to use as a public key). But maybe Robert's improved secret sharing scheme from the new HC paper can give us some ideas: 1. Alice sends blinded signatures for each of her relevant certs, not revealing which signature goes with each cert, and not revealing the cert contents. 2. Bob generates the contents of each of Alice's certs relevant to his policy, and simply generates each possible combination of hash-of-cert-contents and blinded-signature. One from each row will be a match-up between contents and signature, and Alice will have to figure out which. Unfortunately, this requires n^2 multiplies and exponentiations. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Brands' private credentials
On Mon, 10 May 2004, Adam Back wrote: > After that I was presuming you use a signature to convince the server > that you are authorised. Your comment however was that this would > necessarily leak to the server whether you were a doctor or an AIDs > patient. > > However from what I understood from your paper so does your scheme, > from section 5.1: > > P = (P1 or P2) is encoded HC_E(R,p) = {HC_E(R,P1),HC_E(R,P2)} > > With Hidden Credentials, the messages are in the other direction: the > server would send something encrypted for your pseudonym with P1 = > AIDs patient, and P2 = Doctor attributes. However the server could > mark the encrypted values by encoding different challenge response > values in each of them, right? Yep, that'd be a problem in that case. In the most recent (unpublished) paper, I addressed that by using R as the key for a ciphertext+MAC on the actual message. So the server would have to find two R's that both satisfy the MAC but produce different ciphertexts in order to learn anything from the response. In either case, though, you can't just trust that the server encrypted against "patient OR doctor" unless you have both creds and can verify that they each recover the secret. They might be lying about the "doctor" part, and really sending against "patient OR nonexistant", in which case your response reveals that you're a patient. That's why we recommend that your response (if any) include the policy for the creds you used in decryption. So if Alice is responding to a message she decrypted with her "patient" cred, which she only (implicitly) discloses to Medicare, and the response itself is only for AIDS clinics, she should encrypt against "Medicare AND AIDS_clinic". (And you're right, the AIDS example is not very compelling. The slides give a better one about FBI agents, but I'm still looking for other examples of super-sensitive transactions where HCs would fit) > Another approach to hiding membership is one of the techniques > proposed for non-transferable signatures, where you use construct: > > RSA-sig_A(x),RSA-sig_B(y) and verification is x xor y = hash(message). > > Where the sender is proving he is one of A and B without revealing > which one. (One of the values is an existential forgery, where you That's very slick. I'll check it out. > OK so the fact that the server is the AIDs db server is itself secret. > Probably better example is dissident's server or something where there > is some incentive to keep the identity of the server secret. So you > want bi-directional anonymity. It's true that the usual protocols can > not provide both at once; SSL provides neither, the anonymous IP v2 > protocol I designed at ZKS had client anonymity (don't reveal > pseudonym until authenticate server, and yet want to authenticate > channel with pseudonym). This type of bi-directional anonymity pretty > much is going to need something like the attribute based encryption > model you're using. Hugo Krawczyk gave a great talk at Crypto about the going-first problem in IPSec, which is where I got the phrase. He has a nice compromise in letting the user pick who goes first, but for some situations I think hidden credentials really would hit the spot. > I think it would be fair to call it anonymity system, just that the > trust model includes a trusted server. There are lots of things > possible with a trusted server, even with symmetric crypto (KDCs). Yeah, although I think most of them would require an on-line trusted server. But that just makes all sorts of things way too easy to be interesting. :) -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: blinding & BF IBE CA assisted credential system (Re: chaum's patent expiry?)
On Mon, 10 May 2004, Adam Back wrote: > On Mon, May 10, 2004 at 03:03:56AM +0000, Jason Holt wrote: > > [...] Actually, now that you mention Chaum, I'll have to look into > > blind signatures with the B&F IBE (issuing is just a scalar*point > > multiply on a curve). > > I think you mean so that the CA/IBE server even though he learns > pseudonyms private key, does not learn the linkage between true name > and pseudonym. (At any time during a show protocol whether the > private key issuing protocol is blinded or not the IBE server can > compute the pseudonyms private key). Well, he can always generate private keys for any pseudonym, just as in cash systems where the bank can always issue bank notes. Here's what I'm suggesting, where "b" is a blinding function and n1... are random nyms: Issuing: Alice FBI TTP b(n1,"agent")> b(n2,"agent")> b(n3,"agent")> <---cut & choose: n1,n3 (n1,"agent")-> (n3,"agent")-> <---sig(b(n2,"agent")) (Alice unblinds and now has a credential for nym n2) So it's vanilla Chaum-style blinded credentials. The FBI signs Alice's agent cred without learning the nym. Alice can use the nym, and the server can ask the FBI the attributes (agent? chief? secretary?) of the person with the nym, but the FBI won't know. The FBI could eavesdrop on Alice's connection and generate whatever creds are necessary to read the resource Bob sends her, but that's why I was talking about building it in a protocol with PFS. But now that I think of it, PFS isn't really necessary at all for Alice&Bob to have a conversation where their policies are respected: Alice Bob (Alice generates random nonce na) HC_E(na, "Bob:agent", FBI)---> (Bob generates random nb) <---HC_E(nb, "Alice:member", NRA) Both generate session keys from Hash(na,nb). So, Alice wants to connect iff Bob's FBI, and Bob wants to talk iff Alice is in the NRA, where "Alice" and "Bob" are random pseudonyms. Thus they send their random nonces na and nb encrypted against those creds (HC_E is a hidden cred encrypt), then use those nonces for the session keys. The FBI can *always* impersonate an agent, because, well, they're the CA and they can make up pseudonymous agents all day long. But in this protocol, I believe they wouldn't be able to be a MITM and/or just eavesdrop on Alice&Bob. That's because Bob only wants to talk to NRA members, and the FBI can't impersonate that. Now, this is for an interactive session, rather than just sending a single request/response round like I discuss in the paper. But even then, policies are always respected. Just change "na" to "request" and "nb" to "response". Alice's policy is respected whether she talks to FBI-authorized-Bob or FBI-authorized-FBI, and the FBI doesn't get to read Bob's NRA-Alice-only repsonse. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: chaum's patent expiry? (Re: Brands' private credentials)
On Sun, 9 May 2004, Adam Back wrote: > Anyone have to hand the expiry date on Chaum's patent? (Think it is > in patent section of AC for example; perhaps HAC also). I think it's June 2005. Actually, now that you mention Chaum, I'll have to look into blind signatures with the B&F IBE (issuing is just a scalar*point multiply on a curve). That could be a way to get CA anonymity for hidden credentials - just do vanilla cut and choose on blinded pseudonymous credential strings, then use a client/server protocol with perfect forward secrecy so he can't listen in. Hm, I'll have to think it out. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Brands' private credentials
Here's what I remember from about a year ago about the current state of private credentials. That recollection comes with no warranties express or implied. Last I heard, Brands started a company called Credentica, which seems to only have a placeholder page (although it does have an info@ address). I also heard that his credential system was never implemented, but that might be wrong now. Anna Lysyanskaya and Jan Camenisch came up with a credential system that I hear is based on Brands'. Anna's dissertation is online and might give you some clues. They might also have been working on an implementation. I came up with a much simpler system that has many similar properties to Brands', and even does some things that his doesn't. It's much less developed than the other systems, but we did write a Java implementation and published a paper at WPES last year about it. I feel a little presumptuous mentioning it in the context of the other systems, which have a much more esteemed set of authors and are much more developed, but I'm also pretty confident in its simplicity. http://isrl.cs.byu.edu/HiddenCredentials.html http://isrl.cs.byu.edu/pubs/wpes03.pdf Note that most anonymous credential systems are encumbered by patents. The implementation for my system is based on the Franklin/Boneh IBE which they recently patented, although there's another IBE system which may not be encumbered and which should also work as a basis for Hidden Credentials. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]