Archive for the ‘Crypto’ Category

Quickies: dns, tor 0.2.0.x, truecrypt 6, cold boot sw, fips stuff, j-pake

Wednesday, July 23rd, 2008

I am posting these snippets in a period of quiet between bedraggling, booming storms. Alas, dear reader, another set of quickies, as summertime rolls.

-

So, the DNS implementation flaw has (allegedly) been revealed. Grinding through weak state combined with additional RR trickery gets the job done. Good stuff. Adding more entropy to the state information is one way to fend off feasibility, as demonstrated by djbdns (yes, I mentioned djbdns at one point). Patches abound.

Update: An exploit.
-

The 0.2.0.x branch of Tor has gone from alpha to release, with 0.2.0.30 being the first version deemed fit for primetime.

I tagged Tor 0.2.0.30, the stable release of the 0.2.0.x series, on Tuesday.

You can read all about it here:
https://svn.torproject.org/svn/tor/tags/tor-0_2_0_30/ReleaseNotes

We haven’t made an official announcement yet, because we’re waiting for Torbutton 1.2.0 to go stable so we can build packages for the Windows and OS X folks.

From the release notes

Changes in version 0.2.0.30 - 2008-07-15
This new stable release switches to a more efficient directory distribution design, adds features to make connections to the Tor network harder to block, allows Tor to act as a DNS proxy, adds separate rate limiting for relayed traffic to make it easier for clients to become relays, fix a variety of potential anonymity problems, and includes the usual huge pile of other features and bug fixes.

Great work.

-

The TrueCrypt team has been quite busy it seems, with two major releases this year within a few months of each other. So, TrueCrypt 6 has been rolled out, and I took note of the following new features.

Parallelized encryption/decryption on multi-core processors (or multi-processor systems). Increase in encryption/decryption speed is directly proportional to the number of cores and/or processors.

Each volume created by this or later versions of TrueCrypt will contain an embedded backup header (located at the end of the volume). Note that it is impossible to mount a volume when its header is damaged (the header contains an encrypted master key). Therefore, embedded backup headers significantly reduce this risk. Also note that a backup header is not a copy of the original volume header because it is encrypted with a different header key derived using a different salt. For more information, see the subsection Tools > Restore Volume Header.

More great work.

-

Remember cold boot? Well, the software created as part of the research has now been released.

July 16, 2008 — This page contains source code for some of the software that we developed in the course of this research. These prototype applications are intended to illustrate the techniques described in the paper; we are unable to provide technical support.

-

You may have noticed this.

4Q08 The second draft of FIPS 140-3 will be published for public comment (subject to change).

-

A few new modes of operation for the AES have popped up at NIST in somewhat recent months. One of these, XTS, is now being proposed by NIST for approval for government use, meaning it could become an approved mode of operation for AES under FIPS 140.

The P1619 Task Group of the Security in Storage Working Group (SISWG) of the Institute of Electrical and Electronics Engineers, Inc. (IEEE) has submitted the XTS-AES algorithm (XTS, for short) to NIST as an encryption mode of operation of the Advanced Encryption Standard (AES) block cipher. Although XTS does not provide authentication in order to avoid expansion of the data, it is designed to provide some protection against malicious manipulation of the encrypted data. Subject to the 90-day period of public comment that is described below, NIST proposes to approve XTS for government use under the auspices of FIPS Pub. 140-2.

-

Draft SP 800-107, Recommendation for Applications Using Approved Hash Algorithms, has been published and is open to public comment until 09-Oct-2008.

This Recommendation provides security guidelines for achieving the required or desired security strengths of several cryptographic applications that employ the approved cryptographic hash functions specified in Federal Information Processing Standard (FIPS) 180-3 [FIPS 180-3], such as digital signature applications [FIPS 186-3], Keyedhash Message Authentication Codes (HMACs) [FIPS 198-1] and Hash-based Key Derivation Functions (HKDFs) [SP 800 56A] & [SP 800 56B].

Update: Related to the SP 800-107 news, a revision to FIPS 198 has been released, FIPS 198-1.

APPENDIX A: The Differences Between FIPS 198 and FIPS 198-1
The length of truncated HMAC outputs and their security implications in FIPS 198 is not mentioned in this Standard; instead, it is described in SP 800-107. The discussion about the limitations of MAC algorithms has been moved to SP 800-107. The examples and OIDs have been posted on the NIST web sites referenced in Section 6.

-

Yes please.

Abstract. Password-Authenticated Key Exchange (PAKE) studies how to establish secure communication between two remote parties solely based on their shared password, without requiring a Public Key Infrastructure (PKI). Despite extensive research in the past decade, this problem remains unsolved. Patent has been one of the biggest brakes in deploying PAKE solutions in practice. Besides, even for the patented schemes like EKE and SPEKE, their security is only heuristic; researchers have reported some subtle but worrying security issues.

In this paper, we propose to tackle this problem using an approach different from all past solutions. Our protocol, Password Authenticated Key Exchange by Juggling (J-PAKE), achieves mutual authentication in two steps: first, two parties send ephemeral public keys to each other; second, they encrypt the shared password by juggling the public keys in a verifiable way. The first use of such a juggling technique was seen in solving the Dining Cryptographers problem in 2006. Here, we apply it to solve the PAKE problem, and show that the protocol is zero-knowledge as it reveals nothing except one-bit information: whether the supplied passwords at two sides are the same. With clear advantages in security, our scheme has comparable efficiency to the EKE and SPEKE protocols.

Quickies: headaches, links, stories, crypto stuff, other

Wednesday, May 21st, 2008

So, I recently saw Juno for the first time, and was surprised and happy to hear Kimya Dawson permeate the soundtrack. And, I ate at wd~50, which was, well, an experience - highly recommended if you want to try something truly new.

Anyway, yes, still here. Unfortunately, this rare act of posting will be limited to a quickie - a few miscellaneous items accumulated over a couple of months.

-

A few headaches…

  1. Wow, just wow.

    The result of this is that for the last two years (from Debian’s “Etch” release until now), anyone doing pretty much any crypto on Debian (and hence Ubuntu) has been using easily guessable keys. This includes SSH keys, SSL keys and OpenVPN keys.

    Update immediately. And be sure to do things such as regenerate all persistent keys that used random data taken from the vulnerable Debian OpenSSL during their generation - some of this type of work is handled automatically when updating your packages (e.g., OpenSSH server keys), but only you know what you have done outside this automated window.

  2. I booted up a Windows XP box only to find that some resource of the Logitech QuickCam software had become corrupted, and this resulted in a nasty msi installer loop hitting the box as soon as a user logged in. I found this tool extremely useful in cleaning up the mess.

    [..]With the Windows Installer CleanUp Utility, you can remove a program’s Windows Installer configuration information. You may want to remove the Windows Installer configuration information for your program if you experience installation (Setup) problems. For example, you may have to remove a program’s Windows Installer configuration information if you have installation problems when you try to add (or remove) a component of your program that was not included when you first installed your program.

  3. Much to my very unpleasant surprise, I upgraded a server over here from Ubuntu Gutsy to Hardy and discovered networking for Xen DomU’s in Ubuntu Hardy 8.04 is somewhat broken. I ended up using the 2.6.24-17-xen kernel from the hardy-proposed repository, but you could also just stick with the Gutsy Xen kernel for DomU’s.
  4. When I upgraded to Gnome 2.22 on a particular FreeBSD 7.0 system, certain things, like the clock applet, did not work. This was due to the dbus daemon not being started. Then, the hal daemon and Gnome did not want to play nice together. This page provided the information necessary to get them playing nice - in this particular instance, not mounting procfs was the problem.

Side note, I was helping someone install Ubuntu recently, and it brought to my attention yet again how much I take what I consider to be basic skills for granted when using *nix. Small things, like running an executable from within your environment path versus by directly specifying the path (the most confusing to many example of this seems to be trying to run an executable in the current working directory), are just not common knowledge. Even the whole command line itself is often scary and bizarre to people. This makes it extremely difficult to provide useful guidance for people to blindly follow (posts on this blog should never be assumed to provide step-by-step instructions - they are just some basic notes at best, as extremely helpful comments like this make obvious). And, even Ubuntu is not as trivial to use as it would appear to many that work in the *nix world.

-

Three useful Ubuntu and FreeBSD pages…

USN.

These are the Ubuntu security notices that affect the current supported releases of Ubuntu.[...]

FreeBSD VuXML.

Security issues that affect the FreeBSD operating system or applications in the FreeBSD Ports Collection are documented using the Vulnerabilities and Exposures Markup Language (VuXML).[...]

FreeBSD Security Advisories.

This web page contains a list of released FreeBSD Security Advisories.[...]

-

Story-telling is one of the fundamental tools in a teacher’s toolkit. Having done quite a bit of consulting, I have learned how invaluable a good story is to driving home particular points and building relationships. There is something fundamental about how stories effect us, perhaps stemming from our innate ability to empathesize and our massive pattern recognition horse-power.

Anyway, this site has a useful set of stories. [via exi]

Here are some stories, analogies, research findings and other examples that provide wonderful illustrations for learning, and inspiration for self-development.

In fact, the first story mirrors a recent post.

An old lady had a hearing-aid fitted, discreetly, hidden underneath her hair.

A week later she returned to the doctor for her check-up.

“It’s wonderful - I can hear everything now,” she reported very happily to the doctor.

“And is your family pleased too?” asked the doctor.

“Oh I haven’t told them yet,” said the old lady, “And I’ve changed my will twice already..”

This reminds me of a story I often tell about someone I met a while back, a graduate student in psych. She was studying aspects of the initial meeting/courtship routines of people, and would go out to bars and such and interact with potential suitors. Here these suitors were, following their typical pickup routines and sometimes spilling more than their drinks, and here she was, analyzing their interaction and subsequently writing up notes to be turned into research papers, etc.

-

NIST draft SP 800-108 has been released.

SP 800-108

DRAFT Recommendation for Key Derivation Using Pseudorandom Functions

NIST announces the release of draft Special Publication 800-108, Recommendation for Key Derivation Using Pseudorandom Functions. This Recommendation specifies techniques for key derivation from a secret key using pseudorandom functions (PRF). Please submit comments to draft-SP800-108-comment@nist.gov with “Comments on SP800-108″ in the subject line. The comment period closes on June 28, 2008.

Yet more KDFs.

-

They just don’t quit, do they?

1

This is the first article analyzing the security of SHA-256 against fast collision search which considers the recent attacks by Wang et al. We show the limits of applying techniques known so far to SHA-256. Next we introduce a new type of perturbation vector which circumvents the identified limits. This new technique is then applied to the unmodified SHA-256. Exploiting the combination of Boolean functions and modular addition together with the newly developed technique allows us to derive collision-producing characteristics for step-reduced SHA-256, which was not possible before. Although our results do not threaten the security of SHA-256, we show that the low probability of a single local collision may give rise to a false sense of security.

2

We study the security of step-reduced but otherwise unmodified SHA-256. We show the first collision attacks on SHA-256 reduced to 23 and 24 steps with complexities $2^{18}$ and $2^{50}$, respectively. We give an example colliding message pair for 23-step SHA-256. The best previous, recently obtained result was a collision attack for up to 22 steps. Additionally, we show non-random behaviour of SHA-256 in the form of pseudo-near collisions for up to 31 steps, which is 6 more steps than the recently obtained non-random behaviour in the form of a semi-free start near-collision. Even though this represents a step forwards in terms of cryptanalytic techniques, the results do not threaten the security of applications using SHA-256.

3

[...]First we describe message modification techniques and use them to obtain an algorithm to generate message pairs which collide for the actual SHA-256 reduced to 18 steps. Our second contribution is to present differential paths for 19, 20, 21, 22 and 23 steps of SHA-256. We construct parity check equations in a novel way to find these characteristics. Further, the 19-step differential path presented here is constructed by using only 15 local collisions, as against the previously known 19-step near collision differential path which consists of interleaving of 23 local collisions. Our 19-step differential path can also be seen as a single local collision at the message word level. We use a linearized local collision in this work. These results do not cause any threat to the security of the SHA-256 hash function.

4

[...]We build on the work of Nikoli\’{c} and Biryukov and provide a generalized nonlinear local collision which accepts an arbitrary initial message difference. This local collision succeeds with probability 1. Using this local collision we present attacks against 18-step SHA-256 and 18-step SHA-512 with arbitrary initial difference. Both of these attacks succeed with probability 1. We then present special cases of our local collision and show two different differential paths for attacking 20-step SHA-256 and 20-step SHA-512. One of these paths is the same as presented by Nikoli\’{c} and Biryukov while the other one is a new differential path. Messages following both these differential paths can be found with probability 1. This improves on the previous result where the success probability of 20-step attack was 1/3. Finally, we present two differential paths for 21-step collisions for SHA-256 and SHA-512, one of which is a new path. The success probability of these paths for SHA-256 is roughly $2^{-15}$ and $2^{-17}$ which improves on the 21-step attack having probability $2^{-19}$ reported earlier. We show examples of message pairs following all the presented differential paths for up to 21-step collisions in SHA-256. We also show first real examples of colliding message pairs for up to 20-step reduced SHA-512.

Completely academic, but you know what they say - attacks only get better.

-

Interesting stuff.

NSA/CSS periodically releases declassified documents or indexes to these documents to the public. The documents listed on this page were located in response to numerous requests received by NSA on the various subjects stated and for which there appears to be a general public interest. The date after each entry reflects the most current release date of that material. When additional material for a given subject is updated then a new subject index date is posted. To select a subject index, click on the subject title.

In particular, the Cryptologic Spectrum Articles and Cryptologic Quarterly Articles have some fun reads.

-

An easy to cut ‘n paste into a blog post set of old web server log entries depicting an instance of Tor being used to proxy/anonymize automated probes of this web site.

anonymizer.blutmagie.de - - [13/Mar/2008:00:59:00 -0700] “GET /forum/phpbb/index.php HTTP/1.0″ 404 285 “http://forum.d-kriptik.com/phpbb/index.php” “Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1)”

tor.anonymous.proxy.quex.org - - [13/Mar/2008:00:59:01 -0700] “GET /forum/phpbb2/index.php HTTP/1.0″ 404 286 “http://forum.d-kriptik.com/phpbb2/index.php” “Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1)”

tor.anonymizer.ccc.de - - [13/Mar/2008:00:59:02 -0700] “GET /forum/forums/index.php HTTP/1.0″ 404 286 “http://forum.d-kriptik.com/forums/index.php” “Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1)”

tor.anonymizer.ccc.de - - [13/Mar/2008:00:59:08 -0700] “GET /forum/board/index.php HTTP/1.0″ 404 285 “http://forum.d-kriptik.com/board/index.php” “Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1)”

-

Like heat and humidity, free music and Central Park mean summer. The 2008 schedule is up at the Summer Stage web site. And, the opening Saturday looks good to me.

Vampire Weekend
Kid Sister
Ecstatic Sunshine

Saturday, June 14, 2008
From 4:00 PM to 7:30 PM
Central Park SummerStage

entropy, misc

Wednesday, March 12th, 2008

I found this post interesting having just had yet another discussion about entropy in this seed, key, password, etc. world of mine.

The term “Mind Projection Fallacy” was coined by the late great Bayesian Master, E. T. Jaynes, as part of his long and hard-fought battle against the accursèd frequentists. Jaynes was of the opinion that probabilities were in the mind, not in the environment - that probabilities express ignorance, states of partial information; and if I am ignorant of a phenomenon, that is a fact about my state of mind, not a fact about the phenomenon.

Of course, this speaks to entropy. In our seed, key, password, etc. world, entropy is a measure of uncertainty. It is what someone does not know. As such, entropy is subjective. If I know a password, it has no entropy; however, to someone that knows close to absolutely nothing about a password, it has close to maximum entropy.

So, when we talk about the entropy of things like passwords, what we generally mean is the amount of uncertainty, or the lack of information, about that password given some set of assumptions of the information available about that password. And, since entropy is subjective, any measurement of this uncertainty that we produce will likely just be a bound (e.g., an estimate of the maximum possible value) based on particular assumptions.

Ok, lets look at a very simple example with passwords (I banged this out quickly, so hopefully I didn’t make any obvious mistakes)…

Consider the set of passwords exactly 8 digits in length and composed of case-insensitive, repeatable, alphanumeric characters. Given that, each digit of the password can be 1 of 36 characters (i.e., 0-9 or a-z), and, given the passwords are 8 digits in length, there are 36*36*36*36*36*36*36*36 = 368 possible passwords.

Flipping through “The Mathematical Theory of Communication”, Shannon defined entropy, or the measure of uncertainty, for a set of probabilities p1,…,pn, as H = -∑ pi log pi, where pi is the probably of an event i.

Looking at SP800-90, min-entropy, another measure of uncertainty, for a set of probabilities p1,…,pn is defined as H = -log2(pmax), where pmax is the maximum p in p1,…,pn.

Now, lets say you choose a password from this set using a selection method that ensures that the probability of any character being chosen for a digit of the password is 1/36 (i.e., each digit of the password is equally likely to contain any of the 36 possible characters). Once you have chosen and know your password, what is the entropy of that password to you? Well, 0, as you know the password.

In other words, each digit of the password is known to you, meaning the probably of one particular character being in each digit of the password is 1, while the probably of any other characters being in that same digit is 0. So, there is only one pi for each digit of the password, and our Shannon H = -∑ pi log pi = -1 log 1 = 0 and our min-entropy H = -log21 = 0. So, for each digit of our password, H=0. And, treating the digits of our password as independent, the entropy of our password is sum of the individual entropy we calculated for each digit, namely 0+0+0+0+0+0+0+0=0.

Another way of looking at this is that the chance that you will guess your password given you know your password is 1/1=1. Translating that to percent, 1*100 = 100%.

Now, lets say an outside observer comes along who knows nothing about the password you selected above except that it is in this set of possible passwords we have defined. For this attacker, the entropy of the password is quite different, as there is quite a bit uncertainty about your password.

As stated, each digit of the password can be 1 of 36 characters, and this outsider has no information that would bias them towards any particular character being in any particular digit of the password. So, the probably of a particular digit in the password being a particular character is 1/n, where n is the number of potential characters, or 1/36.

Plugging that into H, we get Shannon H = -∑ pi log pi = -((1/36)*log(1/36) + (1/36)*log(1/36) + …repeat 32 more times… + (1/36)*log(1/36) + (1/36)*log(1/36)) = log(36) ≈ 1.5563 (5.1699 bits) or our min-entropy H = -log2(1/36) ≈ 5.1699. So, for each digit of our password, H ≈ 1.5563 (5.1699 bits). And, since this observer knows nothing to imply any dependence between the digits of the password, the digits can be treated as independent and so the total entropy for the password will equal the sum of the entropy of each digit, or roughly 1.5563+1.5563+1.5563+1.5563+1.5563+1.5563+1.5563+1.5563=1.5563*8=≈12.4504 (5.1699+5.1699+5.1699+5.1699+5.1699+5.1699+5.1699+5.1699=5.1699*8=≈41.3594 bits)

Another way of looking at this is that the chance this outside observer will guess our password is 1/(368)=1/2821109907456≈.00000000000035447. Translating that to percent, .00000000000035447*100 = .000000000035447%.

This situation is actually the maximum measure of uncertainty for a password taken from our set of passwords, as it assumes that every character from our character set to be equally likely in every digit of the password and that each digit is independent of the others. (When people ask if their passwords are strong, generally they are asking whether they are near this maximum bound.)

Of course, there is a large range in between the two entropy extremes in this example, and where someone’s uncertainty about a password falls in that range depends on what they know about the password. For example, if they know the password is an English word but not what word exactly, the entropy slides over towards the minimum end. If they know your password is the name of someone very close to you but not what name exactly, then the entropy likely drops to close to zero.

Since I mentioned it above, Appendix A of of SP800-90 (Recommendation for Random Number Generation Using Deterministic Random Bit Generators) discusses the subjectiveness of entropy.

The word “entropy” is used to describe a measure of randomness, i.e., a description of how hard a value is to guess. Entropy is a measure of uncertainty or unpredictability and is dependent on the probabilities associated with the possible results for a given “event” (e.g., a throw of a die or flip of a coin).

Entropy is relative to an adversary and his ability to observe or predict a value. If the adversary has no uncertainty about the value, then the entropy is zero (and so is the security of the consuming application that relies on the DRBG). Any assessment of the entropy of a particular value is actually an assessment of how much of the value is unknown to the adversary.

That document also discusses calculating entropy, recommending min-entropy over Shannon entropy. In the example calculations here, both result in the same entropy estimate, but, in general, min-entropy will produce a more conservative (i.e., less than or equal to) estimate of entropy than Shannon entropy.

***

A new version of mixmaster has been released. [via remops and others]

Mixmaster 3.0 has been released this week. This is the first major version release since 2.9, and a continuation of that code, though it incorporates numerous improvements, feature enhancements, and bug-fixes. It is recommended that you upgrade your remailers to this version.

The next major version of Tor is in the release candidate phase too.

-

For the wannabe gargoyles amongst us… [via tt]

Researchers at the University of Tokyo have developed a smart video goggle system that records everything the wearer looks at, recognizes and assigns names to objects that appear in the video, and creates an easily searchable database of the recorded footage. Designed to function as a high-tech memory aid, these “Cyber Goggles” promise to make the act of losing your keys a thing of the past, according to head researcher professor Tatsuya Harada.

And, yes, I would wear those.

-

Finally, if you build it, they will come.

Abstract—Our study analyzes the security and privacy properties of an implantable cardioverter defibrillator (ICD). Introduced to the U.S. market in 2003, this model of ICD includes pacemaker technology and is designed to communicate wirelessly with a nearby external programmer in the 175 kHz frequency range. After partially reverse-engineering the ICD’s communications protocol with an oscilloscope and a software radio, we implemented several software radio-based attacks that could compromise patient safety and patient privacy. Motivated by our desire to improve patient safety, and mindful of conventional trade-offs between security and power consumption for resource constrained devices, we introduce three new zero-power defenses based on RF power harvesting. Two of these defenses are humancentric, bringing patients into the loop with respect to the security and privacy of their implantable medical devices (IMDs). Our contributions provide a scientific baseline for understanding the potential security and privacy risks of current and future IMDs, and introduce human-perceptible and zero-power mitigation techniques that address those risks. To the best of our knowledge, this paper is the first in our community to use general-purpose software radios to analyze and attack previously unknown radio communications protocols.

Cold boot

Thursday, February 21st, 2008

So, straight off the hotplug post, now there is a paper discussing the recovery of encryption keys from RAM after a machine has been powered off. [hat tip to a friend and Metzger's list]

Contrary to popular assumption, DRAMs used in most modern computers retain their contents for seconds to minutes after power is lost, even at room temperature and even if removed from a motherboard. Although DRAMs become less reliable when they are not refreshed, they are not immediately erased, and their contents persist sufficiently for malicious (or forensic) acquisition of usable full-system memory images. We show that this phenomenon limits the ability of an operating system to protect cryptographic key material from an attacker with physical access. We use cold reboots to mount successful attacks on popular disk encryption systems using no special devices or materials. We experimentally characterize the extent and predictability of memory remanence and report that remanence times can be increased dramatically with simple techniques. We offer new algorithms for finding cryptographic keys in memory images and for correcting errors caused by bit decay. Though we discuss several strategies for partially mitigating these risks, we know of no simple remedy that would eliminate them.

In my previous post, I said “However, if you pulled the plug, then the plaintext key would be lost.” without qualifiers - I generally thought a 10 second rule was appropriate, that is, remove power and 10 seconds later the key would be too difficult for most attackers to recover. Well, it looks like a 60 second rule is a better baseline and perhaps a 515 minute rule is the fairly conservative way to go.

Our first tests measured the decay rate of each memory module under normal operating temperature, which ranged from 25C to 44C depending on the machine (see Figures 1, 2, and 3). We found that the dimensions of the decay curves varied considerably between machines, with the fastest exhibiting complete data loss in approximately 2.5 seconds and the slowest taking an average of 35 seconds. However, the decay curves all display a similar shape, with an initial period of slow decay, followed by an intermediate period of rapid decay, and then a final period of slow decay.

And,

Imaging residual memory contents requires no special equipment. When the system boots, the memory controller begins refreshing the DRAM, reading and rewriting each bit value. At this point, the values are fixed, decay halts, and programs running on the system can read whatever data is present using normal memory-access instructions.

In other words, if someone quickly powers the system back up after the plug is pulled, the decay is stopped. So, turn the system back on within a few seconds, and it is likely quite easy for anybody to quickly reboot the machine from, say, a USB token that has just enough software to dump the memory and then pull the key from that dump. Throw in some error correcting algorithms based on, say, the key schedules used in AES, and key recovery in the presence of some memory degradation improves drastically.

Our experiments (see Section 3) show that it is possible to recover memory contents with few bit errors even after cutting power to the system for a brief time, but the presence of even a small amount of error complicates the process of extracting correct cryptographic keys. In this section we present algorithms for correcting errors in symmetric and private keys. These algorithms can correct most errors quickly and uniquely even in the presence of relatively high bit error probabilities in the range of 5% to 50%, depending on the type of key.

And, yes, they demonstrated all of this on TrueCrypt,

We tested TrueCrypt versions 4.3a and 5.0a running on a Linux system. We mounted a volume encrypted with a 256-bit AES key, then briefly cut power to the system and used our memory imaging tools to record an image of the retained memory data. In both cases, our keyfind program was able to identify the 256-bit AES encryption key, which did not contain any bit errors. For TrueCrypt 5.0a, keyfind was also able to recover the 256-bit AES XTS tweak key without errors.

As well as, on dm-crypt (for those, say, using FDE setup during the installation of Ubuntu Gutsy).

We tested a dm-crypt volume created and mounted using the LUKS (Linux Unified Key Setup) branch of the cryptsetup utility and kernel version 2.6.20. The volume used the default AES-CBC format. We briefly powered down the system and captured a memory image with our PXE kernel. Our keyfind program identified the correct 128-bit AES key, which did not contain any bit errors. After recovering this key, an attacker could decrypt and mount the dm-crypt volume by modifying the cryptsetup program to allow the raw key to be input.

What to do?

Memory imaging attacks are difficult to defend against because cryptographic keys that are in active use need to be stored somewhere. Our suggested countermeasures focus on discarding or obscuring encryption keys before an adversary might gain physical access, preventing memory-dumping software from being executed on the machine, physically protecting DRAM chips, and possibly making the contents of memory decay more readily.

So, shutdown and remove power from that machine when not in use. And, make sure no one accesses that machine for 515 minutes (or more) after removing power. You may even want to create a bootable CD-ROM or USB token that specifically scrubs all system RAM, and boot from that after finishing up using encryption tools.

Good stuff.

Update: Here is the site covering the paper’s release, which includes a FAQ.

Update: Declan McCullagh has a slide show demonstrating the attack conducted against his laptop, as well as, an article on the topic.

Update: Just a quick note, since this post has given me some grief in my circles - you know, if the value of the data you are protecting is such that an attacker would be willing to, say, employ electron microscopes and such in the process of analyzing your DRAM, then you really need to start looking into very specific hardware setups (e.g., hardware cryptographic modules, physical destruction mechanisms, etc.) to meet your needs, because that generic Dell machine running that generic flavor of Windows with whatever cryptographic software on top is very likely not going to cut it for your purposes.

Update: Look at that.

When the idea of memory retaining state for a short time was first brought to my attention a little over a year ago, I ran a few experiments similar to this one, just to prove it to myself. The desktop machines I tried would hold state for anywhere between 5 and 10 seconds without power, whereas my laptop, with no battery or wall power, would maintain state for an amazing 10 minutes.[...]

The Princeton researchers applied this method to the recovery of encryption keys, with great results. They also cooked up a way to image the contents of RAM with a very small footprint, only overwriting a small amount of memory in the process. Unfortunately, at the time of writing this, their tool, ram2usb, hasn’t been released. I decided that it wouldn’t be hard to go ahead and implement one myself, based off their paper and youtube video posted above, so that I (and others) can go ahead and start having fun.

So, as a small side project, I’ve written “msramdmp”, the McGrew Security RAM Dumper. Enjoy!

Update: Yes, yes, if the wire is available, why boot cold when you could just use fire.

Update: The software created by the original researchers has now been released http://citp.princeton.edu/memory/code/.

July 16, 2008 — This page contains source code for some of the software that we developed in the course of this research. These prototype applications are intended to illustrate the techniques described in the paper http://citp.princeton.edu/memory/; we are unable to provide technical support.

FIPS yet again, hotplug, impact

Tuesday, February 19th, 2008

I feel like I am beating a dead horse with the start of this post. I tried to go a little off course from there.

-

Another discussion of FIPS 140 has been kicked off on SAAG. Besides the kick off message (on including FIPS-approved algorithms in a possible IETF recommended set of crypto algorithms), this post (on product customer demand for FIPS 140) and this post (on the general pain of the process) are probably of most interest, but the entire thread may be worth a read if FIPS 140 matters to you. (Oh, and this made me laugh.)

This post of mine from a year ago seems relevant to some of what is being said.

  1. A vendor has been put at a competitive disadvantage because they do not have FIPS 140 validation. Perhaps their competitors have it. Perhaps a bid requires it. Whatever the case may be, they don’t have it, so now they want to tear it down.

    Also found here are people that just dislike FIPS 140 or, perhaps, standards in general.

  2. A vendor has gone through the process, and it was quite painful. So, now they vent about all the changes they had to make, how silly particular requirements were, how incompetent the lab staff was, etc.
  3. An expert tells stories of how the requirements are ambiguous and the labs all vary in how they interpret the requirements.

    Also found here (and often quite different from the previously described expert) are people that have run into FIPS a number of times over the years, which has caused them exposure to differing requirements without having seen the evolution of those changes.

In that lengthy post, I discuss some points often causing pain.

  1. Vendor misunderstanding of the FIPS 140 requirements and terminology.
    [...]
  2. Vendor misinterpretation of lab (or NIST/CSE) questions and issues.
    [...]
  3. Labs can, and do, make requests and recommendations.
    [...]
  4. New labs, new lab staff, new technologies, and new revisions of FIPS 140 (and related) standards can make for created requirements. (This is where you can find the most variation among labs.)
    [...]

Anyway, I think a couple of additional points might be relevant to some of what I read in the latest SAAG thread.

First, I don’t think the concept of failure in a FIPS validation effort is quite so rigid as is being implied in parts of the SAAG discussion. During a FIPS validation effort, the lab (during testing) or NIST/CSE (during review) may bring up issues that a vendor has to address. These issues are often areas in which the module may be failing to meet particular FIPS requirements. This does not mean the module “fails,” it just means that the issues raised must be addressed before the module “passes.” In general, issues often boil down to some of the following:

  1. Clarification - the issue raised is just seeking some short clarification about the product’s workings and/or how a requirement is met. A quick written or verbal response (e.g., answering a question) can often be enough.
  2. Documentation - the issue raised is about incorrect, confusing, or incomplete documentation. Modifying the documentation is normally the fix here. (Even though what follows in 3 is often what vendors dread most, 2 can also lead to much pain if the lab starts questioning technical aspects of the product and heads down all sorts of testing paths that would otherwise have been avoided (i.e., prepare documentation that gives the lab what it needs in an easy to use form).)
  3. Technical - the issue raised is actually a technical problem with the product in regards to meeting the requirements. Here is where the product itself may have to be modified, and this is what most vendors want to avoid once they are knee deep in the validation (i.e., get the product meeting the requirements before the lab testing gets underway).

In all three cases, the “failure” can be corrected and the product can continue on with its validation. Depending on the issues raised, labs will often continue working on the validation effort in other areas while the vendor is working on addressing the issues; however, there is, of course, a point where the lab will need certain issues addressed before being able to move forward - this is where the third case can be especially problematic.

Second, this brings us to the “restarting” portion of the discussion in that thread. In general, if the issues raised can be addressed in a timely manner and based on the version of the product at that moment going through validation, then there should be no “restart” issue. However, if the issues raised take a long time for the vendor to fix and/or require a switch in the version of the product such that the new version includes a large number of other changes in the product (e.g., a switch to a new version of the product with a whole suite of new features), this could cause a “restart.” I generally think of these restarts coming in these two forms.

  1. The lab can no longer move forward with the effort while waiting on the vendor to address issues, so the project is put on hold. Depending on time frame here, lab resources will be moved elsewhere and lab knowledge of the product will deteriorate. When the vendor is ready to start back up, the lab has to restaff the effort, rebuild its knowledge of the product and the validation effort, and generally kick things off again.
  2. The changes were rolled into a new version of the product, and this new product is dramatically changed from the one that began the validation effort. The lab will have to figure out what has changed and determine how much of their work performed to this point can be reused, much like in a revalidation scoping but more awkward. If this is in combination with 1, this could get close to starting over.

Needless to say, you want to avoid going down this road.

-

Since I mentioned TrueCrypt in a previous post, look at this.

HotPlug allows you to seize and move a computer without losing power. (Video demos.) See also: MouseJiggler.

Yep, you guessed it.

How to circumvent Whole Disk Encryption
The key: Do not allow the encryption to activate. Low level encryption such as Vista’s Whole Disk Encryption (WDE) can halt an investigation. Use HotPlug and Mouse Jiggler to prevent encryption technologies from activating. If you can carry away the computer while it’s still logged in, you maintain full access to the hard drive.

In short, the plaintext key is often stored (cached), or authorization to access the plaintext key is stored (cached), in volatile memory (e.g., RAM) when using things like full disk encryption, so that data read from/written to disk can undergo transparent (to the user) processing. When the computer is powered down, goes to sleep, etc., assuming the hardware/software properly handles things, the (easy) access to the plaintext key is lost (e.g., the cached key or authorization to use the key is wiped). This gear is meant to prevent the circumstances that cause that wiping from happening.

Think of TrueCrypt - if you are using system disk encryption on your home desktop, then you know that, once you have entered your password at boot, the stored encrypted key is decrypted and the plaintext key is then stored in memory by TrueCrypt to transparently encrypt/decrypt data as it is written to/read from disk (i.e., you only enter your password once per boot). Anyone taking control of your desktop at that point has full access to your encrypted drive. However, if you pulled the plug, then the plaintext key would be lost. Well, this gear allows an attacker to grab your desktop and remove it from your home without it losing power (or hibernating).

-

Now this phenomenon sounds a little familiar.

Over 90% of people responded physically, for example with an exaggerated stare or a wave. Almost half responded verbally – more men than women. Here, says Professor Shuster, the sex difference was striking. 95% of adult women were praising, encouraging or showed concern. There were very few comic or snide remarks. In contrast, only 25% of adult men responded as did the women, for example, by praise or encouragement; instead 75% attempted comedy, often snide or combative as an intended put-down.

I mentioned this impact with regards to attire in this post.

(Side note, I have an old, bright red Futura t-shirt that says “For love or money”. With many, it generates mostly “for love!” comments and generally leads to conversation about values and the like. With others, it often inspires awkward mockery, as is the case with almost any loud attire.)

The “others” here are generally straight men showing negative interest, while the “many” are usually straight women or gay men showing positive interest. Perhaps this makes sense, as I am likely viewed as a potential rival to the former and a potential suitor to the latter.

Whatever the case may be, I always enjoy hacking peoples’ thoughts and behavior with something so simple as a t-shirt. As such, my custom t-shirts often play to this effect quite nicely.

-

Speaking of impact,

ABC2 has obtained new video of Baltimore police officer Salvatore Rivieri in action at the Inner Harbor. This time he confronts Billy Friebele, an artist from Washington D.C., who was videotaping at the Harbor last summer.

Friebele told ABC2 he was taping the reactions of passersby to a box he was moving with a remote controlled car. Officer Rivieri is seen on tape kicking the box off of the car and then kicking the car. The officer then orders Friebele to leave the area.

Small world. I knew Billy back in college.

gutsy ossl padlock, conversations, truecrypt 5.0

Thursday, February 7th, 2008

So, enabling Via padlock support on my Ubuntu Gutsy system with the default kernel was kind of, well, trivial. I just configured the relevant kernel modules to be loaded at boot, which involved editing “/etc/modules.conf” and inserting “padlock_aes”, “padlock_sha”, and “via_rng” entries.

With that done, I wanted to use the Via hardware RNG as an entropy source to “/dev/random”, so I installed “rng-tools”.

After that, I wanted to get the widest range of apps using OpenSSL to take advantage of the hardware crypto by default as easily as possible, for which I came back to this page a bunch of times. This patched started me off in one direction, and I ended up heading down the path of the “devcrypto” sort of hack already in the OpenSSL code base.

So, I ended up modifying “crypto/engine/eng_all.c” (and “crypto/engine/engine.h” for the prototype) to add a separate setup function (similar to what was there for “devcrypto”) to load padlock and set it as the default engine (BTW, the “set it as default” step should not be necessary - all it does is get padlock cached as the default engine for the supported algorithms now rather than later), and then I changed the “ssl/ssl_algs.c” “SSL_library_init” function and “crypto/evp/c_all.c” “OPENSSL_add_all_algorithms_noconf” function to call this padlock setup function, which should in theory cover the number of applications out there that call “OPENSSL_add_all_algorithms” and “OPENSSL_add_ssl_algorithms.” Also, I inserted a “ENGINE_cleanup” call into the “crypto/evp/names.c” “EVP_cleanup” function, although I am not sure this is necessary (or wise).

About the only thing annoying in the process was warnings of version information not being found in my OpenSSL shared libraries. I found this useful in fixing the issue.

(Oh, and apologies to my Tor server users, as my server was up and down quite a bit while I played with these things.)

-

A few quickly summarized conversations of possible interest to readers.

I was in a bar talking with a couple of people that were in the USA armed forces and about to go back to deployment in the Middle East. One thing they noted was that the only attack that really scared them when they first deployed over there was IEDs. They said that the fright factor came from the fact that IEDs were something for which they were not trained at the time, IEDs were an unknown. With an outright fire fight, with people firing at them, they knew what to expect; with IEDS, everything could be going as best it can for them over there and then, out of nowhere, boom, they were seriously maimed or dead. Both figuratively and literally, IEDs hit them totally out of the blue. However, with time and experience, IEDs have become a known and expected fact of life over there, something that can be dealt with both strategically and emotionally.

The conversation reminded me of topics like this article (the links I quickly turned up for that article require logins, free or otherwise - an excerpt is here).

Another important dimension of appraisal concerns potential actions: “What can be done about the situation?” Here, controllability and its prerequisite, the stimuli’s predictability, are critical: predictable and controllable adverse stimuli generate less fear, anxiety, and pain than unpredictable and uncontrollable stimuli.

Also, Ekman’s Emotions Revealed came to mind, where there is discussion of fear being influenced by three components - intensity, timing, and coping. Coping seems to be the key being discussed here - e.g., by knowing about the threat, strategies can be developed to reduce the risk posed by the threat, and thus reduce the strength of your fear.

Ok, moving along…

I was speaking with a LEO from the NYPD while waiting for a train. We got onto the topic of PBA cards, where I learned that such PBA cards can be tied to particular officers, which was new to me. The officer informed me that the higher the rank of the officer to which the PBA card is tied, the better the chance you have of getting a reduced charge or just being completely left off the hook when stopped by an officer for some offense. However, someone with me pointed out that this whole situation was not fair, that just knowing someone should not let you off the hook. The officer replied that this was not unfair, you just have to know someone. To this, my acquaintance said that was why it was unfair, because she didn’t known anyone, as was evidenced by her lack of names to drop when getting her second speeding ticket in a roughly two month period recently. The officer’s advice, get to know someone high up in the police force or, better yet, just stop speeding. (Of course, my acquaintance left out that she broke down and cried while getting that latest speeding ticket, and the officer subsequently lowered the speed indicated on the ticket by a number of miles.)

The conversation reminded of another conversation I had a while back with a friend of mine that was an academic. He was complaining that publishing papers in his field was as much about getting the right people to sign up as coauthors (regardless of any actual contribution to the research conducted in the paper) as it was about the research being published. He said the politics degraded the science, which seems similar to my acquaintance above pointing out the politics degrading (the fair application of) the law.

Regardless, the reality is clear - who you know matters. And, as often is the case, these discussions reminded me of Cialdini’s influence, such as the power of reciprocation, social proof, and authority.

-

The latest release of TrueCrypt 5.0 is available, including the use of the XTS mode of operation and whole disk encryption for Windows.

Ability to encrypt a system partition/drive (i.e. a partition/drive where Windows is installed) with pre-boot authentication (anyone who wants to gain access and use the system, read and write files, etc., needs to enter the correct password each time before the system starts). For more information, see the chapter System Encryption in the documentation. (Windows Vista/XP/2003)

XTS mode of operation, which was designed by Phillip Rogaway in 2003 and which was recently approved as the IEEE 1619 standard for cryptographic protection of data on block-oriented storage devices. XTS is faster and more secure than LRW mode (for more information on XTS mode, see the section Modes of Operation in the documentation).

Speed improvements on Windows, an OSX port, and SHA-512 support are also included in this release. Good stuff.

Most everywhere I tested out this release, it worked well, with one exception - an “Insufficient memory for encryption” error I ran into on one of my somewhat older systems. Looking around at a few forums (e.g., here) and at the TC code (e.g., “BootSector.asm”, “BootMain.cpp”, “BootDefs.h”), I don’t see a workaround for the system without modifying the TC code directly to correct/masked the issue. So, this will wait for a bugfix release.

On some systems, when performing the system encryption pretest, the TrueCrypt Boot Loader reports the following error: Insufficient memory for encryption. This issue will be addressed in the next version of TrueCrypt.

Update: To help with debugging the “Insufficient memory for encryption” bug, the TrueCrypt team is requesting your help.

[...]If you encountered this error, you can help us solve this issue by booting a special test ISO image, which displays the amount of free base memory on your system. To do so, please download this file, unpack it, and burn the extracted ISO image to a CD/DVD. Then restart your computer and boot from the CD/DVD. Write down the amount of free base memory displayed by the program and email it to us or include it in a bug report (in either case, make sure the subject is: ‘Base Memory Test Report‘). Thank you.

Update: TrueCrypt 5.0a was released today (2007-02-12). Among the changes

The memory requirements for the TrueCrypt Boot Loader have been reduced by 18 KB (eighteen kilobytes). As a result of this improvement, the following problem will no longer occur on most of the affected computers: The memory requirements of the TrueCrypt Boot Loader 5.0 prevented users of some computers from encrypting system partitions/drives (when performing the system encryption pretest, the TrueCrypt Boot Loader displayed the following error message: Insufficient memory for encryption).

I should note that one older system of mine mentioned above still fails to meet the memory requirements. Ah well.

Update: TrueCrypt 5.1 has been released.

What is new in TrueCrypt 5.1   (released March 10, 2008)

Included in the changes,

The minimum memory requirements for the TrueCrypt Boot Loader have been reduced from 42 KB to 27 KB (twenty-seven kilobytes). This allows users to encrypt system partitions/drives on computers where the BIOS reserves a large amount of memory. (Windows Vista/XP/2008/2003)

With that reduction, I can now use FDE on that problem machine noted above.

Also of note,

Increased speed of AES encryption/decryption (depending on the hardware platform, by 30-90%). (Windows)

Nice.

Quickies: fips, banks, misc.

Thursday, January 31st, 2008

I am caught up in a few things, but I thought some quickies might be nice.

***

Lets begin with sort of FIPS 140 news…

-

The FIPS 140-2 Implementation Guidance has been updated.

[01-24-2008] Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program [ PDF ] has been updated

New Implementation Guidance:

* 7.7 Key Establishment and Key Entry and Output

Updated Implementation Guidance:

* G.2 Completion of a test report: Information that must be provided to NIST and CSE
o Added reference to CMVP comments document.
* G.8 Revalidation Requirements
o Added reference to the CMVP FAQ in change scenario 1.

[01-16-2008] Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program [ PDF ] has been updated

Updated Implementation Guidance:

* G.13 Instructions for completing a FIPS 140-2 Validation Certificate
* 1.8 Listing of DES Implementations
* 7.1 Acceptable Key Establishment Protocols
* 9.4 Cryptographic Algorithm Tests for SHS Algorithms and Higher Cryptographic Algorithms Using SHS Algorithms

There are two key updates to look at here, which finally explain in public, written form what has been lore for quite some time.

The new 7.1 IG provides a detailed explanation the key distribution versus key input/output for FIPS 140-2. I can’t say the explanation is the friendliest, but it is good to see the information out there now.

The update to 7.7 basically finishes the translation of the key establishment requirements into something concrete. And, Appendix D now points here.

Also, I always assumed what the change to 9.4 specifies, but I guess this wasn’t explicit until now.

-

An update to the SHA3 candidate implementation C API has been published by NIST.

Revision 3: January 24, 2008

This document specifies the ANSI C interface profile for implementations of SHA-3 candidate algorithms. C implementations shall support the syntax and parameterization of the interface profile messages as described in this API. The API consists of a few data definitions and one function to compute hashes. The function specified in this API has return values listed that are largely used to supply error codes in the event of incomplete execution of the routine. The error values listed are not meant to be an exhaustive list. If additional error codes are useful for your implementation, please provide them.


Update: I figured I would insert this here, rather than in a separate post.

Submissions for the NIST SHA-3 contest are required to include test vectors that can be used to help to verify the correctness of implementations of the candidate algorithms. A specification has been published with the requirements.

Each submission package is required to include Known Answer Test (KAT) and Monte Carlo Test (MCT) values, which can be used to determine the correctness of an implementation of the candidate algorithm. Values shall be included (at a minimum) for each of the four minimum required hash sizes: 224, 256, 384, and 512-bits.

These KAT and MCT tests are based on tests specified in The Secure Hash Algorithm Validation System (SHAVS) [SHAVS], which describes tests for the SHA-2 family of hash functions. Each of the tests for which values are required in the submission packages is described below. In addition, example files are included which specify the exact syntax and format that submitters are required to use when submitting their KAT and MCT values.

Anyone that has undergone algorithm testing for SHA-1 or any of the SHA-2’s will be familar with these types. However, there is an additional test added into the mix, besides the usual SMTs, LMTs, and MCTs.

To test an algorithm’s ability to process messages longer that 232-bits in length, the candidate must supply a message digest for one extremely long sequence. The sequence is a 64-byte character string repeated 16,777,216 times. The message will be supplied in a file called ExtremelyLongMsgKAT_{Length}.txt for each of the required hash length.[...]

So, it looks like we will be running XLMTs in the future too.

(I guess while I am writing this, I should also note that the C API for candidate algorithm implementations has been updated since I wrote the initial post.)

-

Oh, and NIST is running a workshop on IBE.

June 3-4, 2008

This workshop brings together academia, government and industry to explore innovative and practical applications of pairing-based cryptography. Pairings have been used to create identity-based encryption schemes, but are also a useful tool for solving other cryptographic problems. We hope to encourage the development of new security applications and communication between researchers, developers and users. In addition to presentations, the workshop will facilitate panel discussions among invited experts and workshop participants.

***

Besides the many tumbles taking place, banks have had lots of security news of late…

-

Foiled, but popping through physical and people security is a favorite of mine.

The device, which police described as “sophisticated and requiring great (technical) skills,” had apparently been installed during a previous break-in, during which nothing had been stolen from the bank.

-

It looked like looking the part struck again at a bank.

On Wednesday, a man dressed as an armored truck employee with the company AT Systems walked into a BB&T bank in Wheaton about 11 a.m., was handed more than $500,000 in cash and walked out, a source familiar with the case said.

It wasn’t until the actual AT Systems employees arrived at the bank, at 11501 Georgia Ave., the next day that bank officials realized they’d been had. “When the real security guards showed up is when it became known,” said Richard Wolf, a spokesman with the FBI’s Baltimore division.

Or not. Now, it sounds like an insider job.

Assistant State’s Attorney Marybeth Ayres named Elizabeth K. Tarke, a teller at the BB&T branch, as a possible ringleader. Detectives have linked Tarke with Thursday’s theft at a Wachovia branch in the District, Ayres said.

Detectives talked to other employees and grew dubious about Tarke’s story, Pak wrote. Other employees said they saw no “AT” patch on the man’s clothing, just an all-black outfit, with a black hat, gun belt and semiautomatic handgun. They also didn’t see a badge, Pak wrote. Bank video corroborated their accounts, according to the charging documents.

-

Speaking of insiders at a financial (and ignoring write-down scapegoat theories for the moment), this sounds stunning.

The bank identified the trader as Jerome Kerviel. Mr. Kerviel, 31, joined Societe Generale in August 2000 and was working as a trader on the futures desk at the bank’s headquarter near Paris. He was in charge of futures hedging on European equity market indices, known as “plain vanilla” futures. The bank said he was able to dupe the bank’s own security system because he had inside knowledge of the control procedures gained from previous jobs with the bank.

Though Societe Generale says it first learned of what it termed “massive fraudulent directional positions” on Jan. 19, it waited until it could close out those trades before going public with the problem. Winding down the trades, the bank said, resulted in a €4.9 billion write-down, making it potentially the largest loss ever from an alleged rogue trader.

-

Somewhere else, a little online recon strikes at a bank.

A fraudster walked into a branch of Barclays Bank posing as its chairman Marcus Agius and managed to walk out with £10,000.

The conman is believed to have found Mr Agius’ details online and persuaded call centre staff into issuing a Barclaycard in his name.

***

Finally, some miscellaneous items…

-

I mentioned smell before. Well, here is some more.

After the men were allowed to change, 49 women sniffed the shirts and specified which odors they found most attractive. Far more often than chance would predict, the women preferred the smell of T-shirts worn by men who were immunologically dissimilar to them. The difference lay in the sequence of more than 100 immune system genes known as the MHC, or major histocompatibility complex. These genes code for proteins that help the immune system recognize pathogens. The smell of their favorite shirts also reminded the women of their past and current boyfriends, suggesting that MHC does indeed influence women’s dating decisions in real life.

And,

After the men were allowed to change, 49 women sniffed the shirts and specified which odors they found most attractive. Far more often than chance would predict, the women preferred the smell of T-shirts worn by men who were immunologically dissimilar to them. The difference lay in the sequence of more than 100 immune system genes known as the MHC, or major histocompatibility complex. These genes code for proteins that help the immune system recognize pathogens. The smell of their favorite shirts also reminded the women of their past and current boyfriends, suggesting that MHC does indeed influence women’s dating decisions in real life.

Fear not would be social engineers, we already hack this system.

Since the 20th-century hygiene revolution and the rise of the personal-care industry, however, companies have pitched deodorants, perfumes, and colognes to consumers as the epitome of sex appeal. But instead of furthering our quest to find the perfect mate, such products may actually derail it, say researchers, by masking our true scent and making it difficult for prospects to assess compatibility. “Humans abuse body smell signals by hiding them, masking them, putting on deodorant,” says Devendra Singh, a psychologist at the University of Texas. “The noise-to-signal ratio was much better in primitive society.”

Oh, and don’t assume that smelling “good” is always the way to go. For example, say you want some space on a crowded subway.

-

Remember this?

The DHS is funding security audits of many commonly used pieces of open source software, as noticed by Schneier here and described in eWeek here, from which the following excerpt was taken.

If these [1,2] articles are about the same effort, apparently a bit of low-hanging fruit was removed as a result, as noted in this press release.

All the software scrutinised was found to have significant numbers of security flaws, Coverity said on Wednesday. Since 2006 the project has helped fix 7,826 open source flaws in 250 projects, out of 50 million lines of code scanned, the company said.

For instance, 236 flaws were uncovered in 450,000 lines of Samba code, of which 228 have been corrected.

So, now some open source projects are moving on to the next version Coverity’s static analysis tool.

Projects at rung 2 of the Scan ladder have access to a significant upgrade of Coverity Prevent. The first projects to use these new capabilities report a significant increase in the number of identified defects, with some finding as many as 100 new hard-to-find defects than identified in rung 1 of the Scan ladder.

Anyway, I have no idea of what significance the bugs detected by the scans were, but these extra eyes seem like a good thing in general, as does ~7800 less bugs in this open source software.

-

I found this article quite fun.

The study authors, Dr. Rachel C. Vreeman and Dr. Aaron E. Carroll, said that while doctors realize good medicine requires them to constantly learn new things, they often forget to reexamine their existing medical beliefs. “These medical myths are a lighthearted reminder that we can be wrong and need to question what other falsehoods we unwittingly propagate as we practice medicine,’’ wrote Dr. Vreeman and Dr. Carroll.

And the material from which the article was derived, from which I can quote a concise list of the “medical myths” explored.

  • People should drink at least eight glasses of water a day
  • We use only 10% of our brains
  • Hair and fingernails continue to grow after death
  • Shaving hair causes it to grow back faster, darker, or coarser
  • Reading in dim light ruins your eyesight
  • Eating turkey makes people especially drowsy
  • Mobile phones create considerable electromagnetic interference in hospitals.

“Food coma.”

-

Lastly, I poked my head in on this.

Replicant

Dates: January 10–February 9, 2008
Opening: February 17, 2008
Location: 526 West 26th Street – 4th Floor – Room 416 – New York, NY
Gallery Hours: Tuesday to Saturday 11 am – 6 pm and by appointment

Virgil de Voldère is proud to present Replicant, a group exhibition of four emerging artists. Rather than brood over a technocratic dystopia, herald clean utopian spaces, or take a reactionary stance on biological and environmental issues such as climate change and bioengineering, this exhibition explores potential futures in which imagination, adaptation, and creativity present a positive view of cultural and scientific progress. The artists—Ian Burns, Shane Hope, Gilles Rotzetter, and Scott Wolniak—are wildly divergent in their mediums and methods: the work is both outsourced and handmade, meticulous and low-tech, highly conceptual and grounded in materials.

If you go, I recommend bringing printout of the linked to page (or related) and plan on spending 10 minutes or so, as it is a small room/exhibition.

140 trends, zero, etc

Saturday, December 22nd, 2007

Holiday season is NYC can be a painful time of year, but not for the reasons of which most people think. You see, during the holiday season, any watering holes to which you regularly go will likely throw many a free drink at you. Which leads to a problem - you want to go to all these places and see everyone for the holidays, but you don’t want to end up being carried home. So, now you either turn down those drink gifts from those around you or you end up in a tortuous state the next morning, both of which can hurt.

Which is to say, on this home stretch of the holiday season here in the USA, I wish everyone a happy holidays!

A post to the SAAG mailing list of interest to the FIPS 140 readers.

This decade many global financial institutions (e.g. banks, insurance firms, credit unions, and so forth) have said that their commercial (re-)insurers are pressuring them to deploy only FIPS-140 compliant algorithms & modes.

In a growing number of cases, there is even pressure from insurers onto major commercial firms, particularly financial firms, to use only equipment (including ordinary routers and switches, not just “security appliances”) that actually has obtained a FIPS-140 approval for the cryptographic module inside.

Further, a number of governments other than the US government have declared that implementations using cryptographic modules that have been approved under FIPS-140 are also acceptable for deployment within their country or government or both. The number of countries in this group appears to be growing, and seems visibly larger now than 8 years ago.

These are trends that people in the FIPS 140 arena have been talking about for a while, and I know I have seen and been involved with them by virtue of having had a strong window into “the vendor going for FIPS 140 validation” perspective for quite some time now. It is interesting to read someone else’s encounters with these things in a public forum.

So, besides the normal USA government requirements, support of at least a FIPS-approved algorithm suite has become a baseline requirement found almost everywhere now when cryptography is used, and every so often you even see pushes for FIPS 140 validation outside of the USA government. Given that, it is commonplace these days for standards, products, and such utilizing cryptography to include support for a FIPS-approved algorithm suite. Doing so not only brings into use a very commonly deployed, rigorously studied, and well-known set of algorithms, but it also facilitates products implementing those standards, products, and such in being able to go through the FIPS 140 validation process at some point. This makes even more sense since many of the people working on standards, products, and such utilizing cryptography are employed by companies that have to play in the FIPS 140 arena, and so there is often thought given to the FIPS 140 “validatibility” of modules implementing these standards, derived from these products, and such.

With the widespread notoriety of many of the algorithms that get rolled into NIST standards causing tons of eyes to look over these standards very closely, and with things like AES and now the next SHA being derived from open international competitions not to mention modes of operation and such being submitted by the outside world, none of this should come as a surprise.

-

Also of possible interest to FIPS 140 readers, a couple [1, 2] of useful posts on Metzger’s cryptography mailing list on the old topic of how to prevent the compiler from potentially optimizing away your “zeroizing” memset call in C. The sort answer, take advantage of volatile.

An example of how GnuPG does this from [1],

  /* To avoid that a compiler optimizes certain memset calls away, these
     macros may be used instead. */
  #define wipememory2(_ptr,_set,_len) do { \
                volatile char *_vptr=(volatile char *)(_ptr); \
                size_t _vlen=(_len); \
                while(_vlen) { *_vptr=(_set); _vptr++; _vlen--; } \
                    } while(0)
  #define wipememory(_ptr,_len) wipememory2(_ptr,0,_len)

And, [2] points to this 2002 MSDN article on the topic.

-

Finally, random software that has been popping up on some mailing lists I follow.

I remember using Maple quite a bit in college.

SAGE.

Use SAGE for studying a huge range of mathematics, including algebra, calculus, elementary to very advanced number theory, cryptography, numerical computation, commutative algebra, group theory, combinatorics, graph theory, and exact linear algebra.

And, I did lots of Lisp there too.

Clojure.

Clojure is a dynamic programming language that targets the Java Virtual Machine. It is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language - it compiles directly to JVM bytecode, yet remains completely dynamic. Every feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection.

Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs.

Io.

Io is a small, prototype-based programming language. The ideas in Io are mostly inspired by Smalltalk (all values are objects), Self (prototype-based), NewtonScript (differential inheritance), Act1 (actors and futures for concurrency), LISP (code is a runtime inspectable/modifiable tree) and Lua (small, embeddable).

Wow, it’s been 10 years.

Nmap v4.50.

December 13, 2007 — Insecure.Org is pleased to announce the immediate, free availability of the Nmap Security Scanner version 4.50 from http://insecure.org/nmap/. Nmap was first released in 1997, so this release celebrates our 10th anniversary.

Quickies: ossl fips prng seeding, privoxy, gcm, hash stuff, misc

Monday, December 3rd, 2007

Ouch.

A significant flaw in the PRNG implementation for the OpenSSL FIPS Object Module v1.1.1 (http://openssl.org/source/openssl-fips-1.1.1.tar.gz, FIPS 140-2 validation certificate #733, http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#733) has been reported by Geoff Lowe of Secure Computing Corporation. Due to a coding error in the FIPS self-test the auto-seeding never takes place. That means that the PRNG key and seed used correspond to the last self-test. The FIPS PRNG gets additional seed data only from date-time information, so the generated random data is far more predictable than it should be, especially for the first few calls.

I updated this post accordingly.

[...]This means the PRNG is not reseeded after the KAT, so the PRNG ends up seeded with constant self-test values.

A couple of patches [1,2] are available for the OpenSSL FIPS module. The patches boil down to running FIPS_rand_method()->cleanup() after the PRNG KAT and then reseeding the PRNG.

-

In “related to Tor” news, this is a good write-up on recent vulnerabilities in what is often the default Privoxy configuration, including that shipped with the Tor bundle up until recently.

The installed ‘config.txt’ file (’config’ on Mac OS X) had the following option values set to 1:

  • enable-remote-toggle
  • enable-edit-actions

Additionally, on Windows the following option was set to 1:

  • enable-remote-http-toggle

Malicious sites (or malicious exit nodes) could include active content (e.g., JavaScript, Java, Flash) that caused the web browser to:

  • make requests through the proxy that causes Privoxy filtering to be bypassed or completely disabled>
  • establish a direct connection from the web browser to the local proxy and modify the user defined configuration values

It should be noted that these are not Tor specific attacks on Privoxy and you may want to disable these Privoxy configuration options even in non-Tor environments.

-

SP800-38D, specifying the GCM mode of operation, has been finalized.

Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC has been finalized. This Recommendation specifies and approves Galois/Counter Mode (GCM), an authenticated encryption mode of the Advanced Encryption Standard (AES) algorithm.

I remember superficially comparing GCM and CCM back a few years ago. Both seemed to have a push at NIST, but you knew CCM would go through the vetting process relatively quickly being a combined mode of what was already accepted while GCM would take a bit of time. Well, CCM has been approved for quite a while, and now GCM is finally there too.

-

These [1,2] have been making the rounds. More fun with MD5.

We announce two different Win32 executable files with different functionality but identical MD5 hash values. This shows that trust in MD5 as a tool for verifying software integrity, and as a hash function used in code signing, has become questionable.

We have used a Sony Playstation 3 to correctly predict the outcome of the 2008 US presidential elections. In order not to influence the voters we keep our prediction secret, but commit to it by publishing its cryptographic hash on this website. The document with the correct prediction and matching hash will be revealed after the elections.

-

Speaking of hashing, there is a mailing list for the NIST hash competition.

A hash-forum@nist.gov email mailing list has been established for dialogue regarding NIST’s Cryptographic Hash Workshops and Hash Algorithm Competition. It is an unmoderated mailing list; messages addressed to this list are immediately distributed to all the addresses on the list. Only members are allowed to post messages to the list; however, anyone who wishes to do so may add themselves to the list.

-

A location service by Google relying on cell towers to estimate your location when GPS is not available.

Why the uncertainty? The My Location feature takes information broadcast from mobile towers near you to approximate your current location on the map - it’s not GPS, but it comes pretty close (approximately 1000m close, on average). We’re still in beta, but we’re excited to launch this feature and are constantly working to improve our coverage and accuracy.

-

Finally, I found this somewhat interesting to me.

“The empirical fact is that people will often switch to strategies they never picked before. They couldn’t have learned these strategies by reinforcement” from experienced rewards, says Camerer. In these situations, people use imagined rewards, or rewards that could have been theirs, to guide their decision making. This process, called fictive learning, is similar to the emotion of regret. “Regret is essentially the bodily sensation or name we give to fictive learning when there was a better choice than the one we chose.”

data sets, walks, kdfs, banksy, odds

Wednesday, November 28th, 2007

I heard Lotus Cafe is gone. And, Rififi may not be happy either. Ah, old timers.

-

Say you have data set you wish to release for research purposes but you don’t want the individual people identified (e.g., a medical data base) and thus tied to particular sensitive attributes (e.g., medical conditions). So, you have this data set consisting of what you consider to be sensitive attributes (e.g., medical conditions) and non-sensitive attributes (e.g., social security number, date of birth, zip code). In order to anonymize the data, you strip out the attributes that serve as blatantly unique identifiers (e.g., names, social security numbers).

Now, there is an immediate issue here. The obvious identifiers have been removed, but lets say this data set also contains attributes (e.g., date of birth, zip code) that when linked to external information lead to the identification of particular individuals (e.g., there is only one person with a given birthday in a given zip code, and this information is readily available someone trying to identify that individual in the data set).

This is where k-anonymity comes in. Now, you have already identified the sensitive and non-sensitive attributes, and you have removed the outright identifiers. From the remaining set of non-sensitive attributes, you can then identify those attributes, which are called quasi-identifiers, that could be linked to individuals through correlation against external data sources.

Here we come to one of the key assumptions made in the k-anonymizing process - the sanitizer can identify the attributes in the data set that can be tied to other, external sources. Not only do they have to identify these attributes, but they also have to assess the level of resources required to use those attributes to penetrate the anonymity of the data set, and make judgment calls on modifying the data for anonymity and/or privacy versus the usefulness of the resulting data set. This is hard stuff.

You can see many issues with this assumption. Does the sanitizer really know what will be quasi-identifiers in a data set? Even if they do, are their judgments about the risk posed by those identifiers realistic? For example, the sanitizer might not know about various public records or even google. Another example, one may assume that only large governments would have access to name, date of birth, and zip code information for individuals. However, most of us have access to this information for at least out friends and family.

Anyway, once you have picked out the quasi-identifiers, you then ensure that at least k records in the data set possess the same set of values for quasi-identifiers (e.g., generalize the date of birth to be year of birth, such that at least 10 records turn up for all years of birth and zip code combinations). In other words, instead of being able to uniquely identify a unique record using particular values for the quasi-identifiers, one always ends up identifying a set of k records with any particular values for the quasi-identifiers (e.g., you pull up 10 records at least for every year of birth and zip code combination).

Important note for the paper that follows later in this post: You may be wondering, what happens when dealing with all these sparse data sets with long-tail distributions? For example, a particular attribute may have a large number of values that are unique or at least very minimally spread across records, which could mean huge impacts on the data set if these values were generalized or removed for k-anonymity purposes. Which means there may be a big trade-off between anonymity and/or privacy, and the usefulness of the data here, which will minimize k if not render k-anonymity infeasible in order to keep the data at all useful. And, it is notable that most transactions databases fall into this category (e.g., credit card records, amazon purchases).

But, say k-anonymity is reasonable for the data without too much loss of usefulness of the data. Great, that covers establishing the exact identity of records, but there is an issue here - we may still be able to tie sensitive attributes to individuals. For example, if the sensitive attributes you are trying to unlink from an individual are applicable to all of the k records pulled up by the quasi-identifiers (e.g., all 10 records have the same medical condition), then one can assume that the individual possesses this attribute even if they can’t uniquely identify which of the k records is that individual. Or, if one knows particular sensitive values do or do not apply to the individual, they can rule out those records, perhaps pinpointing the applicable value of the sensitive attribute for the individual concerned (e.g., the medical condition in the group is either a broken arm or severe depression, and one knows the individual does not have a broken arm).

Which leads to the concept of l-diversity, wherein a set of k records should have l number of values for sensitive attributes contained within it. Now, when one pulls up that set of k records, all of those records do not have the same sensitive values and, even if I know certain sensitive values to do/do not apply to the individual in question, there is potentially still a range of records with other values for sensitive attributes that are applicable, making it hard for me to establish exactly which values for the sensitive attributes apply to a particular individual.

l-diversity can result in the data set undergoing significant modifications. Like with k-anonymity, judgment calls must be made on privacy versus the usefulness of the data set.

But, say l-diversity is applicable to the data set without too much loss of usefulness of the data. Nice, but we may still have some semantic ties or non-uniformity that can be exploited. For example, if all the k records have some related values for the sensitive values (e.g., all the medical conditions were mental problems) while the overall data set covered a larger variety of values, then information is learned about the members of k. Or, if the sensitive attributes in k records have one of set of odds of having particular values (e.g., 75% of members have cancer), while in the overall data set the sensitive attributes have some set of odds (e.g., 10% of members have cancer), this can be used to reveal information about the set of k records distinguishable for the overall data set.

Which leads to t-closeness, wherein the distribution of values of sensitive attributes in a set of k records will mimic the distribution of those values across the whole data set within a range t.

t-closeness can result in the data set undergoing even major changes. Like with k-anonymity and l-diversity, judgment calls must be made on privacy versus the usefulness of the data set.

And so forth.

I typed out that summary because I just noted this paper interesting. [via what is left of the cypherpunks list]

We present a new class of statistical de-anonymization attacks against high-dimensional micro-data, such as individual preferences, recommendations, transaction records and so on. Our techniques are robust to perturbation in the data and tolerate some mistakes in the adversary’s background knowledge.
We apply our de-anonymization methodology to the Netflix Prize dataset, which contains anonymous movie ratings of 500,000 subscribers of Netflix, the world’s largest online movie rental service. We demonstrate that an adversary who knows only a little bit about an individual subscriber can easily identify this subscriber’s record in the dataset. Using the Internet Movie Database as the source of background knowledge, we successfully identified the Netflix records of known users, uncovering their apparent political preferences and other potentially sensitive information.

A few paragraphs of note…

Micro-data are characterized by high dimensionality and sparsity. Informally, micro-data records contain many attributes, each of which can be viewed as a dimension (an attribute can be thought of as a column in a database schema). Sparsity means that a pair of random records are located far apart in the multi-dimensional space defined by the attributes. This sparsity is empirically well-established [6, 4, 16] and related to the “fat tail” phenomenon: individual transaction and preference records tend to include statistically rare attributes.

This applies to most of those real-world databases out there containing information about us, which is something to note when policies say that information that could identify you has been removed from a data set before that data set is distributed.

Our de-anonymization algorithms are designed to work against databases that have been anonymized and “sanitized” by their publishers. The three main sanitization methods are perturbation, generalization, and suppression [23, 8]. Furthermore, the data publisher may only release a (possibly non-uniform) sample of the database. For example, he may attempt to k-anonymize the records, and then release only one record out of each cluster of k or more records.
If the database is released for collaborative filtering or similar data mining purposes (as in the case of the Netflix Prize dataset), the “error” introduced by sanitization cannot be large, otherwise its utility will be lost. We make this precise in our analysis. Our definition of privacy breach (see below) allows the adversary to identify not just his target’s record, but any record as long as it is sufficiently similar (via Sim) to the target and can thus be used to determine its attributes with high probability.

The tradeoff between privacy and/or anonymity, and usefulness comes into play, and the authors make sure to take advantage of it. The real-world is a fun place.

Moreover, the linkage between an individual and her movie viewing history has implications for her future privacy. In network security, “forward secrecy” is important: even if the attacker manages to compromise a session key, this should not help him much in compromising the keys of future sessions. Similarly, one may state the “forward privacy” property: if someone’s privacy is breached (e.g., her anonymous online records have been linked to her real identity), future privacy breaches should not become easier. Now consider a Netflix subscriber Alice whose entire movie viewing history has been revealed. Even if in the future Alice creates a brand-new virtual identity (call her Ecila), Ecila will never be able to disclose any non-trivial information about the movies that she had rated within Netflix because any such information can be traced back to her real identity via the Netflix Prize dataset. In general, once any piece of data has been linked to a person’s real identity, any association between this data and a virtual identity breaks anonymity of the latter.

Anonymity tends to be a one way street. This can be particularly dangerous when it comes to persistent pseudonyms.

We have presented a de-anonymization methodology for multi-dimensional micro-data, and demonstrated its practical applicability by showing how to de-anonymize movie viewing records released in the Netflix Prize dataset. Our de-anonymization algorithm works under very general assumptions about the distribution from which the data are drawn, and is robust to perturbation and sanitization. Therefore, we expect that it can be successfully used against any large dataset containing anonymous multi-dimensional records such as individual transactions, preferences, and so on.
An interesting topic for future research is extracting social relationships, networks and clusters from the anonymous records. This knowledge can be a source of information for further de-anonymization [13]. In the case of the Netflix Prize dataset, de-anonymization of individual records may also have interesting implications for winning the Netflix Prize. We discuss this briefly in appendix B.

Data is recorded, filtered, and mined. You, your actions are not random. There will be non-uniformity, patterns. Identities and attributes will always appear.

I tend to think pseudonymity is the best you get in practice, and even that is quite difficult.

-

So, a while back I wrote this.

Side note, this is even more interesting in combination with things like the reality it generally takes couples trying to have a baby on the average of a few months to achieve pregnancy. Such drawn out periods seems to protect against a number of attacks, such as misrepresentation and quick judgement - for example, it exposes potential mates that seem good at first glance but aren’t quite so good once a closer look is provided.

Fitting right in here, I noted this.

However, Provost and her colleagues say there is in fact no contradiction between this research and other studies, as they are investigating two different kinds of signal. The previous research investigating men’s response to fertile women focused on signals such as smells and facial expressions, which can only be detected at close range. That makes evolutionary sense, as it would benefit a woman to advertise her fertility to a man that she has decided is worth having children with and has therefore allowed to get close to her.

In contrast, men can pick up on the attractiveness of a woman’s walk from long distance, and it can therefore act as an unwitting signal to less appealing males who she might not want to choose. So the advantage of having a less sexy walk around the time of ovulation becomes clear: it allows a woman to hide her fertile period from undesirable men who might take advantage of her at that time.

-

I noticed this request.

As many of you know, NIST has specified two standard KDFs for use with key agreement algorithms (e.g., Diffie-Hellman or MQV) in NIST SP 800-56A. NIST is considering supplementing the 800-56A KDFs with a more broadly applicable KDF. In particular, NIST is considering a proposal for an HMAC-based KDF. Before committing resources to this effort, we would like to get a better handle on the requirements seen by protocol developers and evaluate the level of support for such a standard. We would also like to identify alternative designs that should be considered.

PBKDF2 (something you may already use possibly without knowing it) and S2V were pointed to in replies.

-

Look at that, Banksy in New York.

VANINA HOLASEK GALLERY·502 West 27TH Street New York, NY 10001 T: 212-367-9093

FOR IMMEDIATE RELEASE:
BANKSY DOES NEW YORK
DECEMBER 2ND – DECEMBER 29TH, 2007
OPENING RECEPTION: SUNDAY, DECEMBER 2ND, 1 PM -5 PM

BANKROBBER GALLERY, London, in collaboration with VANINA HOLASEK GALLERY, are pleased to present for the first time in New York, an exhibition of works by Banksy, on view from December 2nd through December 29th, 2007.

There may even be a comment on security in here.

He’s the maniac who got on the news for managing to smuggle one of his pieces of art into Tate Britain and embarrassed everyone because nobody seemed to notice…He’s the wit behind the stencilled “Mind the Crap” writing that appeared overnight on the steps to Tate Modern. He is the prankster who smuggled 500 alternative copies of the Paris Hilton CD into record stores. He is the subversive who placed a life-size replica of a Guantanamo Bay detainee in Disneyland. He’s the jester who gave LA a painted elephant. He is the trickster whose hoax cave painting of a man pushing a supermarket trolley sat in the British Museum unnoticed for three days. He is the infiltrator who disguised as a pensioner hung his perfectly framed pieces in the Metropolitan, MOMA, Brooklyn Museum and his “dead beetle with glued on sidewinder missiles and satellite dish” had pride of place in the Museum of Natural History NYC. Get the picture, get this. Banksy images are even being used to sell 900k condos in Williamsburg.

Anyway, there is a party Saturday (2007-12-01) night from 6-9pm at the gallery celebrating the opening. [via thisheartsonfire]

-

Finally, here are some generic odds.

The National Safety Council has been compiling and reporting on injury data every year since the 1920s. The table below was prepared in response to frequent inquiries to the Council concerning the odds of dying from or being killed by a specific incident or occurrence such as a lightning strike or a plane crash.

The odds given below are statistical averages over the whole U.S. population and do not necessarily reflect the chances of death for a particular person from a particular external cause. Any individual’s odds of dying from various external causes are affected by the activities in which they participate, where they live and drive, what kind of work they do, and other factors.