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: Client Certificate UI for Chrome?
On Thu, Sep 03, 2009 at 04:26:30PM +1200, Peter Gutmann wrote: Steven Bellovin s...@cs.columbia.edu 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: [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: Client Certificate UI for Chrome?
Ian G i...@systemics.com 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
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: 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: SHA-1 and Git (was Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git)
Thor Lancelot Simon t...@rek.tjls.com 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: 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: 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: 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
