Nominum says it has secret advantages over Bind

2009-09-28 Thread Perry E. Metzger

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

2009-09-28 Thread mhey...@gmail.com
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?

2009-09-28 Thread james hughes


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?

2009-09-28 Thread Jacob Appelbaum
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


Re: FileVault on other than home directories on MacOS?

2009-09-28 Thread Darren J Moffat

james hughes wrote:
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:


[snip]


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


For those not familiar this is because Jim and I choose to use CCM/GCM 
with AES.  ZFS is already using a copy-on-write validated merkle tree. 
The 16 byte tag/MAC from CCM/GCM is stored in the block pointer above 
forming a merkle tree.  Each encrypted block in ZFS has its own IV.  ZFS 
disk blocks are variable size from 512 bytes to (currently) 128k.



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.


Which is really what I was trying to say and over stated that XTS 
provides integrity. When really what it does is as you said, provides a 
better protection for certain classes of ciphertext modification than 
just using CBC.


--
Darren J Moffat

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


[Barker, Elaine B.] NIST Publication Announcements

2009-09-28 Thread Perry E. Metzger

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

2009-09-28 Thread Peter Gutmann
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)

2009-09-28 Thread Fuzzy Hoodie-Monster
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 ?

2009-09-28 Thread Alec Muffett
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