gutsy ossl padlock, conversations, truecrypt 5.0
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.