Re: Client Certificate UI for Chrome?
On Sep 7, 2009, at 8:58 AM, Jerry Leichter wrote: ...standard Mac OS GUI element to prompt for passwords ... I should expand on that a bit: This GUI element is used for all kinds of things tied to a window, not just passwords. For example, if you try to close a window that contains stuff you haven't saved, the same element is used to ask you to confirm, save now, or cancel. So it's a pretty familiar thing to Mac users -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: so how do *you* manage your keys, then? part 3
[added Cc: tahoe-...@allmydata.org, and I added ke...@guarana.org on the whitelist so his posts will go through to tahoe-dev even if he isn't subscribed] On Tuesday,2009-09-08, at 5:54 , Kevin Easton wrote: Possession of the read-cap to the mutable file gives you two things: it gives you the symmetric encryption key with which you decrypt the file contents, and it gives you the public key with which you check a digital signature in order to be sure that the file contents were written by an authorized writer. How do you prevent someone possessing the read-cap for a mutable file from rolling the file back to an earlier version that they have seen, without the consent of the write-cap possessor(s)? You don't even need a read-cap to perform a roll-back attack -- if you can control the ciphertext that the reader gets, then you can give them a copy of an older ciphertext, even if you yourself are incapable of decrypting it. This is a difficult attack to defend against. In the current version of Tahoe-LAFS we already have one interesting defense -- we the reader is communicating with many different servers, and if *any* of the servers is honest and up-to- date and informs the reader about the existence of a newer version, then the reader knows that the older version that he can read is not the latest. Readers in Tahoe-LAFS always download shares of the file from multiple servers, and all of the servers that it uses would have to agree on the version number. Therefore, to perform a rollback attack you need to control at least that many servers as well as you have to control or deny-access-to any other servers which the reader would query and which would inform him about the newer version number. See section 5 of [1]. Does that answer your question about rollback? It would be interesting to build stronger defenses against rollback attack. For starters, if the same reader reads the same file multiple times and gets new contents each time, he might as well remember the version number so that he will detect whether that file rolled back during his inspection of it. Also, it would be interesting if a file handle to a mutable file included the version number that the mutable file was at when the file handle was created. Building on that, it would be really cool if, in a future version of Tahoe-LAFS, we could make it so that you can take a cheap snapshot of the current contents and then give someone a file-handle which *both* securely identified "the most recent version that you can find of this file" and *also* "the specific (immutable) version of this file that existed when I created this file-handle". Also, am I correct in assuming that once write-caps have been distributed, they cannot be revoked, and a new file handle must be created? Currently, yes. An improvement that I would like to make in the next version of Tahoe-LAFS is to allow the holder of a write-cap to revoke it. While some kinds of revocation are tantamount to DRM ("Digital Restrictions Management") and seem to be sufficiently difficult that we're not even going to try to implement them, the specific kind of revocation that you asked about seems to be quite doable. Also, it happens to be the kind of revocation that I have already wanted for my own personal use of Tahoe-LAFS (to host my blog). :-) Here is a letter about that which explains why I needed this and how I envision it working: [2] Stronger defenses against rollback attack, and revocation of write- caps -- these are only a few of the many possible extensions to the Tahoe-LAFS secure storage design. We have a rich library of such designs documented on our issue tracker and our wiki. We are currently having a detailed design discussion on the tahoe-dev list to which several cryptographers are contributing [e.g. 3, 4]. The primary goal for the next version of Tahoe-LAFS caps is to reduce the size of the caps and improve performance, but we're also cataloguing new features such as these to see if we can work them in. Here is the wiki page where we're keeping our notes: [5]. If any smart cryptographer or hacker reading this wants to create secure, decentralized storage, please join us! We could use the help! :-) Regards, Zooko [1] http://allmydata.org/~zooko/lafs.pdf [2] http://allmydata.org/pipermail/tahoe-dev/2009-June/001995.html [3] http://allmydata.org/pipermail/tahoe-dev/2009-July/002345.html [4] http://allmydata.org/pipermail/tahoe-dev/2009-September/002808.html [5] http://allmydata.org/trac/tahoe/wiki/NewCapDesign - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Source for Skype Trojan released
Stephan Neuhaus wrote: > > On Aug 31, 2009, at 13:20, Jerry Leichter wrote: > >> It can “...intercept all audio data coming and going to the Skype >> process.” > > Interesting, but is this a novel idea? As far as I can see, the process > intercepts the audio before it reaches Skype and after it has left > Skype. Isn't that the same as calling a keylogger a "PGP Trojan"? Not really. more generically, you could call it a "VoIP trojan" or even "Audio monitoring trojan" - presumably a more advanced version could listen to the mic stream even when the VoIP application is not in use, in order to obtain information. However, in context, this was designed to be used for law enforcement to "bug" a skype VoIP session, so the name reflects the design goal; yes, it is a more generalized attack than that, but not in intent or (presumed) usage. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: SHA-1 and Git (was Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git)
Thor Lancelot Simon writes: >I think we're largely talking past one another. As regards "new horrible >problems" I meant simply that if there _are_ "new horrible problems_ such >that we need to switch away from SHA1 in the TLS PRF, the design mistakes >made in TLS 1.1 will make it much harder. Well, let's move the TLS 1.2 aspect out of the discussion and look at the underlying issues. If you're looking at this purely from a theoretical point of view then it's possible that the ability to use SHA-2 in the PRF is an improvement (it may also be a step backwards since you're now relying on a single hash rather than the dual hash used in the original design). Since no- one knows of any attacks, we don't know whether it's a step backwards, a step forwards, or (most likely) a no-op. However there's more to it than this. Once you've got the crypto sorted out, you need to implement it, and then deploy it. So looking at the two options you have: Old: No known crypto weaknesses. Interoperable with all deployed implementations. Only one option, so not much to get wrong. New: No known crypto weaknesses. Interoperable with no deployed implementations. Lots of flexibioity and options to get wrong. Removing the common factors (the crypto portion) and the no-op terms ("interoperable with existing implementations") we're left with: Old: - New: Non-interoperable. Complex -> Likely to exhibit security flaws (from the maxim that complexity is the enemy of security). That's a rather high cost to pay just for the ability to make a crypto fashion statement. Even if the ability to negotiate hash algorithms had been built in from the start, this only removes the non-interoperability but doesn't remove the complexity issue. >As I read Ben's comments, they were _advocating_ those kinds of design >mistakes, advocating hard-wiring particular algorithms or their parameter >sizes into protocols, You keep asserting that this is a mistake, but in the absence of any cryptographic argument in support, and with practical arguments against it, it looks like a feature to me. >In fact, it is radically harder to replace an entire protocol, even with a >related one, than to drop a new algorithm into an existing, properly-designed >protocol. A properly-designed security protocol is one that's both cryptographically sound and simple enough that it's hard to get wrong (or at least relatively easy to get right, admittedly not necessarily the same thing). Adding a pile of complexity simply so you can make a crypto fashion statement doesn't seem to be helping here. >If TLS 1.{0,1} had been designed to make the hash functions pluggagle >everywhere ... like that model of security protocol design IKEv1 was [0], then we'd have all kinds of interop problems and quite probably security issues based on exploitation of the unnecessary complexity of the protocol, for a net loss in security and interoperability, and nothing gained. Peter. [0] Apologies to the IPsec folks on the list, just trying to illustrate the point. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
On Sep 3, 2009, at 12:26 AM, Peter Gutmann wrote: This returns us to the previously-unsolved UI problem: how -- with today's users, and with something more or less like today's browsers since that's what today's users know -- can a spoof-proof password prompt be presented? Good enough to satisfy security geeks, no, because no measure you take will ever be good enough. However if you want something that's good enough for most purposes then Camino has been doing something pretty close to this since it was first released (I'm not aware of any other browser that's even tried). When you're asked for credentials, the dialog rolls down out of the browser title bar in a hard-to-describe scrolling motion a bit like a supermarket till printout I'm not sure what version of Camino you're running. The most recent versions use a standard Mac OS GUI element to prompt for passwords - it's indistinguishable from what you get from Safari. In both cases, a special prompt window scrolls down out of the chrome, covering some of the main body of the window. It has a distinctive look: After it's scrolled down, it appears to be "under" the chrome but over the top of the body. In Safari - I didn't experiment with Camino - it's physically tied to the browser window, moving and iconifying with it, and is fully modal at the window level - you can't switch to another tab in the same window. (Curiously, you *can* switch to a different window.) The "loading" indicator in the address bar remains active while you're being prompted. The *intent* is clearly to create something hard to spoof, but I don't know enough Flash to say if one could produce an accurate, or even plausible, fake. (Of course, *most* passwords on the Web are entered into some random web page. A distinctive secure prompt that only appears in a minority of cases doesn't help much.) The most common MacOS password prompts are from the keychain program, since you typically store your passwords there. (There are configurations in which it just asks for permission, not for a password; and configurations in which it just sends the password. But if you want to be careful, you only want keychains unlocked when you intend to use them.) Since *any* program - including programs with no visible GUI - can use keychains, these prompts are necessarily stand- alone windows at least sometimes (and for uniformity, they are so all the time). Those could be spoofed more easily (though if you're really cautious, you can unlock the necessary keychain by hand ahead of time and arrange to just give permission to use the entry later, so you're never entering your password into a window that just pops up on its own). -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
Steven Bellovin writes: >Peter, I'm not sure what you mean by "good enough to satisfy security geeks" >vs. "good enough for most purposes". I'm not looking for theoretically good >enough, for any value of "theory"; my metric -- as a card-carrying security >geek -- is precisely "good enough for most purposes". Here's a real-world example of the problem I was referring to, from a discussion with some browser developers. We were going over the above issue - how to use the results of usability studies to improve the browser security UI - and I asked why, if they were aware of this work, no-one had done anything with it. The response was that "if we implement this then attackers will use XUL to spoof it, and because of that it's not even worth trying". In other words because a hypoethetical weakness existed, it wasn't even worth attempting to improve anything. Instead of trying to help at least some of the people some of the time, it was better to leave everyone unprotected all of the time. >Given the failure of all previous attempts -- who, amongst the proponents of >EV certificates, realized that attackers could and would use all-green >favicon.ico files to fool users -- I think the burden of proof is on the >proponents. But the problem with these approaches is that they're pretty much all just random tweaking of the same thing, aimlessly rearranging the UI elements in the hope that eventually something will work after (as you point out) the twenty more or less identical previous attempts have failed. For example the Firefox password-entry mechanism (a generic popup dialog with a gibberish title) hasn't changed in at least ten years (possibly even longer, I can't remember what the Netscape 2.0 one looked like any more), all that's changed is that every major release a few new bits of flair get added to the browser chrome. The "previous attempts" aren't lots of different approaches, it's the same failed approach tried over and over and over again, with slight variations over time in the hope that one of them might work. What I was advocating was trying new approaches based on ideas from UI research, not just fiddling with the chrome in the hope that this time it'll finally start working. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: [tahoe-dev] Bringing Tahoe ideas to HTTP
James A. Donald wrote: > Nicolas Williams wrote: > > > One possible problem: streaming [real-time] content. > > Brian Warner wrote: > > Yeah, that's a very different problem space. You need > > the low-alacrity stuff from Tahoe, but also you don't > > generally know the full contents in advance. So you're > > talking about a mutable stream rather than an > > immutable file. > > Not mutable, just incomplete. > > Immutable streaming content needs a tiger hash or a > patricia hash, which can handle the fact that some of > the stream will be lost in transmission, and that one > needs to validate the small part of the stream that one > has already received rather than waiting for the end. I was assuming a real-time stream, so the goal would be to provide a filecap before the source had finished generating all the bits. This would necessarily be a mutable filecap, unless you've got some way of predicting the future :-). If instead, you just have a large file that a client wants to fetch one piece at a time, well, Tahoe's immutable-file merkle trees already handle the goal of quickly validating a small part of a large byte sequence. You could use this in a non-real-time stream, in which you process the entire input stream, produce and publish the filecap, then a client fetches pieces of that stream at their own pace. > > upgrade bundles are produced by a very strict process, > > and are rigidly immutable [...] For software upgrades, > > it would reduce the attack surface significantly. > > But how does one know which immutable file is the one > that has been blessed by proper authority? You're right, I was assuming a pre-existing secure "what to upgrade to" channel which could send down an integrity-enhanced download URL. To actually implement such a channel would require further integrity guarantees over mutable data. As I understand it, Firefox actually has a fairly complex upgrade path, because only certain combinations of from-version/to-version are fully tested by QA. Sometimes moving from e.g. 3.0.0.8 to 3.5.0.3 requires going through a 3.0.0.8->3.0.0.9->3.5.0.0->3.5.0.2->3.5.0.3 sort of path. The upgrade channel basically provides instructions to each older version, telling them which new version they should move to. The best sort of integrity guarantees I could think of would be a rule that says "the new version must be signed by my baked-in DSA key and have a version number that is greater than mine", or maybe just "the upgrade instructions must be signed by that DSA key". It's probably not a robust idea to make the rules too strict. cheers, -Brian - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
On Sep 3, 2009, at 12:26 AM, Peter Gutmann wrote: Steven Bellovin writes: This returns us to the previously-unsolved UI problem: how -- with today's users, and with something more or less like today's browsers since that's what today's users know -- can a spoof-proof password prompt be presented? Good enough to satisfy security geeks, no, because no measure you take will ever be good enough. However if you want something that's good enough for most purposes then Camino has been doing something pretty close to this since it was first released (I'm not aware of any other browser that's even tried). When you're asked for credentials, the dialog rolls down out of the browser title bar in a hard-to-describe scrolling motion a bit like a supermarket till printout. In other words instead of a random popup appearing in front of you from who knows what source and asking for a password, you've got a direct visual link to the thing that the credentials are being requested for. You can obviously pepper and salt this as required (and I wouldn't dream of deploying something like this without getting UI folks to comment and test it on real users first), but doing this is a tractable UI design issue and not an intractable business-model/political/social/etc problem. Several other people made similar suggestions. They all boil down to the same thing, IMO -- assume that the user will recognize something distinctive or know to do something special for special sites like banks. Both, to me, are unproven assumptions. Worse yet, both the security literature and what I've seen of user behavior strongly suggest to me that neither scenario is true. Peter, I'm not sure what you mean by "good enough to satisfy security geeks" vs. "good enough for most purposes". I'm not looking for theoretically good enough, for any value of "theory"; my metric -- as a card-carrying security geek -- is precisely "good enough for most purposes". A review of user studies of many different distinctive markers, from yellow URL bars to green partial-URL bars to special pictures to you-name-it shows that users either never notice the *absence* of the distinctive feature or are fooled by a tailored attack (see, e.g., the paper on picture-in-picture attacks). Maybe Camino is really better -- or maybe it just hasn't been properly attacked yet, say by a clever flash animation or some AJAX weirdness. Given the failure of all previous attempts -- who, amongst the proponents of EV certificates, realized that attackers could and would use all-green favicon.ico files to fool users -- I think the burden of proof is on the proponents. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
Ian G writes: >If one is trying to solve the whole thing, then using the much-commented >secure-bookmarks model would do this. Within the secure bookmark, record the >user's certificate and cache enough info on the server's cert to deal with >replacements (like, cert, name, CA). There's a variant of this, the site-specific browser (SSB), that takes you to (for example) your bank in a strongly sandboxed, hardened environment. This reduces the cognitive load on the user from a more or less impossible-to- follow set of instructions to "only ever do your banking by clicking on this desktop icon". This isn't by any means a general solution, but by solving for the most common cases (your bank, Paypal, eBay, Amazon) you'd address a fairly large chunk of the problem. See "Breaking out of the Browser to Defend Against Phishing Attacks" by Smetters and Stewart for more details on this. >Others have suggested some ideas, so I'll just add: the problem isn't IMO >how to do it. There are lots of good ideas. Actually that does point out one problem, which I alluded to in my previous post: we have lots and lots of good ideas, but little hard data to indicate which ones will work and which won't, or which ones work better than others (although the cynical response to this might be that almost anything would work better than what we've got now). Specifically, there are a pile of papers along the lines of "here's an experiment showing that what we're doing now doesn't work, here's a completely new security mechanism we've invented that involves redesigning the browser and server authentication back-end, and as a side-effect here are some UI ideas to go with it". What we don't have however is "here's a real-world evaluation of various ideas that have been proposed for fixing what we already have built into browsers and servers". Unfortunately without this data we (including myself) are to some extent just "people wanking around with their opinions" [0]. It's also not certain how such data would be published. Which journal or conference would accept a paper with no "new ideas" in it, just a straightforward evaluation of existing material? Peter. [0] A Linus quote, brought about by a discussion on the difference between OS secheduler design and security design: "the *discussion* on security seems to never get down to real numbers. So the difference between them is simple: one is 'hard science'. The other one is 'people wanking around with their opinions'". - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: [tahoe-dev] Bringing Tahoe ideas to HTTP
Nicolas Williams wrote: > > One possible problem: streaming [real-time] content. Brian Warner wrote: > Yeah, that's a very different problem space. You need > the low-alacrity stuff from Tahoe, but also you don't > generally know the full contents in advance. So you're > talking about a mutable stream rather than an > immutable file. Not mutable, just incomplete. Immutable streaming content needs a tiger hash or a patricia hash, which can handle the fact that some of the stream will be lost in transmission, and that one needs to validate the small part of the stream that one has already received rather than waiting for the end. > upgrade bundles are produced by a very strict process, > and are rigidly immutable [...] For software upgrades, > it would reduce the attack surface significantly. But how does one know which immutable file is the one that has been blessed by proper authority? Although Version 3.5.0 is immutable, what makes it Version 3.5.0, rather than haxx350, is that some authority says so - the same authority that said that your current version is 3.4.7 - and it should not even be possible to get a file named by some different authority as an upgrade. Of course, one would like a protocol that committed the authority to say the same thing for everyone, and the same thing for all time, saying new things in future, but never being able to retroactively adjust past things it has said. In other words, upgrades should be rooted in an append only capability. I suppose this could be implemented as a signed dag of hashes, in which whenever one upgraded, one checked that the signed dag that validates the upgrade is consistent with the signed dag that validated the current version. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: RNG using AES CTR as encryption algorithm
NIST doesn't provide specific KAT vectors for AES-CTR because the results depend on your specific counter construction. When you interact with a FIPS test lab, you will provide them with your counter construction, they will provide you with the KATs and you will then test to those KATs. This is probably why you are not finding AES-CTR vectors in the same places you might find AES-CBC vectors. NIST explains this somewhere in their publications. Convincing yourself that you have implemented AES-CTR correctly usually involves first checking that your AES-ECB is correct, then putting the output of you counter construction into some other known good AES-CTR implementation and comparing the results with your implementation. Regards, DJ priya yelgar wrote: Hi all, I have implemented RNG using AES algorithm in CTR mode. To test my implementation I needed some test vectors. How ever I searched on the CSRC site, but found the test vectors for AES_CBC not for AES CTR. Please can any one tell me where to look for the test vectors to test RNG using AES CTR. Thanks in advance Priya Ainapur - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: [cryptography] AES-GMAC as a hash
Darren J Moffat wrote: > Ignoring performance for now what is the consensus on the suitabilty > of using AES-GMAC not as MAC but as a hash ? > > Would it be safe ? > > The "key" input to AES-GMAC would be something well known to the data > and/or software. > > The only reason I'm asking is assuming it can be made to perform on > some classes of machine better than or close to SHA256 if it would be > worth considering as an available alternate now until SHA-3 is choosen. > Regarding the speed of GMAC, Intel has added a carry-less-multiplication instruction to their next generation CPUs (PCLMULQDQ)[1]. The core is the Westmere, and is shipping in engineering samples, now. This is also the CPU generation to contain the AES instructions. Unfortunately I'm only running my implementation under the intel simulator which is not cycle accurate, so I'm not sure just how fast this hardware support will make things. My understanding is that the next generation AMD CPUs, (bulldozer) will also support these instructions. eric [1] http://software.intel.com/en-us/articles/carry-less-multiplication-and-its-usage-for-computing-the-gcm-mode/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
On Thu, Sep 03, 2009 at 04:26:30PM +1200, Peter Gutmann wrote: > Steven Bellovin writes: > >This returns us to the previously-unsolved UI problem: how -- with today's > >users, and with something more or less like today's browsers since that's > >what today's users know -- can a spoof-proof password prompt be presented? > > Good enough to satisfy security geeks, no, because no measure you take will > ever be good enough. [...] Well, if you're willing to reserve screen real estate, keyboard key combinations, and so on, with said reserved screen space used to indicate unambiguously the nature of other things displayed, and reserved input combinations used to trigger trusted software paths, then yes, you can solve that problem. That's the premise of "trusted desktops", at any rate. There are caveats, like just how large the TCB becomes (including parts of the browser), the complexity of the trusted information to be presented to users versus the limited amount of screen real estate available to convey it, the need to train users to understand the concept of trusted desktops, no fullscreen apps can be allowed, accessibility issues, it all falls apart if the TCB is compromised, ... Nico -- - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: "Fed's RFIDiocy pwnd at DefCon"
On Sep 1, 2009, at 9:55 PM, Jerry Leichter wrote: ". . . federal agents at the conference got a scare on Friday when they were told they might have been caught in the sights of an RFID reader. The reader, connected to a web camera, sniffed data from RFID- enabled ID cards and other documents carried by attendees in pockets and backpacks as they passed a table where the equipment was stationed in full view" I told them so... http://csrc.nist.gov/groups/SNS/piv/documents/FIPS201-Public-Comments/Fermilab-Computer-Security.pdf - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: RNG using AES CTR as encryption algorithm
On Wed, Sep 02, 2009 at 10:58:03AM +0530, priya yelgar wrote: > Hi all, > > I have implemented RNG using AES algorithm in CTR mode. > > To test my implementation I needed some test vectors. > > How ever I searched on the CSRC site, but found the test vectors for AES_CBC > not for AES CTR. > > Please? can any one tell me where to look for the test vectors to test RNG > using? AES CTR. NIST SP 800-38A "Recommendation for Block Cipher Modes of Operation" contains a set of AES/CTR test vectors in Appendix F.5 http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf -Jack - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: RNG using AES CTR as encryption algorithm
On Wed, Sep 02, 2009 at 10:58:03AM +0530, priya yelgar wrote: > How ever I searched on the CSRC site, but found the test vectors for > AES_CBC not for AES CTR. > > Please can any one tell me where to look for the test vectors to test > RNG using AES CTR. They are trivially constructed from the test vectors for AES in ECB mode (just as counter mode is trivially constructed from ECB mode). Nico -- - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com