Nominum says it has secret advantages over Bind
More security and security politics than crypto, but I thought this was rather interesting to this community: Nominum's Jon Shalowitz is interviewed on why you should buy Nominum's stuff over using open source, oh, pardon, freeware[sic] software: Q: What characterises that open-source, freeware legacy DNS that you think makes it weaker? A: Number one is in terms of security controls. If I have a secret way of blocking a hacker from attacking my software, if it's freeware or open source, the hacker can look at the code. By virtue of something being open source, it has to be open to everybody to look into. I can't keep secrets in there. But if I have a commercial-grade software product, then all of that is closed off, and so things are not visible to the hacker. http://news.zdnet.co.uk/itmanagement/0,100308,39760362,00.htm?s_cid=260 I guess Mr. Shalowitz is unaware of the existence of disassemblers. Either that, or perhaps all those people attacking Windows successfully have the source code, I'm not sure which. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
AES in stick figures
A Stick Figure Guide to the Advanced Encryption Standard (AES) (A play in 4 acts) http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html -Michael Heyman - 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: Ivan Krsti wrote: 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. Note my information may be out of date. I believe that MacOS native encrypted disk images (and thus FileVault) uses AES in CBC mode without any integrity protection, the Wikipedia article seems to confirm that is (or at least was) the case http://en.wikipedia.org/wiki/FileVault Unauthenticated CBC is indeed a problem http://tinyurl.com/ycoaruo There is also a sleep mode issue identified by the NSA: http://crypto.nsa.org/vilefault/23C3-VileFault.pdf I don't think that Jacob Appelbaum or Ralf-Philipp Weinmann work for the NSA (but having crypto.nsa.org is cool :-) TrueCrypt on the other hand uses AES in XTS mode so you get confidentiality and integrity. Technically, you do not get integrity. With XTS (P1619, narrow block tweaked cipher) you are not notified of data integrity failures, but these data integrity failures have a much reduced usability than CBC. With XTS: 1) You can return 16 byte chunks to previous values (ciphertext replay) as long as it is to the same place (offset) as it was before. 2) If you change a bit, you will randomize a 16 byte chunk of information. With the P1619.2 mode, I believe, is called TET (IEEE 1619.2, wide block tweaked cipher) there are different characteristics. Usually the wide block is a sector so it can be 512 or some other value. In this case, you do not get complete integrity either. In this case 1) You can return a sector to a previous value (sector reply) as long as it is to the same place (offset) as it was before. 2) If you change a bit, you will randomize a complete sector of information. If you change this to ZFS Crypto http://opensolaris.org/os/project/zfs-crypto/ You get complete integrity detection with the only remaining vulnerability that 1) you can return the entire disk to a previous state. While I may have put you all asleep, the basic premise holds... XTS is better than unauthenticated CBC. http://www.cpni.gov.uk/docs/re-20050509-00385.pdf http://jvn.jp/niscc/NISCC-004033/index.html http://www.kb.cert.org/vuls/id/302220 -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: FileVault on other than home directories on MacOS?
Ivan Krstić wrote: 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. The devil is in the details. If you use your default keychain to unlock a disk, I believe the _passphrase_ is still stored by LoginWindow.app in plain text... So even if they destroyed keying material properly (do they? Is there source we can review for how FV works?) when the disk isn't in use, I somehow doubt that it's really safe to use FileVault in some circumstances against some attackers. Especially if you have a laptop and especially if you didn't turn on encrypted swap. Also especially if you happened to use the encrypted swap feature when it wasn't working. The list of hilarious bugs goes on and on. (The LoginWindow.app bug is as old as the hills and I'm one of a dozen people to have reported it, I bet. Apple still hasn't fixed it because they rely on a users password being in memory to escalate privileges without interacting with the user! I hear they're working on a fix but that it's difficult because many systems rely on this feature.) I haven't been working on or thinking about VileFault much but I suppose that we probably could add support for sparse bundles if someone wanted. I've been bugging Apple for some specifications and so far, it's been years without a real response. Most of what we know is in VileFault: http://code.google.com/p/vilefault/ It would be really awesome if Apple would open up all of this code or at least publish a specification for how it works. With either we could have a Fuse file system module to support these disk images on other platforms... Best, Jacob signature.asc Description: OpenPGP digital signature
[Barker, Elaine B.] NIST Publication Announcements
Forwarded: From: Barker, Elaine B. elaine.bar...@nist.gov To: Barker, Elaine B. elaine.bar...@nist.gov Date: Thu, 24 Sep 2009 15:54:18 -0400 Subject: NIST Publication Announcements NIST announces the completion of two NIST Special Publications (SPs): SP 800-56B, Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography, and SP 800-102, Recommendation for Digital Signature Timeliness. Both publications are available at http://csrc.nist.gov/publications/PubsSPs.html. SP 800-56B provides specifications of key establishment schemes that are appropriate for use by the U.S. Federal Government, based on a standard developed by the Accredited Standards Committee (ASC) X9, Inc.: ANS X9.44, Key Establishment using Integer Factorization Cryptography. A key establishment scheme can be characterized as either a key agreement scheme or a key transport scheme. This Recommendation provides asymmetric-based key agreement and key transport schemes that are based on the Rivest Shamir Adleman (RSA) algorithm. SP 800-102 is intended to address the timeliness of the digital signatures generated using the techniques specified in Federal Information Processing Standard (FIPS) 186-3. Establishing the time when a digital signature was generated is often a critical consideration. A signed message that includes the (purported) signing time provides no assurance that the private key was used to sign the message at that time unless the accuracy of the time can be trusted. SP 800-102 provides methods of obtaining assurance of the time of digital signature generation using a trusted timestamp authority that is trusted by both the signatory and the verifier. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Interesting way of protecting credit card data on untrusted hosts
A Canadian company called SmartSwipe has come up with an interesting way to protect credit card numbers from most man-in-the-browser attacks. What they do is install a Windows CSP (cryptographic service provider) that acts as a proxy to an external mag-stripe reader with built-in crypto processing, so the CSP on the host PC does nothing more than forward data to be encrypted out to the external device. There's also a browser plug-in that pre-populates the credit-card field in web forms with a cookie. When the page is sent to the CSP for encryption for SSL, the software running on the reader recognises the cookie in the web-form content, reads the card data via the mag-stripe reader, inserts it into the web-form field, and returns the encrypted result to the host PC to forward to the remote server. As a result, the CC data is never present on the host PC. The downsides are obvious: not secure against phishing (which is a killer), only works with MSIE because of the requirement for use of a CSP (although you could do it with Firefox as well by creating a PKCS #11 soft-token), and not secure against page-rewrite trojans which have the web page show one thing and do another, but it's an interesting concept. You can find a description of the technology under the name Dynamic SSL(tm)(c)(p), a start point is: http://www.smartswipe.ca/en/dynamic-ssl/600-dynamic-ssl-a-practical-solution-for-endpoint-to-endpoint-encryption Peter. - 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)
On Mon, Sep 7, 2009 at 6:02 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: 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 usual, I tend to agree with Peter. Consider the time scale and severity of problems with cryptographic algorithms vs. the time scale of protocol development vs. the time scale of bug creation attributable to complex designs. Let's make up some fake numbers, shall we? (After all, we're software engineers. Real numbers are for real engineers! Bah!) cryptographic algorithm weakness discovery rate: several per decade cryptographic algorithm weakness severity: 5 badness points per decade the weakness has been known; 7 badness points is considered fatal. Let's say MD5's badness is 8 and SHA-1's is 3. AES-256's is 1, because even after the attack it is still strong enough for most real uses. protocol development rate: 1 per year bug creation rate (baseline): tens per day per project bug creation rate for bugs due to complex designs: half of baseline (the other half is due to just regular mistakes) Although the numbers are fake, perhaps the orders of magnitude are close enough to make the point. Which is: your software will fail for reasons unrelated to cryptographic algorithm problems long before SHA-256 is broken enough to matter. Perhaps pluggability is a source of frequent failures, designed to solve for infrequent and low-severity algorithm failures. I would worry about an overfull \hbox (badness 1!) long before I worried about AES-128 in CBC mode with a unique IV made from /dev/urandom. Between now and the time our ciphers and hashes and signatures are broken, we'll have a decade to design and implement the next simple system to replace our current system. Most software developers would be overjoyed to have a full decade. Why are we whining? What if TLS v1.1 (2006) specified that the only ciphersuite was RSA with = 1024-bit keys, HMAC_SHA256, and AES-128 in CBC mode. How likely is it that attackers will be able to reliably and economically attack those algorithms in 2016? Meanwhile, the comically complex X.509 is already a punching bag (http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf and http://www.blackhat.com/presentations/bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-SLIDES.pdf, including the remote exploit in the certificate handling code itself). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
OTR splicer for Skype ?
I found the following Adium-based solution for layering OTR atop Skype IM: http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2008-06/msg00224.html ...and was wondering whether anyone has generalised this by creating some open-source, standalone, simple application which talks to the Skype client API and splices OTR into the channel? Just wondering. -a -- alec.muff...@gmail.com http://www.crypticide.com/dropsafe/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
