Schneier on Security
A blog covering security and security technology.
« Sending Coded Messages with Postage Stamps |
| Liars and Outliers News »
January 5, 2012
Newly Released Papers from NSA Journals
The papers are old, but they have just been released under FOIA.
Posted on January 5, 2012 at 6:28 AM
• 10 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
@I like to LOL!
I think that Bruce would be more impressed by a cpu-register-only implementation of twofish ;)
@ LOL and @kiwano
Here's an idea. Make a small chunk of RAM on a board that goes between the CPU and its socket. The CPU heat and the difficulty plus time of removing the heatsink might be effective.
@jammit - you can use the CPU cache for the crypt data but the only way to be sure is to disable access to the cache for anything else see http://frozencache.blogspot.com/
@NobodySpecial - In the old days when Intel introduced the 486, it was the first mass-market processor chip that included a cache - 8 kBytes to be exact. It turns out that the Dhrystone code could just fit into 8kB, and it was a relevant benchmark at the time. The processor had a "benchmark mode" that would simply hard-map the cache into the address space. Their code would load Dhrystone into that spot and then "start" the benchmark, giving them fantastic (for the time) performance on the first runthrough, no cache effects, etc.
Anyone know how big current encryption kernels are? Now that I think of it, the ability to hard-map a small amount of on-CPU RAM into the address space could these days be sold as a security initiative, instead of a way of cheating on benchmarks, like it was with the i486.
@I like to LOL! - this is similar to how the PS3 hypervisor does it's decryption of the OS in order to boot.
In the Cell processor that it uses, there's one small processing element (of the 7 or so that it has alongside the "main" CPU) that purely handles the decryption of the boot image. This processing element has the necessary keys and at no time do they leave this one processor, they never go to shared RAM and no other (more readily accessible) processor ever sees them.
Some (all?) x86 processors have debug modes accessible from the JTAG port. Using these debug modes you can single-step and read machine registers.
So TRESOR isn't all that much more secure.
Regarding the Pearl Harbor paper, it makes you wonder what will be published fifty years hence on 9/11.
Back when I was evaluating embedded processors (Late 1980s), the ability to map on-chip RAM to either cache or dedicated address-space was pretty common, for about the reason mentioned. Many tasks have a small "kernel" (in the more general than OS sense) that can benefit greatly from being "locked in cache".
This only applies, naturally, to systems and programming teams that don't think loading a couple gigs of shared libraries to put up a smiley face is OK.
"If we overclassify, we develop in people's minds a contempt for the classification rules, for if some items which are not secret at all are classified, it means that the whole system is nonsense". (Security in an Open Society; page 10 as numbered)
And that is the reason why a bunch of people from recent US administrations should be on trial together with Manning.
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.