Re: Security of Mac Keychain, File Vault
On Oct 24, 2009, at 2:31 PM, Jerry Leichter wrote: The article at http://www.net-security.org/article.php?id=1322 claims that both are easily broken. Shrug. He doesn't explain what 'broken' means to him or under what threat model, and dammit, security without a threat model is like motherhood without apple pie. I can easily break a bank vault by putting an MP5 to the head of the guy with the key, but that's hardly the vault's fault, now is it? Speaking-only-for-myself, -- Ivan Krstić krs...@solarsail.hcs.harvard.edu | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: FileVault on other than home directories on MacOS?
On Sep 22, 2009, at 5:57 AM, Darren J Moffat wrote: There is also a sleep mode issue identified by the NSA Unlike FileVault whose keys (have to) persist in memory for the duration of the login session, individual encrypted disk images are mounted on demand and their keys destroyed from memory on unmount. TrueCrypt on the other hand uses AES in XTS mode so you get confidentiality and integrity. XTS certainly doesn't provide cryptographic integrity. It provides different ciphertext malleability characteristics than CBC, in that you can only randomize an arbitrary 16-byte block of plaintext instead of being able to flip an arbitrary bit (and screw up the previous block). However, this comes with other costs inherent to seekable narrow-block encryption, so I think it's hard to argue XTS provides more integrity than CBC. Or were you referring to something else? -- Ivan Krstić krs...@solarsail.hcs.harvard.edu | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: FileVault on other than home directories on MacOS?
Steve, On Sep 21, 2009, at 1:57 PM, Steven Bellovin wrote: Is there any way to use FileVault on MacOS except on home directories? FileVault is essentially just the name for a plain encrypted disk image which happens to have some voodoo associated with it to get pivoted in as your homedir at login. This to say, you can make arbitrarily many encrypted disk images with Disk Utility and use them as individual encrypted (non-homedir) folders. If you're asking whether you can turn on encryption for existing system folders, the answer is no; HFS+ itself offers no encryption facilities. I suppose I could install TrueCrypt (other suggestions or comments on TrueVault?), but I prefer to minimize the amount of extra software I have to maintain. TrueCrypt is a fine solution and indeed very helpful if you need cross- platform encrypted volumes; it lets you trivially make an encrypted USB key you can use on Linux, Windows and OS X. If you're *just* talking about OS X, I don't believe TrueCrypt offers any advantages over encrypted disk images unless you're big on conspiracy theories. Cheers, -- Ivan Krstić krs...@solarsail.hcs.harvard.edu | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Bringing Tahoe ideas to HTTP
On Sep 15, 2009, at 4:12 PM, James A. Donald wrote: The ideas used in Tahoe are useful tools that can be used to solve important problems. Yes, and I'd be happy to opine on that as soon as someone told me what those important problems are. -- Ivan Krstić krs...@solarsail.hcs.harvard.edu | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Bringing Tahoe ideas to HTTP
On Aug 27, 2009, at 2:57 PM, Brian Warner wrote: I've no idea how hard it would be to write this sort of plugin. But I'm pretty sure it's feasible, as would be the site-building tools. If firefox had this built-in, and web authors used it, what sorts of vulnerabilities would go away? What sorts of new applications could we build that would take advantage of this kind of security? What you're proposing amounts to a great deal of complex and complicated cryptography. If it were implemented tomorrow, it would take years for the most serious of implementation errors to get weeded out, and some years thereafter for proper interoperability in corner cases. In the meantime, mobile device makers would track you down for the express purpose of breaking into your house at night to pee in your Cheerios, as retaliation for making them explain to their customers why their mobile web browsing is either half the speed it used to be, or not as secure as on the desktop, with no particularly explicable upside. It bugs the hell out of me when smart, technical people spend time and effort devising solutions in search of problems. You need to *start* with the sorts of vulnerabilities you want to do away with, or the kinds of new applications you can build that current security systems don't address, and *then* work your way to solutions that enable those use cases. It's okay to do it in reverse order in the academia, but you seem to be talking about real-world systems. And in real-world systems, you don't get to play Jeopardy with cryptography. Cheers, -- Ivan Krstić krs...@solarsail.hcs.harvard.edu | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: password safes for mac
On Jun 27, 2009, at 6:57 PM, Perry E. Metzger wrote: Does anyone have a recommended encrypted password storage program for the mac? System applications and non-broken 3rd party applications on OS X store credentials in Keychain, which is a system facility for keeping secrets. Your user keychain is encrypted with your login password, and items in it have application-level ACLs (this credential can only be read by these applications). The definition of application for the purpose of Keychain ACLs is derived from OS X code signing, so if someone tampers with one of your apps on disk, the resulting application won't get access to Keychain until you explicitly approve it. You can inspect and modify your keychain with the Keychain Access application, which also allows you to add your own items. -- Ivan Krstić krs...@solarsail.hcs.harvard.edu | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Judge orders defendant to decrypt PGP-protected laptop
On Mar 3, 2009, at 6:38 PM, Perry E. Metzger wrote: So, the court is not going to pay the least attention to your elaborate claims that you just like storing the output of your random number generator on a large chunk of your hard drive. They really don't give a damn about claims like that. Actually they do care. They'll be pissed off that you're wasting their time. You miss the point. Re-read the link I provided that explains how TrueCrypt implements hidden volumes. A hidden TrueCrypt volume is *completely indistinguishable* from empty space in a regular TrueCrypt volume. That's what makes it hidden! As I implied in the 2004 message in the context of political dissidents, a good use for hidden volumes isn't to distract your prosecutor with kittens and sunsets. That's just plain stupid, regardless of whether you're dealing with a US judge or someone whose preferred method of communication involves a pair of pliers and a blowtorch. The idea is to present an alternative but *plausible* set of information that's far less incriminating than the real deal, such as only mildly illegal material or legal material that the owner would still plausibly wish to keep secret for social reasons. I gave you a concrete example: hardcore or fetish porn (legal, but plausibly not the kind of thing whose possession you wish to advertise) provided to investigators to mask a secret volume with kiddie porn. If you give me the benefit of the doubt for having a reasonable general grasp of the legal system and not thinking the judge is an automaton or an idiot, can you explain to me how you think the judge can meet the burden of proof for contempt in this instance? Surely you don't wish to say that anyone using encryption can be held in contempt on the _chance_ they're not divulging all the information; what, then, is the other explanation? -- Ivan Krstić krs...@solarsail.hcs.harvard.edu | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Judge orders defendant to decrypt PGP-protected laptop
On Mar 3, 2009, at 1:08 PM, Adam Fields wrote: Is there any disk encryption software for which this is common practice? In terms of fairly widely used software, yes, TrueCrypt offers hidden volumes: http://www.truecrypt.org/docs/?s=hidden-volume I asked the same original question on this list in 2004, and some other software is mentioned in the replies: http://www.mail-archive.com/cryptography@metzdowd.com/msg02169.html -- Ivan Krstić krs...@solarsail.hcs.harvard.edu | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Judge orders defendant to decrypt PGP-protected laptop
On Mar 3, 2009, at 1:53 PM, Perry E. Metzger wrote: If it is obvious to you and me that a disk has multiple encrypted views, then you can't expect that a court will not be able to understand this and take appropriate action, like putting you in a cage. Why do you think it'd be obvious to you and me that a disk has multiple encrypted views? Contempt carries a burden of proof. If the guy has two encrypted volumes, one with a bunch of hardcore adult porn and the other with a bunch of kiddie porn, how does his unlocking the first one give you a 'preponderance of evidence' that he's obstructing justice or disobeying the court? It becomes a he-said-she-said with the CBP agent, your word against his. -- Ivan Krstić krs...@solarsail.hcs.harvard.edu | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: how to properly secure non-ssl logins (php + ajax)
On Feb 15, 2009, at 7:30 AM, Rene Veerman wrote: Recently, on both the jQuery(.com) and PHP mailinglists, a question has arisen on how to properly secure a login form for a non-ssl web- application. What's the threat model? users[user_id].user_login_hash = onewayHash(user_login_name + preferences.pref_system_hash); That you're hashing the username suggests you're worried about eavesdroppers identifying the user at login time. But without SSL, it'll almost certainly be trivial for an eavesdropper to identify the user _after_ they login. What's the threat model? //checks since when [browser IP] has last received a new challenge, if threshold : make a new challenge. else return old challenge. It is incorrect to rely on a bijection between IPs and users. preferences.pref_system_hash What you're calling a system hash is usually referred to as salt. // walk through all the records in users table, for each, calculate: This is a completely broken approach, and prohibitive for applications with more than a handful of users. I suggest you start by trying to write down a clear, brief and coherent threat model. Once that's done, you can solicit feedback until you're satisfied with the definition of what you're trying to build. Once you can focus on implementation, I suggest looking at things like bcrypt, PBKDF2, and SRP as background reading. Cheers, -- Ivan Krstić krs...@solarsail.hcs.harvard.edu | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Obama's secure PDA
On Jan 29, 2009, at 11:17 PM, Ivan Krstić wrote: I'd find mobile e-mail just as useful if it went through a proxy that stripped out _everything_ that's not plaintext. I open attachments on my phone about once in a blue moon, and wouldn't miss the ability if it were gone. As a postscript, it appears this type of proxy is exactly what's been set up: To minimize the risk, the government technology gurus have made it impossible to forward e-mail messages from the president or to send him attachments, people informed about the precautions say. -- http://www.nytimes.com/2009/02/01/us/politics/01obama.html -- Ivan Krstić krs...@solarsail.hcs.harvard.edu | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Obama's secure PDA
Multiple responses inline: On Jan 26, 2009, at 11:26 AM, Paul Hoffman wrote: I too would like to hear more information on this, particularly the crypto that is known to be used on the Edge. See sections 'Secure Speech Processing' and 'Interoperability' of http://www.gdc4s.com/documents/GD-Sectera_Edge-w.pdf . The standard suites are used, as one would expect. On Jan 26, 2009, at 4:56 PM, Jerry Leichter wrote: The FAQ, indirectly, answers the your previous question of why only Secret for email: Data-at-rest is encrypted using AES, which is only approved for Secret, not Top Secret, data. This isn't the case; AES is approved for Top Secret with 192- or 256- bit keys, per http://www.cnss.gov/Assets/pdf/cnssp_15_fs.pdf. On Jan 26, 2009, at 9:26 PM, Steven M. Bellovin wrote: Quite simply, voice offers one service -- voice. Data offers many services, and hence many venues for data-driven attacks: email (which includes many MIME types) and probably clicking on URLs, web (which includes HMTL, gif, jpeg, perhaps png, and almost certainly Javascript), and perhaps data files including pdf, Word, Powerpoint, and Excel. Any one of those data formats is far more complex than even compressed voice; the union of them makes me surprised it can handle even Secret data... Note especially that HTML involves IFRAMEs and third-party images, which means inherent cross-domain issues. I've thought about this, but I don't buy it. I'm a heavy user of wireless e-mail, but I use it as nothing more than a SMTP-addressable SMS service without a length limit. In other words, people can send me messages from a computer and not just from a mobile handset (true in the other direction, too), and I can read and write more than 160 characters at a time. I'd find mobile e-mail just as useful if it went through a proxy that stripped out _everything_ that's not plaintext. I open attachments on my phone about once in a blue moon, and wouldn't miss the ability if it were gone. Cheers, -- Ivan Krstić krs...@solarsail.hcs.harvard.edu | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
two bits of light holiday reading
1. Jonathan Zittrain's[0] latest book, 'The Future of the Internet and How to Stop It', is available as a free PDF licensed under CC-BY-NC-SA: http://futureoftheinternet.org/static/ZittrainTheFutureoftheInternet.pdf While not dealing with cryptography per se, it does focus on the wider implications of the worsening situation in modern computer security, and what it means for the new computing platforms we're seeing now and in the future. Zittrain is one of the foremost cyberlaw thinkers on the planet; given a number of discussions on this list, I thought the book would be of interest to subscribers. [0] http://en.wikipedia.org/wiki/Jonathan_Zittrain 2. The DC-based Center for Strategic and International Studies recently released a report titled 'Securing Cyberspace for the 44th Presidency' written by a number of influential authors: http://www.csis.org/media/csis/pubs/081208_securingcyberspace_44.pdf Of most interest to this list, the report suggests going on the offensive with regard to identity management, proposing to restrict bonuses and awards of US federal agencies not using strong digital credentials for employees in sufficient numbers (logical pp. 61-65). Maybe, uh, it'll work this time around? Cheers, -- Ivan Krstić krs...@solarsail.hcs.harvard.edu | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: e-gold and e-go1d
On Nov 29, 2008, at 9:18 AM, James A. Donald wrote: The algorithm is to map all lookalike glyphs to canonical glyphs The definition of lookalike glyphs depends on the choice of font and variant, and Unicode wraps the whole problem in a lovely layer of hell. If I had to do this, I'd investigate rendering both strings in the (same) target font and then quantifying the amount of overlap in the bitmaps, as e.g. SWORD does for TLDs: http://icann.sword-group.com/icann-algorithm/Default.aspx The above is proprietary; NIST's Paul Black has Python code available for a slightly enhanced Levenshtein distance: http://hissa.nist.gov/~black/GTLD/ -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Judge approves TRO to stop DEFCON presentation
On Sat, 09 Aug 2008 17:11:11 -0400, Perry E. Metzger [EMAIL PROTECTED] wrote: Las Vegas - Three students at the Massachusetts Institute of Technology (MIT) were ordered this morning by a federal court judge to cancel their scheduled presentation about vulnerabilities in Boston's transit fare payment system, violating their First Amendment right to discuss their important research. http://www-tech.mit.edu/V128/N30/subway/Defcon_Presentation.pdf -- Ivan Krsti? [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: On the randomness of DNS
On Jul 30, 2008, at 1:56 PM, Ben Laurie wrote: Oh, and I should say that number of ports and standard deviation are not a GREAT way to test for randomness. For example, the sequence 1000, 2000, ..., 27000 has 27 ports and a standard deviation of over 7500, which looks pretty GREAT to me. But not very random. I boggled a bit at the abuse of simple descriptive statistics, too. For those interested in actual statistical tests of randomness, there's a good literature survey at http://www.ciphersbyritter.com/RES/RANDTEST.HTM . -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The wisdom of the ill informed
On Jul 1, 2008, at 12:46 PM, Perry E. Metzger wrote: My experience with European banks is quite limited -- my consulting practice is pretty much US centric. My general understanding, however, is that they are doing better, not worse, with login security. As a data point, the largest bank in Croatia used to mail customers pre-printed TAN lists. Some number of years ago, they switched to (non- SecurID) tokens which require a 4-digit PIN to turn on, and then provide two functions: a login OTP and a challenge/response system for authorizing individual transactions. Your username is simply the token's serial number, though it's not clear if these are in fact serial. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The wisdom of the ill informed
On Jun 30, 2008, at 7:22 PM, Perry E. Metzger wrote: One of the most interesting things I find about most fields is the fact that people who are incompetent very often fancy themselves experts. There's a great study on this subject -- usually the least competent people are the ones that feel highly confident in their skills, while the people who aren't have more doubts. One sees this very phenomenon on this very list, and not infrequently. Indeed: http://en.wikipedia.org/wiki/Lake_Wobegon_effect http://en.wikipedia.org/wiki/Dunning-Kruger_effect How security non-experts screwed up security in systems like WEP and PPTP is no mystery to me. How, on the other hand, a real expert at _anything_ feels comfortable entering another hard technical field without screaming for assistance is something I don't get at all. That a roomful of network experts designing 802.11 didn't hold hands and all together chant bring us a good cryptographer with such maniacal monophony as to rival any Gregorian choir makes me highly suspicious about their supposed expertise with _networks_. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A call for aid in cracking a 1024-bit malware key
On Jun 11, 2008, at 10:04 PM, Steven M. Bellovin wrote: Let's put it like this: suppose you wanted to use all of your cryptographic skills to do such a thing. Do you think it could be cracked? I don't... Exactly right. After Storm, I don't think anyone reasonable still believes that there's no talent in the black hat community. So even if this particular piece of malware has implementation issues, the next version won't. And then what? Focusing on the crypto is just missing the point entirely, although I suppose it grabs headlines. But the problem at hand has nothing to do with crypto, and everything to do with the fact that our desktop security systems are fundamentally broken[0]. There is _no_ _reason_ that a piece of malware executing silently in the background should have access to the user's files without interaction or approval from the user. And you can't maliciously encrypt files you can't access. We know how to build systems that are both drastically more secure and more usable than the ones in use today[1]. I wonder if a proliferation of headline-grabbing threats like cryptographic ransomware will help overcome the OS vendor inertia. [0] See first half of http://radian.org/~krstic/talks/2007/auscert/slides.pdf . Note: I'm no longer affiliated with OLPC. [1] E.g. http://en.wikipedia.org/wiki/CapDesk, http://en.wikipedia.org/wiki/Polaris_(computer_security) , http://en.wikipedia.org/wiki/Bitfrost -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Protection mail at rest
On Jun 1, 2008, at 12:07 AM, Victor Duchovni wrote: Not much demand for this yet, so I don't expect mature offerings any time soon. We'd have to build a boutique service for cipher-punks. I doubt there'll ever be much demand. The tinfoil hat crowd will be bothered by the n-1 hops (and however many Narus boxes in between) being traversed unencrypted, while most everyone else seemingly doesn't care and uses GMail/Hotmail/YahooMail, forfeiting any expectation of privacy right from the start. The easiest thing for people who _do_ care is still running their own mail server. The emergence of reasonably priced VM hosting providers (e.g. slicehost.com) makes it fairly uncomplicated, modulo initial setup. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The perils of security tools
On May 25, 2008, at 6:02 AM, Ben Laurie wrote: I meant: how good are the PRNGs underneath them? Not a direct answer to your question, but somewhat relevant as context is Michal Zalewski's analysis of TCP/IP sequence number predictability across operating systems: http://lcamtuf.coredump.cx/newtcp/ It's several years out of date, however. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
New result in predicate encryption: disjunction support
This is fairly interesting: AFAIK the first generalization of predicate encryption to support disjunctions. I find the result mostly interesting mathematically, since I expect we won't be seeing predicate encryption in widespread use anytime soon due to complexity and regulatory concerns. --IK Predicate Encryption Supporting Disjunctions, Polynomial Equations, and Inner Products Jonathan Katz and Amit Sahai and Brent Waters Preprint: http://eprint.iacr.org/2007/404 Abstract: Predicate encryption is a new paradigm generalizing, among other things, identity-based encryption. In a predicate encryption scheme, secret keys correspond to predicates and ciphertexts are associated with attributes; the secret key SK_f corresponding to the predicate f can be used to decrypt a ciphertext associated with attribute I if and only if f(I)=1. Constructions of such schemes are currently known for relatively few classes of predicates. We construct such a scheme for predicates corresponding to the evaluation of inner products over N (for some large integer N). This, in turn, enables constructions in which predicates correspond to the evaluation of disjunctions, polynomials, CNF/DNF formulae, or threshold predicates (among others). Besides serving as what we feel is a significant step forward in the theory of predicate encryption, our results lead to a number of applications that are interesting in their own right. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: defending against evil in all layers of hardware and software
On Apr 28, 2008, at 2:56 PM, Perry E. Metzger wrote: I'm pretty sure we can defend against this sort of thing a lot of the time (by no means all) if it is done by quite ordinary criminals. If it is done by really good people, I have very serious doubts. I think you just described all of security. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: defending against evil in all layers of hardware and software
On Apr 28, 2008, at 12:58 PM, John Denker wrote: Of course we should insist on an open-source boot ROM code: The boot ROM should check the pgp signature of each PCI card's BIOS code before letting it get control. And then it should check the pgp signature of the operating system before booting it. I don't know of any machine that actually does this The OLPC XO-1 laptop has an open-source bootloader (Open Firmware) which checks the operating system signature before passing control to it. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Designing and implementing malicious hardware
On Apr 25, 2008, at 11:09 AM, Leichter, Jerry wrote: I remember seeing another, similar contest in which the goal was to produce a vote-counting program that looked completely correct, but biased the results. The winner was amazingly good - I consider myself pretty good at analyzing code, but even knowing that this code had a hook in it, I missed it completely. Worse, none of the code even set of my why is it doing *that* detector. I was reminded of the same contest[0]. The winning date-agnostic entry[1] was by Michał Zalewski[2], and is nothing short of evil. I spotted the problem after staring at the code intensely for about a half hour, knowing in advance it was there. Had I not known, I don't think I'd have found it. [0] http://graphics.stanford.edu/~danielrh/vote/vote.html [1] http://graphics.stanford.edu/~danielrh/vote/mzalewski.c [2] http://en.wikipedia.org/wiki/Micha%C5%82_Zalewski -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [p2p-hackers] convergent encryption reconsidered -- salting and key-strengthening
On Mar 30, 2008, at 9:37 PM, zooko wrote: You can store your True Name, credit card number, bank account number, mother's maiden name, and so forth, on the same server as your password, but you don't have to worry about using salts or key strengthening on those latter secrets, because the server doesn't run a service that allows unauthenticated remote people to connect, submit a guess as to their value, and receive confirmation, the way it does for your password. Tahoe doesn't run this service either. I can't use it to make guesses at any of the values you mentioned. I can use it to make guesses at whole documents incorporating such values, which is in most cases a highly non-trivial distinction. To make such guesses, I need to account for at least: - file formats, since an e-mail message has a different on-disk representation depending on the recipient's e-mail client, - temporal and transport variance, as PDF documents generally incorporate a generation timestamp, and e-mail messages include routing headers (with timestamps!), - document modifications due to variables other than the one(s) being guessed, e.g. names, e-mail addresses, customized unsubscribe links. I would be interested to see an actual real-world example of how a document would fall to this attack. It strikes me as a cute threat in theory, but uninteresting in practice. *** Convergent encryption exposes whatever data is put into it to the sorts of attacks that already apply to passwords. Sometimes, under highly peculiar circumstances, etc. Convergent encryption had been invented, analyzed and used for many years, but to the best of my knowledge the first time that anyone noticed this issue was March 16 of this year FWIW, I have discussed this threat verbally with colleagues when I was asked for possible designs for OLPC's server-based automatic backup system. I dismissed it at the time as 'not a real-world concern'. I might even have it in my notes, but those weren't published, so it's moot. Now PBKDF2 is a combination of the first two defenses -- salting and key strengthening. When you first suggested PBKDF2, I -- and apparently Jerry Leichter -- thought that you were suggesting its salting feature as a solution. Yeah, sorry, I wasn't being clear. I should've just said a key strengthening function rather than naming anything in particular. This would have a performance impact on normal everyday use of Tahoe without, in my current estimation, making a brute-force/dictionary attack infeasible. Adding, say, 5 seconds of computation to the time it takes to store a file is likely to be lost as noise in comparison with the actual network upload time, while still making an attacker's life _dramatically_ harder than now. The trade-off is actually worse than it appears since the attacker is attacking multiple users at once (in traditional convergent encryption, he is attacking *all* users at once) Again, is there a real-world example of the kind of data or documents that would show this to be a serious problem? While it's technically true that you're targeting all the users in parallel when brute forcing, note that if you're not actually hyper-targeting your attack, you need to brute force _all_ the variables I mention above in parallel, except in pathological cases -- and those, if you know of some, would be interesting for the discussion. economy of scale, and can profitably invest in specialized tools, even specialized hardware such as a COPACOBANA [1]. The OpenBSD eksblowfish/bcrypt design can't be bitsliced and generally doesn't lend itself well to large speedups in hardware, by design. Cheers, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [p2p-hackers] convergent encryption reconsidered
On Mar 31, 2008, at 6:44 AM, James A. Donald wrote: Better still, have a limited supply of tickets that enable one to construct the convergence key. Enough tickets for all normal usage, but not enough to perform an exhaustive search. [...] If you give the ticket issuing computers an elliptic point P, they will give you the corresponding elliptic point k*P. If, however, you ask for too many such points, they will stop responding. This isn't a good design. It's incompatible with Tahoe's present architecture, introduces a single point of failure, centralizes the otherwise by-design decentralized filesystem, and presents a simple way to mount denial of service attacks. Finally, since the decentralization in Tahoe is part of its security design (storage servers aren't trusted), you run into the usual quis custodiet ipsos custodes problem with the ticket-issuing server that the present system nicely avoids. Cheers, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: presentations about encrypted storage
On Mar 28, 2008, at 5:48 PM, [EMAIL PROTECTED] wrote: I've got two presentations I've given on encrypted storage technologies On a similar note, list readers might enjoy the detailed writeup of Tahoe, the secure distributed erasure-coded filesystem built by Zooko and the folks at allmydata.org: http://allmydata.org/~warner/pycon-tahoe.html Perry forwarded the Tahoe 0.9 announcement to the list, but it didn't include a link to this writeup, which might not have existed at the time. As an unrelated bonus and since it doesn't merit a separate post, here's a (well-sung!) crypto take on Harry Belafonte's Banana Boat Song: http://www.catonmat.net/blog/musical-geek-friday-crypto/ Cheers, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [p2p-hackers] convergent encryption reconsidered
On Mar 20, 2008, at 3:42 PM, zooko wrote: They extended the confirmation-of-a-file attack into the learn-partial-information attack. In this new attack, the attacker learns some information from the file. This is done by trying possible values for unknown parts of a file and then checking whether the result matches the observed ciphertext. How is this conceptually different from classic dictionary attacks, and why does e.g. running the file through PBKDF2 and using the result for convergence not address your concern(s)? -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [p2p-hackers] convergent encryption reconsidered
On Mar 30, 2008, at 3:12 PM, Leichter, Jerry wrote: How would that help? Unless I'm misunderstanding Zooko's writeup, he's worried about an attacker going from a partially-known plaintext (e.g. a form bank letter) to a completely-known plaintext by repeating the following process: 1. take partially known plaintext 2. make a guess, randomly or more intelligently where possible, about the unknown parts 3. take the current integrated partial+guessed plaintext, hash to obtain convergence key 4. verify whether that key exists in the storage index 5. if yes, you've found the full plaintext. if not, repeat from '2'. That's a brute force search. If your convergence key, instead of being a simple file hash, is obtained through a deterministic but computationally expensive function such as PBKDF2 (or the OpenBSD bcrypt, etc), then step 3 makes an exhaustive search prohibitive in most cases while not interfering with normal filesystem operation. What am I missing? Cheers, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
On Feb 21, 2008, at 6:40 PM, Ali, Saqib wrote: i think in most cases tamper-resistant is sufficient Er, what do TPMs have to do with this at all? TPMs are not tamper- proof hardware FDE devices. They're somewhat tamper-proof (in practice, I wouldn't depend on it) non-volatile storage for small amounts of sensitive data, such as encryption keys. But as long as it's software that's driving your FD encryption, you need to have your keys in RAM. So, either: * The TPM is used in 'basic' mode, where its only purpose is to provide a measure of tamper-resistance to the boot path, and as long as no boot-time tampering is detected, the FDE key will be loaded into RAM automatically, or, * The TPM requires explicit authentication (e.g. by password or smart card) before releasing the key, in which case a successful authentication will load the FDE key in RAM. If the machine is running and the FDE in use -- which is the entire premise behind this attack -- both TPM use cases are just as vulnerable. TPMs are a red herring in this discussion, unless the FDE was actually offloading the crypto operations to it. This is not a supported mode of operation for any widely-deployed FDE system that I'm familiar with. So, is anyone else as amused as I am that Apple can release an EFI firmware update to zeroize MacBook Air memory at boot-time, turning the heretofore widely-decried inability to upgrade that laptop's RAM -- due to the chips being soldered to the motherboard -- into an advantage, and making the Air the laptop of choice for discriminating, fashion-aware, security-conscious professionals the world over? -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
On Feb 1, 2008, at 9:34 PM, Ian G wrote: * Browser vendors don't employ security people as we know them on this mailgroup [...] But they are completely at sea when it comes to systemic security failings or designing new systems. I don't know about other browsers, but Mozilla's CSO-type is Window Snyder who I'd easily describe as a pretty top-notch security person. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
On Jan 31, 2008, at 10:32 PM, Richard Salz wrote: Developers working in almost any field should know the history and best practices -- is PGP's original bass o matic any more important than the code in a defibrillator? -- but this is not the way our field works right now. Compare it to something like civil engineering or architecture. I think this misses the point. Security is different. In 2008, I can learn to build pretty good suspension bridges by learning the state of the art of bridge-building. After that, as long as I live, I run almost no risk of Newtonian mechanics being shown to be wrong for any value of wrong that would make me go well, wow, I no longer understand how to build bridges. In other words, people who build bridges these days can give you a convincing presentation, based on solid physics and a highly-complete threat model (soil erosion, material failure, etc) that their bridge will do its job. They can say this bridge will work because it satisfies well-understood and reasonably immutable laws of nature. People who attempt to build secure systems have no ultimately well- understood (let alone immutable!) requirements to design against. A good approximation is a secure system is one that survives all relevant attacks that people in our field have come up with thus far, but it's clear that a system successfully meeting that goal can simply cease to meet it any given day. Thus unlike with bridges, you fundamentally can't evaluate the quality of a security system you built if you're unfamiliar with the state of the art of _attacks_ against security systems, and you can't become familiar with those unless you realize that these attacks have each brought down a system previously considered impregnable. And if by the time you've gone through dozens of broken systems and their corresponding attacks you still think you're smart enough to write a new system by yourself, you're either very brave or very daft. Neither of those mean you're a bad person, but both mean you shouldn't be designing security systems. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
On Jan 31, 2008, at 4:07 PM, Guus Sliepen wrote: I hope that in the future, if you see an application doing something wrong, you don't immediately give the developers the soundwave therapy. The wider point of Peter's writeup -- and of the therapy -- is that developers working on security tools should _know_ they're working in a notoriously, infamously hard field where the odds are _overwhelmingly_ against them if they choose to engineer new solutions. With such understanding, no competent developer should ever set out to build new cryptosystems unless he can explain, point by point, why his needs cannot be met by existing, vetted systems. That explanation should ideally be made public for dissection by the community. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
On Jan 25, 2008, at 4:27 PM, Perry E. Metzger wrote: However, you should be very skeptical when someone claims that they need to use a home grown crypto algorithm or that they need to use a home grown protocol instead of a well proven one. I'm beginning to suspect that more often than not, this nonsense is a result of market forces rather than idiot technologists. In my experience, senior decision-maker types outside of the computer industry (and even within it, but perhaps a tad less so) are sufficiently non-technical as to never have heard of Kerckhoffs' principle -- and to disbelieve it when they do, since it opposes their intuition of what makes for secure systems. Various companies (or departments) then emerge peddling their home-grown crypto and trumpeting the fact that it's proprietary as a feature, commonly going hand in hand with stupidly large key sizes. Some number of these muppets approached me over the last couple of years offering to donate a free license for their excellent products. I used to be more polite about it, but nowadays I ask that they Google the famous Gutmann Sound Wave Therapy[0] and mail me afterwards. I've never heard back. [0] Last paragraph, http://diswww.mit.edu/bloom-picayune/crypto/14238 -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Question on export issues
On Jan 3, 2008, at 10:47 PM, Peter Gutmann wrote: That's because there's nothing much to publish: In the US, notify the BIS via email. Our outside counsel -- specializing in this area -- thought this was insufficient. That said, thanks for all the feedback in the thread -- I'll pass the information back and try to figure out what the difficulties were, posting here if anything interesting becomes illuminated. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Death of antivirus software imminent
On Dec 31, 2007, at 4:46 PM, Bill Frantz wrote: My favorite virtual machine use is for the virus to install itself as a virtual machine, and run the OS in the virtual machine. This technique should be really good for hiding from virus scanners. It's not, and despite the press handwaving about hypervisor rootkits being the death of all security as we know it, this attack is largely uninteresting in practice. Repeat after me: it's not a real problem, and it's unlikely to become a real problem. A walkthrough with pretty pictures, courtesy of the Matasano folk: http://www.matasano.com/log/930/side-channel-detection-attacks-against-unauthorized-hypervisors/ Cheers, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Question on export issues
On Dec 30, 2007, at 12:06 AM, [EMAIL PROTECTED] wrote: never be permitted to export to the embargoed country list (Cuba, Iran, Sudan, Syria, North Korea, and Libya). Not Libya. See 15 C.F.R §740Spir[0], country group E: Cuba, Iran, North Korea, Sudan, Syria. Interestingly, 15 C.F.R. §746.8[1] also lists Rwanda: an embargo applies to the sale or supply to Rwanda of arms and related matériel of all types and regardless of origin, including weapons and ammunition. I am not a lawyer, and cannot tell whether this applies to encryption. We've recently had to jump through the BIS crypto export hoops at OLPC. Our systems both ship with crypto built-in and, due to their Fedora underpinnings, allow end-user installation of various crypto libraries -- all open-source -- through our servers. It was a nightmare; the regulations and paperwork appear to be designed for the use case of individual applications that utilize a handful of primitives and attempt to keep the user from examining or modifying the utilized crypto. Trying to fit a Linux distribution into this model proved, er, challenging. (We also found that projects that we expected would know the drill cold, such as Fedora and Mozilla, were actually not very familiar with the processes involved.) Cheers, Ivan. [0] http://www.access.gpo.gov/bis/ear/pdf/740spir.pdf [1] http://www.access.gpo.gov/bis/ear/pdf/746.pdf -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Death of antivirus software imminent
On Dec 29, 2007, at 6:37 PM, Anne Lynn Wheeler wrote: Virtualization still hot, death of antivirus software imminent My, that sounds awfully familiar: http://radian.org/~krstic/talks/2007/auscert/slides.pdf I note that, come the January OLPC software update, I will be using my XO laptop for all my e-banking and related needs. It provides a drastically more secure platform for doing so than any mainstream computer I know exists. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Seagate announces hardware FDE for laptop and desktop machines
On Oct 3, 2007, at 4:39 AM, Florian Weimer wrote: But this exhibits an issue with disk-based encryption: you can't really know what they are doing, and if they are doing it right. (Given countless examples of badly-deployed cryptography, this isn't just paranoia, but a real concern.) Precisely. If you're keeping secrets from your nosy siblings and coworkers, hardware FDE is more than adequate. If you have reason to believe someone skilled and resourceful might really want your data, you almost certainly have no business using a blackbox encryption system operating in a way that's not publicly documented -- even if the system is buzzword-compliant -- and implemented by a company (hard disk vendor) where crypto is about as far from their core competency as you can get. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
On Sep 19, 2007, at 5:01 PM, Nash Foster wrote: Any actual cryptographers care to comment on this? I don't feel qualified to judge. If the affected software is doing DH with a malicious/compromised peer, the peer can make it arrive at a predictable secret -- which would be known to some passive listener. But hey, if the peer is malicious or compromised to begin with, it could just as well do DH normally and explicitly send the secret to the listener when it's done. Not much to see here. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: using SRAM state as a source of randomness
On Sep 12, 2007, at 7:06 AM, Udhay Shankar N wrote: Sounds like an interesting idea - using SRAM state as a source of randomness. Any of the folks here willing to comment on this? If you care about your randomness, you don't want to be making the assumption that a source is random because it sometimes looks that way, sort of. You want to be using a source that's assumed random because, as far as you know, it's very hard for it to be any other way. Clearly, SRAM state falls into the former category, and there are lots and lots of variables keeping it firmly outside the latter. This means the usual wisdom applies: if you really need the extra entropy, mix some of these SRAM state bits into your pool, but make sure you're also feeding the pool from at least one source about whose randomness you can reason strongly. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: MC Frontalot sings about encryption
On Sep 14, 2007, at 8:36 PM, Perry E. Metzger wrote: Secrets From The Future, MC Frontalot's song about crypto Lyrics: http://frontalot.com/index.php/?page=lyricslyricid=41 -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New DoD encryption mandate
On Aug 18, 2007, at 3:30 PM, Ali, Saqib wrote: One of the functions provided by the TPM is to wrap/bind and store the bulk encryption keys. Now let's us say the mother board or the TPM goes bad on your notebook or you simply want to upgrade the computer. You need to be able to restore+transfer the information stored in the TPM to your new computer. This is where you need TPM management suite that support key backup/restore and transfer. I still don't follow. BitLocker explicitly includes a (optionally file-based) recovery password. If you want central management, why not centrally manage _that_? Alex Alten wrote: Agreed, for most requirements. Sometimes one may need to keep keys in trusted hardware only. The reason the TPM is used to wrap the BitLocker key is not because people don't want the key to be available outside of hardware -- at least I've never heard of that requirement going hand in hand with central key backup/migrate. Instead, TPM key wrapping is used so the early-boot checks can be enforced. I don't see how a hardware-only key that you can migrate to another TPM centrally is any more secure than keeping a key in hardware but falling back on a centrally- managed spare for enabling data migration. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New DoD encryption mandate
On Aug 19, 2007, at 12:13 PM, Ali, Saqib wrote: On if MS provided some way to manage them centrally. Using a encrypted DB to manually store the keys in it, is simply not feasible. Your argument just went from TPMs are bad for volume encryption with BitLocker because they can't be centrally managed to Microsoft should provide tools to centrally manage key recovery files because I find doing it myself too hard. Which are you actually arguing? I've tried to show you that the first argument is _wrong_; the second argument has nothing to do with TPMs. You have a choice when it comes to how you approach the recovery keyfile problem. You can build tools for it, or any company that perceives a market need can do so. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New DoD encryption mandate
On Aug 16, 2007, at 8:30 AM, Ali, Saqib wrote: The other problem is that it lacks any centralized management. If you are letting TPM manage your Bitlocker keys you still need a TPM management suite with key backup/restore/transfer/migrate capabilities in case your computer goes bad. How so? If your computer goes bad, you need a *backup*. That's entirely orthogonal to the drive encryption problem. Bitlocker uses the TPM to provide assurance that your drive -- really, volume -- is locked to your computer, and that the early boot environment hasn't been messed with. When either check fails, you use the BitLocker recovery password (either on a USB stick or entered manually) to recover your data. This holds in the event that you take your drive out and stick it in a different machine. In other words, the TPM is not a single point of failure, so I don't understand why you think you care about TPM backup/restore/transfer. The third problem is that it is software based encryption, which uses the main CPU to perform the encryption. Security is never free, but in 2007, we can afford the cycles. What's a better use for them? Drawing semi-transparent stained glass window borders? -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: improving ssh
On Jul 14, 2007, at 2:43 PM, Ed Gerck wrote: 1. firewall port-knocking to block scanning and attacks 2. firewall logging and IP disabling for repeated attacks (prevent DoS, block dictionary attacks) 3. pre- and post-filtering to prevent SSH from advertising itself and server OS 4. block empty authentication requests 5. block sending host key fingerprint for invalid or no username 6. drop SSH reply (send no response) for invalid or no username None of these are crypto issues. The OpenSSH dev list (http:// www.openssh.com/list.html) would almost certainly lend itself to a more productive discussion of these concerns. Cheers, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
On Jun 29, 2007, at 10:44 AM, Steven M. Bellovin wrote: It's very valid to criticize today's products, and it's almost obligatory to criticize over-hyped marketing. As I said, I don't think today's products are useful anywhere, and the comparisons vendors draw to conventional cryptography are at best misleading. But let's not throw the baby out with the bathwater. The problem I have with QC is that, as others have amply pointed out, there is a lot of bathwater but not much of a baby to speak of. If someone created a protocol that does a DH exchange at the beginning and then throws away the secret and performs the rest of the communication in plaintext, we'd hardly call the resulting system a cryptographic protocol. Really, we'd be hesitant to use any form of the word cryptography in the description. QC, however, does something exactly analogous: it performs a quantum key exchange and then falls back on classical primitives. It's at best confusing, fallacious and disingenuous to refer to such setups as quantum cryptography, though I understand classical encryption with quantum key exchange has less of a marketable ring to it. So, by all means, let the QKD and related research continue. It's interesting, it's cool, it's *important* work. But when the folks behind it are talking to those of us who understand and work with cryptography every day, they need to do a much better job at not letting their own imprecise and almost deceitful terminology paint themselves in a corner and trigger our snakeoil detectors. I deeply support Jon's proposal of renaming the whole thing quantum secrecy, in which case I'd get off my snark horse and show more respect for the whole thing. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Blackberries insecure?
[Perry -- I have no connection to Nokia whatsoever and am thrilled with the phone in question, but the message below sounds like an advertisement so please reject from the list if inappropriate.] [Moderator's note: this is off topic, but there were a couple of what is that phone messages to the list so clearly enough readers want to know where to get a phone that runs real ssl and ssh. No followups, please -- the list has been off topic enough lately already. --Perry] James A. Donald wrote: What is your phone's model number? Nokia E61i, an update of the E61: http://europe.nokia.com/A4344018 http://www.nokiausa.com/phones/E61i It's not available directly from service providers in the states who only sell the E62, which is a crippled E61. It has wifi, Bluetooth, takes additional microSD storage, exposes its drive (and SD card) as a standard USB hard drive, has a decent music player and built-in zooming web browser, runs Acrobat reader and Opera, can sync with Google calendar with a third party program, runs putty as an ssh client, supports viewing Office documents and has all the other features you'd expect from a business phone (e.g. timed profiles and phone ACLs -- instead of turning off or muting your phone at night, you can, for instance, specify that only certain people can call you.) -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free Rootkit with Every New Intel Machine
Peter Gutmann wrote: I've seen all sorts of *claims* of TPM support, but try going out and buying a PC with one Of the 25 business laptop models that HP offers on its site right now, only 5 don't have a TPM installed. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Blackberries insecure?
Steven M. Bellovin wrote: That's a bit puzzling. My understanding is that email is encrypted from the organization's (Exchange?) server to the receiving Blackberry, and that it's not in the clear while in transit or on RIM's servers. Doesn't this run into the common problem of supposedly it's secure, but they're not offering the source, just like with e.g. Skype, TPM RNGs, all commercial hardware security modules that I'm aware of, etc? Personally, I found a SymbianOS phone with a full keyboard that's lighter, thinner and more stylish than the Blackberry, runs Python and exposes most of the phone functionality to it through a set of APIs, and is happy to grab my mail via IMAP+SSL. With an unlimited data plan, who cares if it's pull instead of push e-mail? -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free Rootkit with Every New Intel Machine
Peter Gutmann wrote: [...] a register article saying Intel released its new platform Centrino Pro which includes Intel Active Management 2.5. An article with some more info is here: It appears Active Management is a setting that can be disabled normally from the BIOS, like with TPMs today: http://support.intel.com/support/motherboards/desktop/sb/cs-020837.htm I couldn't find a conclusive statement one way or the other, but I expect it'll also be turned off by default for consumer machines. That still leaves a slew of open questions, but makes it less initially alarming, I'd say. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
Anne Lynn Wheeler wrote: it would be really great to make it an excuse to move away from offline paradigm to real online operation ... getting totally rid of the need for domain name certificates ... DNS serving up both ip-addresses and public keys in single operation. That can't happen until we make sure you can trust DNS, which in turn can't happen until we get a concrete proposal that has clearly defined goals and isn't braindead. As has been amply pointed out, it's not clear that DNSSEC will cut it anytime soon. (These days, the complaints even come with illustrations: http://www.matasano.com/log/772/a-case-against-dnssec-count-2-too-complicated-to-deploy/). -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Russian cyberwar against Estonia?
Bill Stewart wrote: - Some teenage hacker who got annoyed at some other teenage hacker because they got into an argument on WoW or Myspace and decided to DDOS him Some years back, I was on the receiving end of this type of scenario bringing down connectivity for a small European country, and it was a larger one than Estonia. Out of curiosity, does anyone have information on how fat Estonia's external pipes are? -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 0wned .gov machines (was Re: Russian cyberwar against Estonia?)
Perry E. Metzger wrote: What is interesting to me is that, even though things have nearly gotten as bad as they could possibly get, we still have seen very little real effort made to improve systems security (at least in comparison with what is necessary to make a big dent). I think it's anything but surprising. There's only so much you can do to significantly improve systems security if you're unwilling to break backwards compatibility -- many of the fundamental premises of desktop security are fatally flawed, chief among them the idea that all programs execute with the full privileges of the executing user. One Laptop per Child is breaking application backwards compatibility for a number of reasons, one of which is security. As a result, I'm earnestly hoping that our systems security platform, Bitfrost[0], will be an improvement on the scale you're talking about. But time will tell. (Sidenote: I'm giving a keynote at AusCERT tomorrow about exactly this, titled 'Everything you know about desktop security is wrong, or: How I Learned to Stop Worrying and Love the Virtual Machine'. Any list members who are at the conference should mail me if they want to play with an OLPC laptop and commiserate about desktop security over beer.) [0] Summary at http://wiki.laptop.org/go/Bitfrost with full spec at http://wiki.laptop.org/go/OLPC_Bitfrost -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More info in my AES128-CBC question
Aram Perez wrote: The proposal for using AES128-CBC with a fixed IV of all zeros is for a protocol between two entities that will be exchanging messages. This is being done in a standards body (OMA) and many of the attendees have very little security experience. We don't let a bunch of random people design airbags. How on earth is it a good idea to let a random bunch of people design crypto protocols? Is this the same bunch of people that will be shocked, just SHOCKED when someone demonstrates that their design is idiotic and doesn't protect anyone or anything? No, really, that people with very little security experience feel comfortable doing this kind of work just boggles my mind. Please congratulate everyone involved, and remind them to always use their PPTP VPN over their WEP-protected wireless. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Failure of PKI in messaging
Ian G wrote: Actually, there are many problems. If you ask the low-level crypto guys, they say that the HI is the problem. If you ask the HI guys, they say that the PKI concept is the problem. If you ask the PKI people, they say the users are not playing the game, and if you ask the users they say the deployment is broken ... Everyone has got someone else to blame. This is, in my experience, exactly right. I'm trying to take some steps for the better on the OLPC: all e-mails and IMs will be signed transparently and by default, with the possibility of being encrypted by default in countries where it's not a problem. This'll help with privacy and message integrity, but it's not designed to stop phishing or impersonation. Phishing is less of an immediate problem for us, as there's little incentive to phish 6-year olds in developing countries. But it will be a problem eventually, and by then, it might be extremely difficult to introduce sweeping changes in the security and HCI model to remedy the problem. One tremendous advantage we have now with OLPC is the ability to ignore backwards compatibility for a number of things, so if we had a really good model for dealing with phishing and the like -- even if it required new assumptions or approaches -- we could probably do it. So maybe it's time (for us, perhaps) to organize a workshop on this? Is there a better way to do it? -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: One Laptop per Child security
Steven M. Bellovin wrote: What about unprotected, frequently-running web browsers? I don't follow. How do you hop from one browser to another, if you want to use one as your spread vector? Browsers don't accept inbound connections. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: One Laptop per Child security
Peter Gutmann wrote: Just a general thought, it seems like the OLPC security design is a real-world implementation of Bill Cheswick's Windows OK proposal. See for example http://usablesecurity.com/2005/07/07/bill-cheswick/ for more on this (modulo the comments on feature starvation, which don't apply to the OLPC design). The systems are similar in their desire to offer no-frills protection, but I think the similarities end there. If I had been trying to simply lock the machines down, as is the essence of Cheswick's proposal, my task would have been extremely simple. The resulting security model would also have gone against everything OLPC's educational principles stand for. I think you'll find that moving (even mentally) from protection by not running untrusted code to usable protection _while_ running untrusted code involves a few trips through a labyrinth sitting on top of a mine field, with the exit guarded by a killer rabbit. It's also certainly possible I'm not smart enough, and other people find this to be an easier problem. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: One Laptop per Child security
Hi, Steve. Thanks for your thoughts; comments inline. Steven M. Bellovin wrote: That firewalls should be omitted is no surprise. A firewall is a device for centralized policy enforcement; it's useful when policy to the outside -- whatever that is -- is different than policy for the inside. If you don't have a well-defined inside and outside, they're not very useful. The no firewalls thing is really a journalistic misrepresentation. There are no *personal* firewalls, in the keep-popping-up-messages-and-prompts sense. P_NET filtering, described in the spec, is implemented exactly by using a firewall -- standard Linux netfilter. Because each program executes in a VM of its own, enforcing network access policies on it becomes very simple: it's a matter of choosing to NAT or not NAT packets from/to its virtual IP, with any applicable restrictions. But it's no longer something the user has to know or care about, which has been one of my fanatical focuses in designing Bitfrost. I firmly believe this is how most security systems should be designed regardless of the target audience, but with 6 year olds in the mix, it's no longer a belief or convenience, it's an absolute necessity. Even if the crypto authentication succeeds, all it means is that some process on the other machine has access to the credentials; it says nothing about whether or not the human in front of that machine wants to connect. Is this a general comment, or are you talking about some particular crypto authentication on the OLPC? It would take a fairly radical OS design to prevent a user-level worm from spreading. Is it really a big deal if a worm spreads to every OLPC laptop, but can't do anything particularly malicious once it's there? Thought experiment: explain what OS facilities would have prevented the 1988 Internet worm from succeeding. If you said spreading, I'd have a different answer. But let's talk about the worm succeeding. It succeeded in bringing down the Internet because it -- accidentally, from what we know -- kept creating running copies even on previously infected machines. Eventually there were too many processes, and the machines buckled under the DoS. The Morris worm amounted to a self-propagating forkbomb. Bitfrost would keep the Morris worm from succeeding in any interesting sense. Assuming the worm managed to spread despite the other protections, once it landed on a user's machine and the processes started multiplying, they'd just get throttled back -- to no more than 10% CPU use -- for the combined lot of them -- if the user doesn't have the worm's window in the foreground of the UI. (What window? Exactly.) Decoupling user permissions from process permissions and integrating explicit assent into dealing with the user's documents get you a long, long way towards a usable and reasonably secure system, I think. If I'm wrong, I'll have 10 million reasons to not sleep next year. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: One Laptop per Child security
Hi Nico, Nicolas Williams wrote: If this means pop-up dialogs for every little thing an application wants to do then the result may well be further training users to click 'OK'. It really does help to read at least the introduction to the document in question before hitting 'reply' to an e-mail :) Here are two of the four guiding principles for Bitfrost, stated in the first chapter of the spec: * No reading required Security cannot depend upon the user's ability to read a message from the computer and act in an informed and sensible manner. While disabling a particular security mechanism may require reading, a machine must be secure out of the factory if given to a user who cannot yet read. * Unobtrusive security Whenever possible, the security on the machines must be behind the scenes, making its presence known only through subtle visual or audio cues, and never getting in the user's way. Whenever in conflict with slight user convenience, strong unobtrusive security is to take precedence, though utmost care must be taken to ensure such allowances do not seriously or conspicuously reduce the usability of the machines. As an example, if a program is found attempting to violate a security setting, the user will not be prompted to permit the action; the action will simply be denied. If the user wishes to grant permission for such an action, she can do so through the graphical security center interface. Summary and other principles: http://wiki.laptop.org/go/Bitfrost (borrowed directly from the full spec). As for browsers, you'd have to make sure that every window/tab/frame is treated as a separate application, and even then that probably wouldn't be enough. Remember, the browser is a sort of operating system itself -- applying policy to it is akin to applying policy to the open-ended set of applications that it runs. The browser is an environment, which makes it an edge case. Even so, Bitfrost provides guarantees on what happens if you take over the browser: it's very hard to violate the user's privacy, you can't harm the machine in any way, you can't get unauthorized access to the user's documents. From a systems security point of view, that's all I could hope for. Security within the browser cannot lie in the scope of the spec. (Not to say that I don't care about it, though -- I'm meeting with Mozilla's CSO later today to talk about what we can do to make the browsing experience more secure.) Cheers, -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: One Laptop per Child security
Hi Paul, Paul J. Morris wrote: If a worm can propagate to every OLPC laptop it must have network access in some form, this means it could use the entire set of OLPC laptops to perform a distributed denial of service attack on a target. Sort of. The worm would still be subject to connection rate and bandwidth throttling, so the laptops are not _that_ useful as a DDoS launchpad. But it's all a big hypothetical scenario, because finding invariants to infect across all OLPC systems is likely to prove extremely difficult; only applications that the user sometimes runs generally listen on a port and act as a server. There aren't going to be unprotected, constantly-running servers to exploit. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: One Laptop per Child security
[Perry -- this is a very interesting discussion, but please feel free to
tell us to bugger off to the OLPC security list if you find it too
off-topic.]
Nicolas Williams wrote:
It tends to make me think that if an
application wants to do something that I've not enabled it to do ahead
of time then it fails.
If an application wants to do something for which _it_ didn't request
permission ahead of time, it fails. The difficulty is in creating the
permission set with the proper mutual exclusions, and in such a way that
it's very hard to request a permission set required to do something
malicious. At the same time, it has to be easy for most applications to
request the permissions they need to get their work done. I've tried to
strike a decent balance.
I'm imagining BitFrost as something like OpenBSD's systrace facility + a
small number of well-profiled apps. If this is a good analogy, please
confirm it.
Think high-level systrace, with each application providing the policy at
install time, and the user being able to amend it at any time.
In a world where web-based applications are all the applications you
need, this attitude towards the browser leaves BitFrost with a big hole
in it.
Protecting the browser is not in the scope of _system_ security. I'm
working on it separately, and want to see how to make it better, but to
the system security platform, a browser is just another application. To
that end, if the entire application is compromised, Bitfrost provides
very strong assurances about what an attacker can('t) do to the rest of
the system.
I think you have to think of each site as a separate application, and
profile that, if I understood BitFrost correctly.
No, the platform is too low in the security stack to have any idea about
what tabs and sites are. It sees a process, or some number of processes,
which are the browser.
--
Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
One Laptop per Child security
Earlier today, I publicly released the architecture-level specification for Bitfrost, the security platform on the One Laptop per Child machines: http://dev.laptop.org/git.do?p=security;a=blob;hb=HEAD;f=bitfrost.txt This is a complete but non-technical spec, with its technical complement scheduled for release sometime in late March (there's a pile of crypto powering various choice bits of the system). Comments are very much invited. Cheers, -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: man in the middle, SSL
James Muir wrote: It is my understanding that SSL is engineered to resist mitm attacks, so I am suspicious of these claims. I wondered if someone more familiar with SSL/TLS could comment. Isn't in the case that the application doing SSL on the client should detect what this proxy server is doing and display a warning to the user? There's nothing new or interesting about this; SSL MITM tools have been around for a long time. When you're connecting to a website via SSL, you have no out of band knowledge of the certificate that the server is supposed to use (e.g. you can't query DNS and get the certificate fingerprint). SSL clients generally do three checks on the server cert: they verify it's still valid on today's date, that the name in the cert matches the server you're connecting to, and that you trust the CA that issued the cert. An SSL MITM proxy can trivially satisfy two of those three checks. If an attacker had sufficiently strong incentive and a specific target site, presumably he could satisfy the third as well (get a trusted CA to sign a bogus cert for the server in question -- remember Microsoft from a few years back). So yes, in the general case, the web browser will notice the MITM, and inform the user that two checks pass and one fails. And almost all users will hit continue and not care, because they don't understand SSL or the risks involved. They shouldn't have to, either; it's for this reason that I think SSL is just altogether broken in the way we use it on the web. It passes the technical requirements, but utterly fails at being a usable security technology. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: man in the middle, SSL
[I prefer to keep discussions on-list where possible. CCing the list.] Beryllium Sphere LLC wrote: Bruce Schneier pointed out years ago that it's trivial for a virus or Trojan to add a new trusted CA to the browser's list of trusted roots. At least one advertising support web accelerator installs itself in the browser configuration as a peer of Verisign and can then proxy SSL without any warning to the user. Right. I was talking about the kind of MITM where an attacker is physically between your machine and the SSL destination, such as sitting on your network's egress. MOYM (man on your machine) attacks are a bit of a lost cause with most modern OS environments, though I've been working pretty hard to try and change that on the One Laptop per Child machines. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: more on NIST hash competition
Perry E. Metzger wrote: http://www.csrc.nist.gov/pki/HashWorkshop/index.html I'm completely unfamiliar with the way NIST operates, but I've been wondering for years why they haven't organized this competition already. Do we have a list veteran who can shed some light on why it took them this long? My curiosity demands to know. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
MS responds to Gutmann's Vista paper
Aside from admitting to increased CPU utilization, which seemed pretty incontestable anyway, they're disputing [0] many of the points made in the original paper [1]. Ignoring the hand-wavy arguments, I find most interesting their claims that a) there will be no move away from unified drivers, b) that HFS doesn't depend on, and therefore won't impact, open source drivers, and c) that video quality is degraded only for specific premium content rather than globally. Assuming all three are true, this would downgrade the Vista content protection system from cataclysmically braindead to merely extremely braindead -- a welcome downgrade, given all of Peter's other points. [0] http://windowsvistablog.com/blogs/windowsvista/archive/2007/01/20/windows-vista-content-protection-twenty-questions-and-answers.aspx [1] http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
MS responds to Gutmann's Vista paper
[Perry -- had a clause in there that made no sense; I shouldn't send mail minutes after waking up. Please discard previous mail and send along this one.] [Moderator's note: Too late, sorry. --Perry] Aside from admitting to increased CPU utilization, which seemed pretty incontestable anyway, they're disputing [0] many of the points made in the original paper [1]. Ignoring the hand-wavy arguments, I find most interesting their claims that a) there will be no move away from unified drivers, b) that HFS doesn't depend on driver-related video chip features, and therefore won't impact (the creation of) open source drivers, and c) that video quality is degraded only for specific premium content rather than globally. Assuming all three are true, this would downgrade the Vista content protection system from cataclysmically braindead to merely extremely braindead -- a welcome downgrade, given all of Peter's other points. [0] http://windowsvistablog.com/blogs/windowsvista/archive/2007/01/20/windows-vista-content-protection-twenty-questions-and-answers.aspx [1] http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: (Short) Intro and question
Allen wrote: One of the questions that I have been raising is trust and how to ensure that that it is not misplaced or eroded over time. Which leads me to my question for the list: I can see easily how to do split key for 2 out of x for key recovery, but I can't seem to find a reference to the 3 out of x problem. Read Shamir's original paper: http://www.cs.tau.ac.il/~bchor/Shamir.html and the Wikipedia page: http://en.wikipedia.org/wiki/Secret_sharing -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can you keep a secret? This encrypted drive can...
Adam Shostack wrote: Just a nit: as I understand things, Bitlocker is available, but not on, by default. Someone needs to actively flip a switch to make it go. Ah, okay. The notes I jotted down from MacIver's talk at HITB in Malaysia indicate he said it was on by default in the upper versions, but I could well have written it down incorrectly. Thanks for the correction. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can you keep a secret? This encrypted drive can...
Saqib Ali wrote: http://www.infoworld.com/article/06/10/30/HNseagateagain_1.html Notably, none of the three articles mention Vista's BitLocker, which provides FDE in software and establishes trust via a TPM chip. (For those who haven't heard about it, BitLocker also uses a clever diffuser that Niels Ferguson designed specifically for the FDE scenario.) The problem I see with hardware FDE is the same one that prompted Poul-Henning Kamp to design GBDE some time back: the lose a password, game over model doesn't work in corporate environments. People forget passwords all the time. They don't see this as an irrecoverable failure; it's something that the IT people are supposed to be able to fix with a wave of their tricorder. Once that assumption flies out the window, the cost of a lost password becomes so high that it's more convenient to disable the encryption altogether. On the other hand, Vista is shipping with BitLocker enabled by default in the upper editions (Enterprise or somesuch), and doesn't rely on passwords at all; it actually brings the user, without any interaction, to the standard Windows login prompt, where the user can reach for a smart card, or use a fingerprint reader, or do any other kind of authentication Windows supports. Optionally, a hardware token or USB key can be required during boot, and those can be made rekeyable by the IT department, if I understood one of the engineers who worked on it correctly. Seagate's technical solution isn't compatible with the social problem it's trying to solve. I think Microsoft's is, surprisingly enough. As a sidenote, I wonder if Seagate will release full details and code for their FDE (and AES) implementation, or if we're supposed to take the no backdoors clause on faith, as we do with TPMs. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
Travis H. wrote: I can validate everything else, but as long as the BIOS is motherboard-specific and closed source, I don't see why I should trust it. We need to get rid of this legacy crud. LinuxBIOS is a good step but unfortunately it is only supported on a few motherboards. We're shipping LinuxBIOS on the One Laptop per Child machines. No BIOS I know of has a semblance of security, given temporary physical access to the machine. I came up with a scheme that lets us do a secure BIOS without a TPM; bypassing it without a PLCC would be extremely difficult. I'm not yet certain if we'll end up shipping a PLCC socket on the final hardware, but if not, I suspect you'd be hard-pressed to do much to the BIOS protection even with physical access, short of un-soldering and re-soldering a different SPI flash chip to the motherboard. That was explicitly not part of my threat model. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
Alexander Klimov wrote: Since a regular installation should not change ``reported OS hash,'' TPM will not be able to detect the difference. Am I missing something? You're missing the marketing value of saying this piece of hardware, that you probably wouldn't otherwise want in your machine since it makes sure that the machine can be trusted /against/ you, is great! Because it protects you against trojans! And everyone wants to be safe from trojans, right?. Btw, how the TCG allows to regularly change the kernel for security patches and still keep the same ``reported hash''? The Microsoft guy presenting BitLocker at HITB last month mentioned this, but glossed over it without explaining. He did seem to indicate that they had some solution, but didn't provide details, IIRC. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
Kuehn, Ulrich wrote: Who is we? In the case of my own system I payed for (so speaking for myself) I would like to have such a mechanism to have the system prove to me before login that it is not tampered with. The TCG approach does not provide this. What does prove mean here? Does having a hash of the system state for visual inspection before boot do it? -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: secure key storage APIs
Perry, please merge with my previous message; I hit 'send' by mistake. Also, the following are of general interest: Henson S., `Netscape certificate database info`: http://www.drh-consultancy.demon.co.uk/cert7.html Henson S., `Netscape key database format`: http://www.drh-consultancy.demon.co.uk/key3.html Cheers, -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: secure key storage APIs
Travis H. wrote: Does anyone know of any OSS OS facilities for managing keys? Take a look at the GNOME Keyring: http://en.wikipedia.org/wiki/GNOME_Keyring http://cvs.gnome.org/viewcvs/gnome-keyring/ In addition, various frontends exists to GnuPG, e.g. KGPG. It's not yet clear, but I might have to write something from scratch to satisfy our needs at OLPC (http://laptop.org). -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
