-

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.

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

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 = 36⁸ possible passwords.

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

Looking at SP800-90, min-entropy, another measure of uncertainty, for a set of probabilities p₁,…,p_n is defined as H = -log₂(p_max), where p_max is the maximum p in p₁,…,p_n.

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 p_i for each digit of the password, and our Shannon H = -∑ p_i log p_i = -1 log 1 = 0 and our min-entropy H = -log₂1 = 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 = -∑ p_i log p_i = -((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 = -log₂(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/(36⁸)=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.

Now, “we all know” having sensitive conversations walking down the street in NYC is not necessarily the wisest thing to do; however, people tend to think it is acceptable when no one appears to be within direct earshot. But, in many places within NYC, apartment intercoms are within earshot. And, many intercoms give no indication of when “listen” is activated.

Sure, there are lots of ways to eavesdrop on public conversations, but intercoms are a quick and easy way for just about anyone living in an apartment in NYC to do a bit of local surveillance using a standard apartment feature available to them at this very moment. And, if you live in the financial district or some area full of well to do business or political people or what have you, there could be lots of potential to gather both dirt and confidential information via intercoms.

Anyway, it might be interesting to pull together a weekly or monthly or what have you podcast composed of, well, interesting conversations (or even video in some cases) captured via intercoms just to see the results. (Of course, before doing so, it would be good to find out if recording public conversations is legal in whatever jurisdiction the recording is taking place?)

On a side note, while “we all know” discussing or reading sensitive information does not mix with public places, it is still quite common for people to have sensitive conversations in public directly within earshot of others and read sensitive documents in public directly within eyeshot of others - for example, someone was reading a hard copy of a design spec for a financial management system, including the security section, on the train a couple of days ago in plain view (this particular instance stood out to me because the system was for a company I own stock in). In NYC, commuters seem to be particularly prone to exhibiting these behaviors, which gives rise to some potential recon options, like enlisting people that, say, ride the subway during rush hour to keep an ear/eye out for interesting information. That nifty cell phone might be of use here too.

Yes, still “keepin’ it old school” in 2008.

While this post was somewhat in good fun, it did bring to mind a conversation I had with a bartender back in DC a number of years ago about Romania. He told me that many talented techies there turn to computer crime and such because there are so few opportunities for them to use their skills in other ways. You know, as the economy slips in the USA, this type of situation may hit hard close to home - which could mean, say, HUMINT will be even cheaper and more plentiful (e.g., chat up a laid off employee), and so on.

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.

-

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.

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.

***

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.

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.

-

Ok, let me first get the disappointment out of the way - I don’t have any nightlife or other stories I want to write up this time.

That said, Pacha NYC does seem to be a topic of interest to many, as my thoughts on customer service there have attracted some attention. So, why not comment on the crowd?

As I stated before, Pacha is big and well-known, which means that lots of people go there and almost every one of them gets in. The result of this often seems to be that there are very positive, very negative, and a whole bunch of neutral people running around inside during peak time, which is to say, you may run into someone that makes you smile but you may also run into someone that makes you frown.

I guess I should qualify my terms a bit. My thoughts on positive, negative, and neutral in this context are something like follows.

• Positive - there to have fun; respectful; happy; enjoys the music; can handle a crowd.
• Negative - rude; angry; beligerent; incoherent; upset by a crowd.
• Neutral - just sort of there; meat market.

Now, there are three DJs that get me into Pacha routinely, Boris, Victor Calderone (VC), and Danny Tenaglia (dt), and so I will comment on the crowds for these three.

While the neutral people are hard to notice, the positive and negative people do make an impact and their concentrations tend to vary quite a bit across these three DJs when at Pacha. So, here is a breakdown of the crowd for each.

• Boris - Boris generally has a balanced mix of negative and positive people during peak. As after hours comes in, most negative people head out, leaving a much higher concentration of positive people to negative people, which means a good crowd for after hours.
• dt - During peak, the crowd at Tenaglia always seems to be at the extremes, having both the highest concentration of negative people and the highest concentration of positive people. However, once the party rolls over fully to after hours, the dt regulars tend to take over the place. Tenaglia has a “be yourself” and let others be themselves motto, which is something the dt regulars have adopted fully, meaning the crowd when after hours kicks into high gear is completely positive and absolutely perfect.
• VC - The crowd for Calderone from peak to finish always seems to have the lowest concentration of negative people and a high concentration of positive people. Once after hours kicks in, the few negative people tend to depart, leaving a great crowd.

Based solely on crowd, that makes the best bet to go to Pacha when VC is there; however, if you are a late-nighter (like me), then dt pulls ahead.

My recommendation though, forget the crowd, go for the music and fun, and focus on the after hours. All three of these guys play marathon sets (at least 8 hours long), and none of them really kick into high gear until at least 6AM.

-

So, I briefly mentioned height and the results of USA presidential elections in part of a ramble.

We can play with features here too. Take height, which can both play a role in being judged beautiful and has strong ties to being perceived as a leader. Perhaps this is because physical size played an important role in being a leader way back when and helped with survival. Whatever the cause, there are some interesting statistics about height and power. Just look at the heights of US presidents in general (and even as compared to their opponents - probably one of the best ways to pick which candidate will win an election). And, how tall are the CEOs of major corporations on average?

Now, I did not qualify “best” in that comment at all and intended it to be a bit humorous, but the end result may be an incorrect statement. Of course, the general point was to show the influence of physical attributes on our perceptions of people, not to actually mean the most effective way to predict the results of a USA presidential election is answering the question “which candidate is taller?” Nevertheless, I have since changed that statement to avoid additional headaches.

Looking at Wikipedia, there is a discussion of the topic here, which gives the heights of the USA presidents and is summed up as follows.

In reality, for the 46 elections in which the height of which both candidates is known, the taller candidate won 25 times (approximately 54 percent of the time), the shorter candidate won 18 times (approximately 39 percent of the time) and the candidates were the same height three times (about 7 percent of the time).[original research?] Therefore, the taller candidate has won the majority of elections, but the tall-short margin of victory is by no means overwhelming.

It should be noted however that in three of the cases where the shorter candidate won, the taller candidate actually received more popular votes but lost in the Electoral College; this happened in 1824, 1888, and 2000 (the other time that the electoral vote winner was not the popular vote winner was in 1876, for which we do not know the height of the loser).[original research?] So of the 46 cases we have data, the taller candidate has won the popular vote 28 times (61 percent), and the shorter candidate only about 15 times (33 percent of them).

I have no idea if the height information is accurate, but, if it is, this boils down to the following… In USA presidential elections where we know height was different, 58% of the time the taller candidates won the election, and 65% of the time they won the popular vote. Since 1900, in USA presidential elections where we know height was different, 65% of the time the taller candidates won the election, and 69% of the time they won the popular vote.

Clearly, those odds favor the taller candidate, so height is a simple, physical appearance based metric to pick the winner of a USA presidential election with greater than coin flip odds. This seems to make sense, as height is an aspect of physical appearance that effects peoples’ judgments of leadership capabilities. But, let’s look at another aspect of physical appearance that probably shines through better than height in many media used today - faces.

So, we have this paper.

Human groups are unusual among primates in that our leaders are often democratically selected. Faces affect hiring decisions and could influence voting behavior. Here, we show that facial appearance has important effects on choice of leader. We show that differences in facial shape alone between candidates can predict who wins or loses in an election (Study 1) and that changing context from war time to peace time can affect which face receives the most votes (Study 2). Our studies highlight the role of face shape in voting behavior and the role of personal attributions in face perception. We also show that there may be no general characteristics of faces that can win votes, demonstrating that face traits and information about the environment interact in choice of leader.

With the results…

Feeding this percentage into the regression models, we found that the models predicted a win for Blair in terms of both popular vote (53.17%) and seats won (56.6%).

Our predictions were relatively accurate, as Blair won 52.13% of the actual two-way share of the popular vote and 64.3% of the split in seats won[...]

The final polling revealed, from a 99% return for the two candidates, that Bush had 51% and Kerry had 48% of votes, very similar to the 56%/44% split here when judges were asked which face they would vote for as the leader of their country.

And this paper.

Here we show that rapid judgments of competence based solely on the facial appearance of candidates predicted the outcomes of gubernatorial elections, the most important elections in the United States next to the presidential elections. In all experiments, participants were presented with the faces of the winner and the runner-up and asked to decide who is more competent. To ensure that competence judgments were based solely on facial appearance and not on prior person knowledge, judgments for races in which the participant recognized any of the faces were excluded from all analyses. Predictions were as accurate after a 100-ms exposure to the faces of the winner and the runner-up as exposure after 250 ms and unlimited time exposure (Experiment 1). Asking participants to deliberate and make a good judgment dramatically increased the response times and reduced the predictive accuracy of judgments relative to both judgments made after 250 ms of exposure to the faces and judgments made within a response deadline of 2 s (Experiment 2). Finally, competence judgments collected before the elections in 2006 predicted 68.6% of the gubernatorial races and 72.4% of the Senate races (Experiment 3). These effects were independent of the incumbency status of the candidates. The findings suggest that rapid, unreflective judgments of competence from faces can affect voting decisions.

Great, so now we have evidence that facial appearance impacts how we rate someone as a leader too, and this can be used to predict election results. (All of which is right in line with the original ramble.)

So, lets reduce all of this height and face stuff down to the level of picking candidates by answering a simple question, such as our “who is taller?” question.

Perhaps a just as simple and maybe better way to pick who will be elected president than answering “who is taller?” is to answer this more general question - who best looks the part? (A little lamination goes a long way. ) And, of course, a consensus answer gives better results than each individual answer here.

Which might also be in line with this other paper.

The current study examined whether desired personality influences face preference. Pairs of composite faces were made based on the faces that individuals differing in desired partner personality found most attractive. One composite represented a face most attractive to those desiring a particular trait and the other a face most attractive to those not desiring the same trait. Pairs were presented to different participants to ascertain whether the composites reflected the desired personality of the original raters. For several traits the composites did differ in perceived personality indicating that the personality desired in a partner is reflected in face preference: if a trait is desired then faces perceived to possess that trait are found more attractive than faces which do not possess that trait. These findings cast new light on the ‘‘what is beautiful is good’’ stereotype. What an individual desires in partner reflects what they consider ‘‘good’’, and they find faces reflecting these desired traits as attractive – ‘‘what is good is beautiful’’. Possessing personality traits that are attractive may be causal in making a face attractive.

What is good is beautiful, or what is beautiful is good? However you look at it then beauty is good.

But, when do we start to recognize beauty and judge people as attractive or not?

Like adults, young infants prefer attractive to unattractive faces (e.g. Langlois, Roggman, Casey, Ritter, Rieser-Danner & Jenkins, 1987; Slater, von der Schulenburg, Brown, Badenoch, Butterworth, Parsons & Samuels, 1998). Older children and adults stereotype based on facial attractiveness (Eagly, Ashmore, Makhijani & Longo, 1991; Langlois, Kalakanis, Rubenstein, Larson, Hallam & Smooth, 2000). How do preferences for attractive faces develop into stereotypes? Several theories of stereotyping posit that categorization of groups is necessary before positive and negative traits can become linked to the groups (e.g. Tajfel, Billig, Bundy & Flament, 1971; Zebrowitz-McArthur, 1982). We investigated whether or not 6-month-old infants can categorize faces as attractive or unattractive. In Experiment 1, we familiarized infants to unattractive female faces; in Experiment 2, we familiarized infants to attractive female faces and tested both groups of infants on novel faces from the familiar or novel attractiveness category. Results showed that 6-month-olds categorized attractive and unattractive female faces into two different groups of faces. Experiments 3 and 4 confirmed that infants could discriminate among the faces used in Experiments 1 and 2, and therefore categorized the faces based on their similarities in attractiveness rather than because they could not differentiate among the faces. These findings suggest that categorization of facial attractiveness may underlie the development of the ‘beauty is good’ stereotype.

Which brings us to this major work that pulls together of a wealth of studies.

Common maxims about beauty suggest that attractiveness is not important in life. In contrast, both fitness-related evolutionary theory and socialization theory suggest that attractiveness influences development an