Subscribe via Email

Subscribe via RSS


Recent Posts

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

KiTTY with Fedora 22/ OpenSSH 6.9 gives a blank screen and hangs

The KiTTY SSH client for Windows gives a blank screen and hangs when connecting to my Fedora 22 box (which runs OpenSSH 6.9). KiTTY is a fork of PuTTY, which I am happy with, so there’s no particular reason for me to use KiTTY except that I am checking it out.

kitty hungAfter a while it gives an error that the server closed the connection.

kitty fatalI have an Ubuntu Server 14.10 and CentOS 6.7 and KiTTY works fine with them. So it seems to be related to the version of OpenSSH in Fedora 22.

Fedora 22 logs show entries like these:

Looks like key-exchange was failing?


Note to self: An alternative command syntax to the above is this:

I also noticed that including SELinux in the output gave a bit more info. Not that it helped but it’s worth mentioning here as a reference to myself. For that I include the sshd.service unit and also the SELinux context for SSHD.

Tip: After typing journalctl it is possible to keep pressing TAB to get the fields and their values. That’s how I discovered the SSHD context above.

On the topic of journalctl: this intro post by its creator and this DigitalOcean tutorial are worth a read.

Another useful tip with journalctrl: by default it doesn’t wrap the output but you can scroll left and right with the keyboard. This isn’t useful when you want to copy-paste the logs somewhere. The work-around is to use the --no-pager switch so everything’s dumped out together and then pipe it into less which wraps the text:


I turned on SSH packet and raw data logging in KiTTY.

kitty logginFrom the log files I could see a sequence of events like this:

And with that it stops. So it looked like the DH Key Exchange was failing. Which confirms what I saw on the server side too.

SSH protocol 2 supports DSA, ECDSA, Ed25519 and RSA keys when clients establish a connection to the server. However, the first step is a Key Exchange for forward-secrecy and for this the DH algorithm is used.  From the sshd(8) manpage:

For protocol 2, forward security is provided through a Diffie-Hellman key agreement.  This key agreement results in a shared session key.  The rest of the session is encrypted using a symmetric cipher, currently 128-bit AES, Blowfish, 3DES, CAST128, Arcfour, 192-bit AES, or 256-bit AES.  The client selects the encryption algorithm to use from those offered by the server.  Additionally, session integrity is provided through a cryptographic message authentication code (hmac-md5, hmac-sha1, umac-64, umac-128, hmac-ripemd160, hmac-sha2-256 or hmac-sha2-512).

From the sshd_config(5) manpage:

The supported algorithms are:

The default is:,

The KexAlgorithms option can be used to change this but the point is all these are variants of the DH algorithm.

KiTTY has the following algorithm selection options:

kitty options

For protocol 2 only the first three (Diffie-Hellman options) apply. The fourth one (RSA-based key exchange) only applies for protocol 1. Comparing this with the preferred order for OpenSSH only the first and second options are common:

  • Diffie-Hellman group exchange (a.k.a. diffie-hellman-group-exchange-sha256)
  • Diffie-Hellman group 14 (a.k.a. diffie-hellman-group14-sha1)

Of these the second one (diffie-hellman-group14-sha1) is the older one. It is defined in RFC 4253. This RFC defines two key exchange algorithms: diffie-hellman-group14-sha1 and diffie-hellman-group1-sha1. (The group number defines the number of bits in the key. Group 1 has 768 bits, group 14 has 2048 bits. Larger is better). (Correction: Turns out diffie-hellman-group1-sha1 is actually Group 2).

The key exchange algorithms of RFC 4253 are updated via RFC 4419 – which defines two additional algorithms: diffie-hellman-group-exchange-sha1 and diffie-hellman-group-exchange-sha256. I am not very clear about these but it looks like they remove any weaknesses to do with groups that define the fixed number of bits and introduces the ability for the client and server to negotiate a custom group (of 1024 – 8192 bits). From RFC 4419:

Currently, SSH performs the initial key exchange using the “diffie-hellman-group1-sha1” method [RFC4253].  This method prescribes a fixed group on which all operations are performed.

The security of the Diffie-Hellman key exchange is based on the difficulty of solving the Discrete Logarithm Problem (DLP). Since we expect that the SSH protocol will be in use for many years in the future, we fear that extensive precomputation and more efficient algorithms to compute the discrete logarithm over a fixed group might pose a security threat to the SSH protocol.

The ability to propose new groups will reduce the incentive to use precomputation for more efficient calculation of the discrete logarithm.  The server can constantly compute new groups in the background.

So, to summarize: the common algorithms between KiTTY and OpenSSH are diffie-hellman-group-exchange-sha256 and diffie-hellman-group14-sha1. By default the preferred order between KiTTY client and OpenSSH server are in the order I specified above. In terms of security diffie-hellman-group-exchange-sha256 is preferred over diffie-hellman-group14-sha1. For some reason, however, KiTTY breaks with the newer version of OpenSSH when it comes to this stage.

Since diffie-hellman-group-exchange-sha256 is what both would be using I changed the preferred order on KiTTY such that  diffie-hellman-group14-sha1 is selected. 

kitty orderOnce I did that KiTTY connected successfully with OpenSSH – so that worked around the problem for now albeit by using a weaker algorithm – but at least it works. I wonder why diffie-hellman-group-exchange-sha256 breaks though.

I downloaded the latest version of PuTTY and gave that a shot with the default options (which are same as KiTTY). That worked fine! From the PuTTY logs I could see that at the point where KiTTY failed PuTTY manages to negotiate a key successfully:

Comparing the configuration settings of PuTTY and KiTTY I found the following:

putty fix

If I change the setting from “Auto” to “Yes”, PuTTY also hangs like KiTTY. So that narrows down the problem. RFC 4419 is the one I mentioned above, which introduced the new algorithms. Looks like that has been updated and KiTTY doesn’t support the new algorithms whereas PuTTY is able to.

PuTTY’s changelog didn’t have anything but its wishlist contained mention of what was going on. Apparently it isn’t a case of an update to RFC 4419 or any new algorithms, it is just a case of OpenSSH now strictly implementing the message format of RFC 4419 and thus breaking clients who do not implement this yet. To understand this have a look at this bit from the log entries of PuTTY and KiTTY at the point where KiTTY fails:

Pretty identical except for the type number. KiTTY uses 30 while PuTTY now uses 34. If you look at RFC 4419 these numbers are defined thus:

The following message numbers have been defined in this document.

They are in a name space private to this document and not assigned by IANA.

     #define SSH_MSG_KEX_DH_GEX_REQUEST      34
     #define SSH_MSG_KEX_DH_GEX_GROUP        31
     #define SSH_MSG_KEX_DH_GEX_INIT         32
     #define SSH_MSG_KEX_DH_GEX_REPLY        33

SSH_MSG_KEX_DH_GEX_REQUEST_OLD is used for backward compatibility. Instead of sending “min || n || max”, the client only sends “n”.  In addition, the hash is calculated using only “n” instead of “min || n || max”.

So RFC 4419 has updated the type number to 34 and set aside 30 for backward compatibility. Ideally clients should be sending type number 34 as their request. From the PuTTY wishlist link I saw the OpenSSH commit that removed the server from accepting type 30 any more. That’s why KiTTY was breaking, while PuTTY had updated their message type to the correct one and was successfully connecting! :)

(While digging around I saw that WinSCP too is (was?) affected.)

FYI: Self Encrypting Drives must be uninitialized for BitLocker Hardware encryption

Got myself a new 1TB Crucial MX200 SSD today. This is a Self Encrypting Drive like my other SSDs. When I tried enabling BitLocker on it as I usually do, I noticed that it was asking me about how to encrypt the drive and taking more time with the encryption than I have seen in the past with SED drives that support the TCG OPAL standard. 

Not good if you get this screen!

Not good if you get this screen!

Something was not right. So I went back to Microsoft’s page on BitLocker and SEDs and noticed that one of the requirements was that the drive must be uninitialized! Damn! In the past I usually enable encryption and then copy over data, but today I had copied the data first (thus initializing the drive and creating partitions) and then I was trying toe enable encryption. Obliviously that was a no-go so I had to copy the data out of the drive, uninitialize it, and then turn on BitLocker encryption. 

Uninitializing is easy via diskpart

Now Disk Management will show the disk as uninitialized. 


Create partitions as usual but before writing any data to the disk turn on BitLocker encryption. This time it will be a one-second operation and you won’t get a prompt like above. 

To confirm that the drive is hardware encrypted (in case you wonder whether BitLocker didn’t just zip through coz the drive had no data on it) use the manage-bde command:

As you can see the drive is hardware encrypted. 

[Aside] Everything you need to know about cryptography in 1 hour – Colin Percival

Good talk about crypto by Colin Percival. The talk is slightly less than 2 hours long (but that could be due to questions at the end – I don’t know, I am only 50 mins into it so far). 

A good talk. With a lot of humor in between. Only reason I decided to watch this video is because I follow Colin’s blog (or rather I try to follow – there’s a lot of crypto stuff in there that goes over my head). He was the FreeBSD Security officer when I was into FreeBSD and that’s how I started following his blog and became aware of him.  Am glad I am watching it though, it clarifies a lot of things I was vaguely aware of without going into too much details. I don’t think I’ll ever be doing programming that involves crypto, but it’s good to know and is an area of interest. 

Notes on Windows LSA, Secure Channel, NTLM, etc.

These are some notes to myself on the Windows security subsystem. 

On Windows, the Local Security Authority (LSA) is a subsystem that is responsible for security of the system. The LSA runs as a process called the LSA Subsystem Service (LSASS; you can find it as c:\Windows\System32\lsass.exe) and takes care of two tasks: (1) authentication and (2) enforcing local security policies on system.

For authentication the LSA makes uses of Security Support Providers (SSPs) that provide various authentication protocols. SSPs are Dynamic Link Libraries (DLLs) that offer the authentication protocol to applications that wish to make use of it. They expose a Security Service Provider Interface (SSPI) API which applications can make use of without knowing about the underlying protocol. (Generic Security Service Application Program Interface (GSSAPI or GSS-API) is an IETF standard that defines an API for programs to access security services. SSPI is is a proprietary variant of GSSAPI). 

In a way this post ties in with other things I have been reading about and posted recently. Stuff like encryption ciphers and Active Directory. On domain joined machines for instance, LSA uses Active Directory, while on non-domain joined machines LSA uses Security Accounts Manager (SAM). Either case the LSA is a critical component. 

It is possible to create custom SSPs to support new protocols. Microsoft includes the following SSPs (may not be an exhaustive list).

Kerberos (Kerberos.dll)

  • Provides the Kerberos authentication protocol. This is the protocol of choice in Windows. 
  • Kerberos cannot be used with non-domain joined systems. 
  • More about Kerberos in a later post. I plan to cover it as part of Active Directory. 

NTLM — LM, NTLM, and NTLMv2 (Msv1_0.dll)

  • Provides the NTLM authentication protocol.
    • LM == LAN Manager (also called as LAN MAN). It’s an old way of authentication – from pre Windows NT days. Not recommended any more. 
    • NTLM == NT LAN Manager. Is a successor to LM. Introduced with Windows NT. Is backward compatible to LAN MAN. It too is not recommended any more. It’s worth pointing out that NTLM uses RC4 for encryption (which is insecure as I previously pointed out).
    • NTLMv2 == NT LAN Manager version 2. Is a successor to NTLM. Introduced in Windows 2000 (and in Windows NT as part of SP4). It is the current recommended alternative to LM and NTLM and is the default since Windows Vista.
  • Although Kerberos is the preferred protocol NTLM is still supported by Windows.
  • Also, NTLM must be used on standalone systems as these don’t support Kerberos. 
  • NTLM is a challenge/ response type of authentication protocol. Here’s how it works roughly:
    • The client sends its username to the server. This could be a domain user or a local user (i.e. stored in the server SAM database). Notice that the password isn’t sent. 
    • To authenticate, the server sends some random data to the client – the challenge
    • The client encrypts this data with a hash of its password – the response. Notice that the hash of the password is used as a key to encrypt the data. 
    • If the username is stored in the server SAM database, the hash of the password will be present with the username. The server simply uses this hash to encrypt its challenge, compares the result with the response from the client, and if the two match authenticates the client. 
    • If the username is not stored in the server SAM database, it sends the username, the challenge, and response to a Domain Controller. The Domain Controller will have the password hash along with the username, so it looks these up and performs similar steps as above, compares the two results, and if they match authenticates the client.  
  • Here are some interesting blog posts on NTLM security:
    • NTLM Challenge Response is 100% Broken – talks about vulnerabilities in NTLM & LM, and why it’s better to use NTLMv2.
    • The Most Misunderstood Windows Security Setting of All Time – about the HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel registry key (mentioned in the above blog post too) which affects how Windows uses NTLMv2. By default Vista and above only send NTLMv2 reponses but accept LM, NTLM, and NTLMv2 challenges. This post also goes into how NTLMv2 performs the challenge/ response I mention above differently.
      • NTLMv2 uses a different hash function (HMAC-MD5 instead of MD4).
      • NTLMv2 also includes a challenge from the client to the server. 
      • It is also possible to use NTLM for authentication with NTLMv2 for session security.
    • Rehashing Pass the Hash – a blog post of Pass the Hash (PtH) which is about stealing the stored password hash (in memory) from the client and using that to authenticate as the client elsewhere (since the hash is equivalent to the password, getting hold of the hash is sufficient). This post also made me realize that LM/ NTLM/ NTLMv2 hashes are unsalted – i.e. the password is hashed and stored, there’s no extra bit added to the password before salting just to make it difficult for attackers to guess the password. (Very briefly: if my password is “Password” and its hashed as it is to “12345”, all any attacker needs to do is try a large number of passwords and compare their hash with “12345”. Whichever one matches is what my password would be! Attackers can create “hash tables” that contain words and their hashes, so they don’t even have to compute the hash to guess my password. To work around this most systems salt the hash. That is, the add some random text – which varies for each user – to the password, so instead of hashing “Password” the system would hash “xxxPassword”. Now an attacker can’t simply reuse any existing hashtables, thus improving security).
      • A good blog post that illustrates Pass the Hash.
      • A PDF presentation that talks about Pass the Hash.
      • Windows 8.1 makes it difficult to do Pass-the-Hash. As the post says, you cannot eliminate Pass-the-Hash attacks as long as the hash is not in some way tied to the hardware machine.
    • When you login to the domain, your computer caches a hash of the password so that you can login even if your Domain Controller is down/ unreachable. This cache stores an MD4 hash of the “MD4 hash of the password + plus the username”.
    • If all the above isn’t enough and you want to know even more about how NTLM works look no further than this page by Eric Glass. :)

Negotiate (secur32.dll)

  • This is a psuedo-SSP. Also called the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO). 
  • It lets clients and servers negotiate a protocol to use for further authentication – NTLM or Kerberos. That’s why it is a psuedo-SSP, it doesn’t provide any authentication of its own. 
  • Kerberos is always selected unless one of the parties cannot use it. 
  • Also, if an SPN (Service Principal Name), NetBIOS name, or UPN (User Principal Name) is not given then Kerberos will not be used. Thus if you connect to a server via IP address then NTLM will be used. 

CredSSP (credssp.dll)

  • Provides the Credential Security Support Provider (CredSSP) protocol. 
  • This allows for user credentials from a client to be delegated to a server for remote authentication from there on. CredSSP was introduced in Windows Vista.
  • Some day I’ll write a blog post on CredSSP and PowerShell :) but for now I’ll point to this Scripting Guy blog post that gives an example of how CredSSP is used. If I connect remotely to some machine – meaning I have authenticated with it – and now I want to connect to some other machine from this machine (maybe I want to open a shared folder), there must be some way for my credentials to be passed to this first machine I am connected to so it can authenticate me with the second machine. That’s where CredSSP comes into play. 
  • CredSSP uses TLS/SSL and the Negotiate/SPNGO SSP to delegate credentials. 
  • More about CredSSP at this MSDN article

Digest (Wdigest.dll)

  • Provides the Digest protocol. See these TechNet articles for more on Digest authentication and how it works
  • Like NTLM, this is a challenge/ response type of authentication protocol. Mostly used with HTTP or LDAP. 
  • There is no encryption involved, only hashing. Can be used in conjunction with SSL/TLS for encryption.

SChannel (Schannel.dll)

  • Provides the SSL/ TLS authentication protocols and support for Public Key Infrastructure (PKI). 
  • Different versions of Windows have different support for TLS/SSL/ DTLS because the SChannel SSP in that version of Windows only supports certain features. For instance:
  • More about SChannel at this TechNet page
  • Used when visiting websites via HTTPS.
  • Used by domain joined machines when talking to Domain Controllers – for validation, changing machine account password, NTLM authentication pass-through, SID look-up, group policies etc.
    • Used between domain machines and Domain Controllers, as well as between Domain Controllers. In case of the latter secure channel is also used for replication. Secure channels also exist between DCs in different trusted domain. 
    • Upon boot up every domain machine will discover a DC, authenticate its machine password with the DC, and create a secure channel to the DC. The Netlogon service maintains the secure channel. 
    • Every machine account in the domain has a password. This password is used to create the secure channel with the domain. 
      • Upon boot up every domain machine will discover a DC, authenticate its machine password with the DC, and create a secure channel to the DC. 
    • This is a good post to read on how to find if secure channel is broken. It shows three methods to identify a problem – NLTest, PowerShell, WMI – and if the secure channel is broken because the machine password is different from what AD has then the NLTest /SC_RESET:<DomainName> command can reset it.
      • A note on the machine password: machine account passwords do not expire in AD (unlike user account passwords). Every 30 days (configurable via a registry key) the Netlogon service of the machine will initiate a password change. Before changing the password it will test whether a secure channel exists. Only after creating a secure channel will it change the password. This post is worth reading for more info. These password changes can be disable via a registry key/ group policy
  • More on how SSL/TLS is implemented in SChannel can be found at this TechNet page.

OpenSSH and ECC keys (ECDSA)

Note to self: OpenSSH 5.7 and above support ECDSA authentication. As I mentioned previously, ECDSA is based on ECC keys. These are harder to crack and offer better performance as the key size is small. Here’s what I did to set up SSH keys for a new install of Git on Windows today:

The important bit is the -t ECDSA. The other two switches just specify a place to store the key as well as give it a description for my reference.

Notes on Cryptography Ciphers: RSA, DSA, AES, RC4, ECC, ECDSA, SHA, and so on …

I thought I should make a running post on cryptography ciphers (algorithms) and such. For instance, in my previous post I mentioned AES, EDH, etc. but that’s just the tip of the ice-berg as there are so many algorithms each suited for different tasks. As I come across these I’ll add them to this post as a quick reference to myself. 

Symmetric key algorithms (Private key cryptography)

Both parties share a private key (kept secret between them).

Symmetric key algorithms are what you use for encryption. F0r example: encryption of traffic between a server and client, as well as encryption of data on a disk. 

  • DES – Data Encryption Standard – designed at IBM
    • DES is a standard. The actual algorithm used is also called DES or sometimes DEA (Digital Encryption Algorithm). 
    • DES is now considered insecure (mainly due to a small key size of 56-bits). 
    • Triple DES (3DES) applies the DES algorithm thrice and thus has better practical security. It has 3 keys of 56-bits each (applied to each pass of DES/ DEA). 
    • DES-X is another variant. 
    • DES is a block cipher.
  • IDEA – International Data Encryption Algorithm
    • Considered to be a good and secure algorithm. 
    • Patented but free for non-commercial use. 
    • IDEA is a block cipher.
  • AES – Advanced Encryption Standard – is the successor to DES
    • AES is based on the Rijndael cipher. There was a competition to choose the cipher that will become the AES. The Rijndael cipher won the competition. However, there are some differences between Rijndael and its implementation in AES. 
    • Most CPUs now include hardware AES support making it very fast.
    • Supported by TrueCrypt, SSH. 
    • AES and Rjindael are block ciphers
    • AES can operate in many modes.
      • AES-GCM (AES operating in Galois/Counter Mode (GCM)) is preferred (check this blog post too). It is fast and secure and works similar to stream ciphers. Can achieve high speeds on low hardware too. Only supported on TLS 1.2 and above. 
      • AES-CBC is what older clients commonly use. AES-CBC mode is susceptible to attacks such as Lucky13 and BEAST.
      • See this answer for an excellent overview of the various modes. 
  • Blowfish – designed by Bruce Schneier as an alternative to DES; no issues so far, but can be attacked if the key is weak, better to use Twofish or Threefish.
    • Patent free. In public domain. 
    • Supported by SSH.
    • Much faster than DES and IDEA but not as fast as RC4.
    • Uses variable size keys of 32 to 448 bits. Considered secure. Designed for fast CPUs, now slower / old er CPUs.
    • Blowfish is a block cipher.
  • Twofish – designed by Bruce Schneier and others as a successor to Blowfish
    • Was one of the finalists in the AES competition
    • Most CPUs now include hardware AES support making it very fast than Twofish.
    • Patent free. In public domain.
    • Uses keys of size 128, 192, or 256 bits. Designed to be more flexible than Blowfish (in terms of hardware requirements). 
    • Supported by TrueCrypt, SSH. 
    • Twofish is a block cipher.
  • Threefish – designed by Bruce Schneier and others
  • Serpent – designed by Ross Anderson, Eli Biham, and Lars Knudsen
    • Was one of the finalists in the AES competition
    • Patent free. In public domain.
    • Has a more conservative approach to security than other AES competition finalists. 
    • Supported by TrueCrypt. 
    • Serpent is a block cipher.
  • MARS – designed by Don Coppersmith (who was involved in DES) and others at IBM
    • Was one of the finalists in the AES competition
  • RC6 – Rivest Cipher 6 or Ron’s Code 6 – designed by Ron Rivest and others
    • Was one of the finalists in the AES competition
    • Proprietary algorithm. Patented by RSA Security. 
    • RC5 is a predecessor of RC6. Other siblings include RC2 and RC4. 
    • More on RC5 and RC6 at this RSA link
    • RC5 and RC6 are block ciphers.
  • RC4 – Rivest Cipher 4, or Ron’s Code 4 – also known as ARC4 or ARCFOUR (Alleged RC4).

Asymmetric key algorithms (Public key cryptography)

Each party has a private key (kept secret) and a public key (known to all). These are used in the following way:

  • Public keys are used for encrypting, Private keys are used for decrypting. 
    • For example: to send something encrypted to a party use its public key and send the encrypted data. Since only that party has the corresponding private key, only that party can decrypt it. (No point encrypting it with your private key as anyone can then decrypt with your public key!)
  • Private keys are used for signing, Public keys are used for verifying. 
    • For example: to digitally sign something, encrypt it with your private key (usually a hash is made and the hash encrypted). Anyone can decrypt this data (or decrypt the hash & data and perform a hash themselves to verify your hash and their hash match) and verify that since it was signed by your private key the data belongs to you. 

These algorithms are usually used to digitally sign data and/ or exchange a secret key which can be used with a symmetric key algorithm to encrypt further data. They are often not used for encrypting the conversation either because they can’t (DSA, Diffie-Hellman) or because the yield is low and there are speed constraints (RSA). Most of these algorithms make use of hashing functions (see below) for internal purposes

  • RSA – short for the surnames of its designers Ron Rivest, Adi Shamir and Leonard Adleman
    • Not used to encrypt data directly because of speed constraints and also because its yield is small (see this post for a good explanation; also this TechNet article).
      • Usually RSA is used to share a secret key and then a symmetric key algorithm is used for the actual encryption. 
      • RSA can be used for digital signing but is slower. DSA (see below) is preferred. However, RSA signatures are faster to verify. To sign data a hash is made of it and the hash encrypted with the private key. (Note: RSA requires that a hash be made rather than encrypt the data itself).  
      • RSA does not require the use of any particular hash function. 
    • Public and Private keys are based on two large prime numbers which must be kept secret. RSA’s security is based on the fact that factorization of large integers is difficult. (The public and private keys are large integers which are derived from the two large prime numbers).
    • PKCS#1 is a standard for implementing the RSA algorithm. The RSA algorithm can be attacked if certain criteria are met so the PKCS#1 defines things such that these criteria are not met. See this post for more info. 
    • Was originally patented by the RSA but has since (circa 2000) expired. 
    • SSH v1 only uses RSA keys (for identity verification). 
  • DSA – Digital Signature Algorithm – designed by the NSA as part of the Digital Signature Standard (DSS)
    • Used for digital signing. Does not do encryption. (But implementations can do encryption using RSA or ElGamal encryption) 
    • DSA is fast at signing but slow at verifying
      • It mandates the use of SHA hashes when computing digital signatures. 
      • Unlike RSA which makes a hash of the data and then encrypts it to sign the message – and this data plus encrypted hash is what’s used to verify the signature – DSA has a different process. DSA generates a digital signature composed of two 160-bit numbers directly from the private key and a hash of the data to be signed. The corresponding public key can be used to verify the signature. The verifying is slow. 
      • A note about speed: DSA is faster at signing, slow at verifying. RSA is faster at verifying, slow at signing. The significance of this is different from what you may think. Signing can be used to sign data, it can also be used for authentication. For instance, when using SSH you sign some data with your private key and send to the server. The server verifies the signature and if it succeeds you are authenticated. In such a situation it doesn’t matter that DSA verification is slow because it usually happens on a powerful server. DSA signing, which happens on a relatively slower computer/ phone/ tablet is a much faster process and so less intensive on the processor. In such a scenario DSA is preferred! Remember: where the slow/ fast activity occurs also matters. 
    • DSA can be used only for signing. So DSA has to use something like Diffie-Hellman to generate another key for encrypting the conversation. 
      • This is a good thing as it allows for Perfect Forward Secrecy (PFS). 
        • Forward Secrecy => the shared key used for encrypting conversation between two parties is not related to their public/ private key.
        • Perfect Forward Secrecy => in addition to the above, the shared keys are generated for each conversation and are independent of each other. 
      • Also, because DSA can be used only for digital signatures and not encryption, it is usually not subject to export or import restrictions. Therefore it can be used more widely.
    • Patented but made available royalty free. 
    • DSA’s security is based on the discrete logarithm problem. 
    • Section of this article is worth a read. Since it’s designed by the NSA, DSA has some controversies. 
    • SSH v2 can use RSA or DSA keys (for identity verification). It prefers DSA because RSA used to be patent protected. But now that the patents have expired RSA is supported
    • RSA is supported by all versions of SSL/ TLS. 
    • DSA (and ECDSA) requires random numbers. If the random number generator is weak then the private key can be figured out from the traffic. See this blog post and RFC for good explanations. These StackExchange answers are worth a read too: 1, 2, and 3.
  • ECDSA – Elliptic Curve DSA
    • Variant of DSA that uses Elliptic Curve Cryptography (ECC).
    • ECC is based on Elliptic Curves theory and solving the “Elliptic Curve Discrete Logarithm Problem (ECDLP)” problem which is considered very hard to break
    • ECC keys are better than RSA & DSA keys in that the algorithm is harder to break. So not only are ECC keys more future proof, you can also use smaller length keys (for instance a 256-bit ECC key is as secure as a 3248-bit RSA key).
    • As with DSA it requires a good source of random numbers. If the source isn’t good then the private key can be leaked
    • Although the ECDLP is hard to solve, there are many attacks that can successfully break ECC if the curve chosen in the implementation if poor. For good ECC security one must use SafeCurves. For example Curve25519 by D.J. Bernstein
    • Used in Bitcoin and extensively in iOS for instance. Many web servers are adopting it too. 
  • ElGamal – designed by Taher ElGamal
    • Used by GnuPG and recent versions of PGP
    • Taher ElGamal also designed the ElGamal signature, of which the DSA is a variant. ElGamal signature is not widely used but DSA is. 
  • Diffie-Hellman (DH) – designed by Whitfield Diffie, Martin Hellman and Ralph Merkle
    • Does not do encryption or signing. It is only used for arriving at a shared key. Unlike RSA where a shared key is chosen by one of the parties and sent to the other via encryption, here the shared key is generated as part of the conversation – neither parties get to choose the key. 
    • Here’s how it works in brief: (1) the two parties agree upon a large prime number and a smaller number in public, (2) each party then picks a secret number (the private key) for itself and calculates another number (the public key) based on this secret number, the prime number, and the smaller number, (3) the public keys are shared to each other and using each others public key, the prime number, and the small number, each party can calculate the (same) shared key. The beauty of the math involved in this algorithm is that even though a snooper knows the prime number, the small number, and the two public keys, it still cannot deduce the private keys or the shared key! The two parties publicly derive a shared key such that no one snooping on their conversation can derive the key themselves. 
    • Has two versions:
      • a fixed/ static version (called “DH”) where all conversations use the same key,
      • an ephemeral version (called “EDH” (Ephermeral Diffie-Hellman) or “DHE” (Diffie-Hellman Ephemeral)) where every conversation has a different key. 
    • Its security too is based on the discrete logarithm problem (like DSA). 
    • SSHv2 uses DH as its key exchange protocol. 

Hashing functions

Hashing functions take input data and return a value (called a hash or digest). The input and message digest have a one-to-one mapping, such that given an input you get a unique digest and even a small change to the input will result in a different digest. Hashes are one way functions – given an input you can easily create a digest, but given a digest it is practically impossible to generate the input that created it. 

  • MD2 – Message-Digest 2 – designed by Ron Rivest
    • Is optimized for 8-bit computers. Creates a digest of 128-bits. 
    • No longer considered secure but is still in use in Public Key Infrastructure (PKI) certificates but is being phased out?
  • MD4 – Message-Digest 4 – designed by Ron Rivest
    • Creates a digest of 128-bits.
    • It is used to create NTLM password hashes in Windows NT, XP, Vista, and 7.
    • MD4 is no longer recommended as there are attacks that can generate collisions (i.e. the same hash for different input). 
  • MD5 – Message-Digest 5 – designed by Ron Rivest to replace MD4
    • As with MD4 it creates a digest of 128-bits.
    • MD5 too is no longer recommended as vulnerabilities have been found in it and actively exploited. 
  • MD6 – Message-Digest 6 – designed by Ron Rivest and others. 

For more on MD2, MD4, and MD5 see this link

  • SHA 0 (a.k.a. SHA) – Secure Hash Algorithm 0 – designed by the NSA
    • Creates a 160-bit hash. 
    • Not widely used.
  • SHA-1 – Secure Hash Algorithm 1 – designed by the NSA
    • Creates a 160-bit hash. 
    • Is very similar to SHA-0 but corrects many alleged weaknesses. Is related to MD-4 too. 
    • Is very widely used but is not recommended as there are theoretical attacks on it that could become practical as technology improves. 
    • SHA-2 is the new recommendation. Microsoft and Google will stop accepting certificates with SHA-1 hashes, for instance, from January 2017.
  • SHA-2 – Secure Hash Algorithm 2 – designed by the NSA. 
    • Significantly different from SHA-1.
    • Patented. But royalty free. 
    • SHA-2 defines a family of hash functions. 
    • Creates hashes of 224, 256, 384 or 512 bits. These variants are called SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256.
      • SHA-256 and SHA-512 new hash functions. They are similar to each other. These are the popular functions of this family.
        • SHA-512 is supported by TrueCrypt.
        • SHA-256 is used by DKIM signing. 
        • SHA-256 and SHA-512 are recommended for DNSSEC. 
      • SHA-224 and SHA-384 are truncated versions of the above two. 
      • SHA-512/224 and SHA-512/256 are also truncated versions of the above two with some other differences. 
    • There are theoretical attacks against SHA-2 but no practical ones. 
  • SHA-3 – Secure Hash Algorithm 3 – winner of the NIST hash function competition
    • Not meant to replace SHA-2 currently. 
    • The actual algorithm name is Keccak.

Some more hash functions are:

  • Whirlpool – designed by Vincent Rijmen (co-creator of AES) and Paulo S. L. M. Barreto. 
    • Patent free. In public domain.
    • Creates a 512-digest. 
    • Supported by TrueCrypt.
  • RIPEMD – RACE Integrity Primitives Evaluation Message Digest 
    • Based on the design principles of MD-4. Similar in performance to SHA-1. Not widely used however. 
    • Was designed in a the open academic community and meant to be an alternative to the NSA designed SHA-1 and SHA-2. 
    • Creates 128-bit hashes.
    • There are many variants now: RIPEMD-128 creates 128-bit hashes (as the original RIPEMD hash), RIPEMD-160 creates 160-bit hashes, RIPEMD-256 creates 256-bit hashes, RIPEMD-320 creates 320-bit hashes. 


  • PEM (Privacy Enhanced Mail) is the preferred format for storing private keys, digital certificates (the public key), and trusted Certificate Authorities (CAs). 
    • Supports storing multiple certificates (e.g. a certificate chain).
    • If a chain is stored, then first certificate is the server certificate, next is issuer certificate, and so on. Last one can be self-signed or (of a root CA).
    • The file begins with the line ----BEGIN CERTIFICATE---- and ends with the line ----END CERTIFICATE----. The data is in a text format. 
    • Private key files (i.e. private keys not stored in a keystore) must be in PKCS#5/PKCS#8 PEM format.
  • DER (Distinguished Encoding Rules) is another format.
    • Can only contain one certificate. The data is in a binary format. 
  • JKS (Java KeyStore) is the preferred format for key stores. 
  • P7B (Public-Key Cryptography Standards #7 (PKCS #7)) is a format for storing digital certificates (no private keys)
    • Supports storing multiple certificates.
    • More about PKCS at WikiPedia. PKCS#7 is used to sign and/ or encrypt messages under a PKI. Also to disseminate certificates. 
  • PFX/P12 (Public-Key Cryptography Standards #12 (PKCS #12)) is a format for storing private keys, digital certificates (the public key), and trusted CAs. 
    • PFX is a predecessor to PKCS#12. 
    • Usually protected with a password-based symmetric key. 
  • CER is a format for storing a single digital certificate (no private keys)
    • Base64-encoded or DER-encoded X.509 certificates.
  • SSL/ TLS are protocols that use the above
    • SSL – Secure Sockets Layer; TLS – Transport Layer Security
    • SSL has version 1.0 to 3.0. SSL version 3.1 became TLS 1.0. TLS has version 1.0 to 1.2. SSL and TLS are not interoperable (TLS 1.0 can have some of the newer features disabled, and hence security weakened, to make it interoperable with SSL 3.0)
    • Used for authentication and encryption. Makes use of the ciphers above. 


Since writing this post I came across some links related to the topics above. Thought I’d add them to this post in case anyone else finds these useful:

Notes on TLS/SSL, RSA, DSA, EDH, ECDHE, and so on …

The CloudFlare guys make excellent technical posts. Recently they introduced Keyless SSL (which is a way of conducting the SSL protocol wherein the server you are talking to does not necessarily need to have the private key) and as part of the post going into its technical details they talk about the SSL protocol in general. Below are my notes on this and a few other posts. Crypto intrigues me as I like encryption and privacy so this is an area of interest. 

Note: This is not a summary of the CloudFlare blog post. It was inspired by that post but I talk about a lot more basic stuff below. 

The TLS/SSL protocol

First things first – what we refer to as Secure Sockets Layer (SSL) protocol is not really SSL but Transport Layer Security (TLS).

  • Versions 1.0 to 3.0 of SSL were called, well … SSL 1.0 to SSL 3.0. 
  • TLS 1.0 was the upgrade from SSL 3.0. It is very similar to SSL such that TLS 1.0 is often referred to as SSL 3.1. 
  • Although the differences between TLS 1.0 and SSL 3.0 are not huge, the two cannot talk to each other. TLS 1.0, however, includes a mode wherein it can talk to SSL 3.0 but this decreases security. 

The world still refers to TLS as SSL but keep in mind it’s really TLS. TLS has three versions so far – TLS 1.0, TLS 1.1, and TLS 1.2. A fourth version, TLS 1.3, is currently in draft form. I would be lying if I said I know the differences between these versions (or even the differences between SSL 3.0 and TLS 1.0) so it’s best to check the RFCs for more info!

TLS/SSL goals

The TLS/SSL protocol has two goals:

  1. Authenticate the two parties that are talking with each other (authentication of a server is the more common scenario – such as when you visit your bank’s website for instance – but authentication of the user/ client too is supported and used in some scenarios). 
  2. Protect the conversation between the two parties.

Both goals are achieved via encryption.

Encryption is a way of “locking” data such that only a person who has a “key” to unlock it can read it. Encryption mechanisms are essentially algorithms: you take a message, follow the steps of the algorithm, and end up with an encrypted gobbledygook. All encryption algorithms make use of keys to lock and unlock the message – either a single key (which both encrypts and decrypts the message) or two keys (either can encrypt and decrypt).

Shared key encryption/ Symmetric encryption

A very simple encryption algorithm is the Caesar Cipher where all you do is take some text and replace the letters with letters that are a specified number away from it (for example you could replace “A” with “B”, “B” with “C”, and so on or “A” with “C”, “B” with “D”, and so on … in the first case you replace with a letter one away from it, in the second case you replace with a letter two away from it). For the Caesar Cipher the key is simply the “number of letters” away that you choose. Thus for instance, if both parties decide to use a key of 5, the encrypting algorithm will replace each letter with one that’s 5 letters away, while the decrypting algorithm will replace each letter with one that’s 5 letters before. The key in this case is a shared key – both parties need to know it beforehand. 

Encryption algorithms where a single shared key is used are known as symmetric encryption algorithms. The operations are symmetrical – you do something to encrypt, and you undo that something to decrypt. TLS/SSL uses symmetric encryption to protect the conversation between two parties. Examples of the symmetric encryption algorithms TLS/SSL uses are AES (preferred), Triple DES, and RC4 (not preferred). Examples of popular symmetric  algorithms can  be found on this Wikipedia page

Symmetric encryption has the obvious disadvantage that you need a way of securely sharing the key beforehand, which may not always be practical (and if you can securely share the key then why not securely share your message too?).

Public key encryption/ Asymmetric encryption

Encryption algorithms that use two keys are known as asymmetric encryption or public key encryption. The name is because such algorithms make use of two keys – one of which is secret/ private and the other is public/ known to all. Here the operations aren’t symmetrical- you do something to encrypt, and you do something else to decrypt. The two keys are special in that they are mathematically linked and anything that’s encrypted by one of the keys can be decrypted only by the second key. A popular public key encryption algorithm is RSA. This CloudFlare blog post on Elliptic Curve Cryptography (ECC), which is itself an example of a public key encryption algorithm, has a good explanation of how RSA works. 

Public key encryption can be used for encryption as well as authentication. Say there are two parties, each party will keep its private key to itself and publish the public key. If the first party wants to encrypt a message for the second party, it can encrypt it using the public key of the second party. Only the second party will be able to decrypt the message as only it holds the private key. Thus the second party is authenticated as only the second party holds the private key corresponding to the public key.

Public key cryptography algorithms can also be used to generate digital signatures. If the first party wants to send a message to the second party and sign it, such that the second party can be sure it came from the first party, all the first party needs to do is send the message as usual but this time take a hash of the message encrypt that with its private key. When the second party receives this message it can decrypt the hash via the public key of the first party, make a hash itself of the message, and compare the two. If the hashes match it proves that the message wasn’t tampered in progress and also that the first party has indeed signed it as only its private key locked message can be unlocked by the public key. Very cool stuff actually!

Not all public key cryptography algorithms are good at encryption and signing nor are they required to be so. RSA, for instance, is good at encryption & decryption. Another algorithm, DSA (Digital Signature Algorithm) is good at signing & validation. RSA can do signing & validation too but that’s due to the nature of its algorithm

A question of trust

While public key encryption can be used for authentication there is a problem. What happens if a third party publishes its public key on the network but claims that it is the second party. Obviously it’s a fraud but how is the first party to know of that? Two ways really: one way is the first party can perhaps call or through some other means verify with the second party as to what its public key is and thus choose the correct one – this is tricky because it has to verify the identity somehow and be sure about it – or, the second way, there can be some trusted authority that verifies this for everyone – such a trusted authority will confirm that such and such public key really belongs to the second party. 

These two ways of finding if you can trust someone are called the Web of Trust (WoT) and Public Key Infrastructure (PKI) respectively. Both achieve the same thing, the difference being the former is decentralized while the latter is centralized. Both of these make use of something called certificates – which is basically a digital document that contains the public key as well as some information on the owner of the public key (details such as the email address, web address, how long the certificate is valid for, etc). 

Web of Trust (WoT)

In a WoT model everyone uploads their certificates to certain public servers. When a first party searches for certificates belonging to a second party it can find them – both legitimate ones (i.e. actually belonging to the second party) as well as illegitimate ones (i.e. falsely uploaded by other parties claiming to the be second party). By default though the first party doesn’t trust these certificates. It only trusts a certificate once it verifies through some other means as to which is the legitimate one – maybe it calls up the second party or meets the party in person or gets details from its website. The first party can also trust a certificate if someone else it already trusts has marked a certificate as trusted. Thus each party in effect builds up a web of certificates – it trusts a few and it trusts whatever is trusted by the few that it trusts. 

To add to the pool once a party trusts a certificate it can indicate so for others to see. This is done by signing the certificate (which is similar to the signing process I mentioned earlier). So if the first party has somehow verified that a certificate it found really belongs to the second party, it can sign it and upload that information to the public servers. Anyone else then searching for certificates of the second party will come across the true certificate too and find the signature of the first party. 

WoT is what you use with programs such as PGP and GnuPG. 

Public Key Infrastructure (PKI)

In a PKI model there are designated Certificate Authorities (CA) which are trusted by everyone. Each party sends their certificates to the CA to get it signed. The CA verifies that the party is who it claims to be and then signs it. There are many classes of validation – domain validation (the CA verifies that the requester can manage the domain the certificate is for), organization validation (the CA also verifies that the requester actually exists), and extended validation (a much more comprehensive validation than the other two). 

Certificate Authorities have a tree structure. There are certain CAs – called root CAs – which are implicitly trusted by everyone. Their certificates are self-signed or unsigned but trusted by everyone. These root CAs sign certificates of other CAs who in-turn might sign certificates of other CAs or of a requester. Thus there’s a chain of trust – a root CA trust an intermediary CA, who trusts another intermediary CA, who trusts (signs) the certificate of a party. Because of this chain of trust, anyone who trusts the root CA will trust the certificate signed by one of its intermediaries. 

 It’s probably worth pointing out that you don’t really need to get your certificate signed by a CA. For instance, say I want to encrypt all traffic between my computer and this blog and so I create a certificate for the blog. I will be the only person using this – all my regular visitors will visit the blog unencrypted. In such a case I don’t have to bother with them not trusting my certificate. I trust my certificate as I know what its public key and details look like, so I can install the certificate and use an https link when browsing the blog, everyone else can use the regular http link. I don’t need to get it signed by a CA for my single person use. It’s only if I want the general public to trust the certificate that I must involve a CA. 

PKI is what you use with Internet Browsers such as Firefox, Chrome, etc. PKI is also what you use with email programs such as Outlook, Thunderbird, etc to encrypt communication with a server (these emails program may also use WoT to encrypt communication between a sender & recipient). 

TLS/SSL (contd)

From here on I’ll use the words “client” and “server” interchangeably with “first party” and “second party”. The intent is the same, just that it’s easier to think of one of one party as the client and the other as a server. 

TLS/SSL uses both asymmetric and symmetric encryption. TLS/SSL clients use asymmetric encryption to authenticate the server (and vice-versa too if required) and as part of that authentication they also share with each other a symmetric encryption key which they’ll use to encrypt the rest of their conversation. TLS/SSL uses both types of encryption algorithms because asymmetric encryption is computationally expensive (by design) and so it is not practical to encrypt the entire conversation using asymmetric encryption (see this StackExchange answer for more reasons). Better to use use asymmetric encryption to authenticate and bootstrap symmetric encryption. 

When a TLS/SSL client contacts a TLS/SSL the server sends the client its certificate. The client validates it using the PKI. Assuming the validation succeeds, client and server perform a “handshake” (a series of steps) the end result of which is (1) authentication and (2) the establishment of a “session key” which is the symmetric key used for encrypting the rest of the conversation. 

CloudFlare’s blog post on Keyless SSL goes into more details of the handshake. There are two types of handshakes possible: RSA handshakes and Diffie-Hellman handshakes. The two types of handshakes differ in terms of what algorithms are used for authentication and what algorithms are used for session key generation. 

RSA handshake

RSA handshakes are based on the RSA algorithm which I mentioned earlier under public key encryption. 

An RSA handshake uses RSA certificates for authentication (RSA certificates contain a public RSA key). Once authentication is successful, the client creates a random session key and encrypts with the public key of the server (this encryption uses the RSA algorithm). The server can decrypt this session key with its private key, and going forward both client & server use this session key to encrypt further traffic (this encryption does not use the RSA algorithm, it uses one of the symmetric key algorithms).

 The RSA handshake has a drawback in that if someone were to capture and store past encrypted traffic, and if the server’s private key were to somehow leak, then such a person could easily decrypt the session key and thus decrypt the past traffic. The server’s private key plays a very crucial role here as it not only authenticates the server, it also protects the session key. 

Diffie-Hellman handshake

Diffie-Hellman handshakes are based on the Diffie-Hellman key exchange algorithm. 

The Diffie-Hellman key exchange is an interesting algorithm. It doesn’t do any encryption or authentication by itself. Instead, it offers a way for two parties to generate a shared key in public (i.e. anyone can snoop in on the conversation that takes place to generate the secret key) but the shared key is secret and only the two parties know of it (i.e. the third party snooping in on the conversation can’t deduce the shared key). A good explanation of how Diffie-Hellman does this can be found in this blog post. Essentially: (1) the two parties agree upon a large prime number and a smaller number in public, (2) each party then picks a secret number (the private key) for itself and calculates another number (the public key) based on this secret number, the prime number, and the smaller number, (3) the public keys are shared to each other and using each others public key, the prime number, and the small number, each party can calculate the (same) shared key. The beauty of the math involved in this algorithm is that even though a snooper knows the prime number, the small number, and the two public keys, it still cannot deduce the private keys or the shared key!

There are two versions of the Diffie-Hellman algorithm:

  • a fixed/ static version, where both parties use the same public/ private keys (and hence same shared key) across all their conversations; and
  • an ephemeral version, where one party keeps changing its public/ private key (and hence the shared key)

Since the Diffie-Hellman algorithm does not do authentication it needs some other mechanism to authenticate the client and server. It can use an RSA certificate (certificates containing an RSA public key) or a non-RSA certificates – for example DSA certificates (certificates containing a DSA public key) and ECDSA (Elliptic Curve Digital Signature Algorithm) certificates (ECDSA is a variant of DSA that uses Elliptic Curve Cryptography (ECC). ECDSA certificates contain an ECC public key. ECC keys are better than RSA & DSA keys in that the ECC algorithm is harder to break. So not only are ECC keys more future proof, you can also use smaller length keys (for instance a 256-bit ECC key is as secure as a 3248-bit RSA key) and hence the certificates are of a smaller size). 

The fixed/ static version of Diffie-Hellman requires a Diffie-Hellman certificate for authentication (see here and here). Along with the public key of the server, this certificate also contains the prime number and smaller number required by the Diffie-Hellman algorithm. Since these numbers are a part of the certificate itself and cannot change, Diffie-Hellman certificates only work with fixed/ static Diffie-Hellman algorithms and vice-versa. A Diffie-Hellman handshake that uses the fixed/ static Diffie-Hellman algorithm has the same drawback as a RSA handshake. If the server’s private key is leaked, past traffic can be decrypted.  

The ephemeral version of Diffie-Hellman (often referred to as EDH (Ephermeral Diffie-Hellman) or DHE (Diffie-Hellman Ephemeral)) works with RSA certificates, DSA certificates, and ECDSA certificates. EDH/ DEH is computationally expensive as it is not easy to keep generating a new prime number and small number for every connection. A variant of EDH/ DEH that uses elliptic curves – known as Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) – doesn’t have the performance hit of EDH/ DEH and is preferred. 

A Diffie-Hellman handshake that uses EDH/ DEH or ECDHE doesn’t have the drawback of an RSA handshake. The server’s private key is only used to authenticate it, not for generating/ protecting the shared session key. This feature of EDH/DHE and ECDHE wherein the shared keys are generated for each connection and are shared keys themselves are random and independent of each other is known as Perfect Forward Secrecy (PFS). (Perfect Forward Secrecy is a stronger form of Forward Secrecy. The latter does not require the shared keys themselves be independent of each other, only that the shared keys not be related to the server’s private/ public key). 

To be continued …

Writing this post took longer than I expected so I’ll conclude here. I wanted to explore TLS/SSL in the context of Windows and Active Directory, but I got side-tracked talking about handshakes and RSA, ECDHE, etc. Am glad I went down that route though. I was aware of elliptic curves and ECDHE, ECDSA etc. but had never really explored them in detail until now nor written down a cumulative understanding of it all. 

Self Encrypting Drives (SEDs), BitLocker, UEFI, Truecrypt, etc

Past few days I upgraded my laptops with SSD drives. Learnt a few bits and pieces on the way, this is just a dump of what I learnt in case it helps others.

SSDs are fast and can really speed up old hardware, but set your expectations right if you are using encryption. In my case, an aging laptop with a 5400rpm regular HDD was very fast (as expected) when replaced with SSD. But add Truecrypt encryption to the mix, and it slows down a bit. Not too much, but noticeably, and especially when it comes to waking up from hibernation. In retrospect this should be expected as encryption places demands on the CPU, and older laptops mean slower CPUs hence that becomes a bottleneck.

There are SSDs that support hardware based encryption too. These are usually $20-$30 more than the other SSDs but the advantage is that the encryption task is offloaded to the controller of the SSD freeing up your computer CPU and avoiding a performance hit.

There seem to be three varieties of SSDs that support hardware based encryption: (1) also known as Self Encrypting Drives, these are based on an OPAL standard developed by the TCG wherein the drive itself has an engine to encrypt everything written to it (hence the name “self encrypting” drive); (2) those where the hard disk enclosure has a smaller regular (non-encrypted) hard drive, accompanied by an encryptor chip that takes care of encryption; and (3) there is a separate encryptor chip placed between the computer and regular (non-encrypted) hard drive that takes care of the encryption.

Self Encrypting Drives seem to be the popular ones. The Crucial M500, which I used for one of my laptops, is such a drive. SEDs have a 256-bit AES encryption engine that encrypts everything written to the drive by default. On it’s own that’s useless though as there’s no password protecting the keys used to encrypt everything, so anyone can read data from the drive and it will happily decrypt too. To use the drive effectively one needs additional software that support the OPAL standard and which will interact with the drive to password protect the keys. There are many third party software for this but sadly most of them are for enterprises (so the software is very expensive and you can’t get more details until you contact the sales department etc). This is a pity, I wish drive manufacturers included such software for an additional reasonable cost as without such software the hardware-based encryption feature of such SSDs is useless.

From one of the Amazon reviews for the M500 I learnt that a user had good experiences using WinMagic’s SecureDoc. That software too is pricey (nearly as much as the SSD itself!) and I have two laptops so buying two copies of the software is not worth it.

There exists a “free” alternative though. If you are on Windows 8 (or Server 2012) and your SSD is OPAL 2 compliant (the M500 is) and your computer is UEFI 2.3.1 based and has the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL defined (and has the Compatibility Support Module (CSM) disabled in UEFI, and always boots natively from UEFI) then you can use BitLocker (which is a part of Windows 8) will encrypt the drive using its hardware-based encryption. (If you want to be doubly sure you can use the BitLocker PowerShell cmdlets to specify you want hardware encryption and later use the manage-bde -status command to verify hardware-based encryption is in use).

The UEFI requirement is only if the SSD is used as a startup drive though (i.e. the OS is installed on it and boots up from it). If you are using the SSD as an additional drive, then BitLocker can be used to for hardware-based encryption.

In my case, however, the SSD is a startup drive but neither computer had UEFI. Nor did the computer manufacturer have any updates for flashing UEFI. It does not seem possible to upgrade BIOS to UEFI either (at least not easily and there could be hardware limitations that prevent you from doing so too). So although I have an SED I can’t use BitLocker to use its hardware-based encryption features. Bummer!

For more info on SEDs: check out this KB article from Crucial on the encryption features of the M500; this forum post which clarifies hardware-based encryption does not work with Linux and also mentions SecureDoc; this and this article from AnandTech; this very informative article on how SEDs work.

UPDATE: Turns out I am not entirely correct in saying that SEDs are based on OPAL standards. Not all SEDs are based on OPAL standards. For instance, SSDs from Intel and Samsung (Intel SSD 520 Series, Samsung 840 Series) are SEDs but use a password you specify in the BIOS for hardware encryption. These SSDs require BIOS support for the password – known as ATA password. The drives always encrypt their data and once you specify a BIOS ATA password they keys are encrypted using a hash of this ATA password, thus locking the data (also see this FAQ and whitepaper in case the previous link is broken). (Also, if you are interested in ATA passwords and have a motherboard that does not support ATA passwords (not the same as BIOS passwords!) this forum post might be helpful).

See this page too from Softex.

UPDATE 2: Softex SecureDrive seems to be a reasonably priced product for OPAL SED drives. It’s about US$75 per license, which while high is still less that the US$100+ prices of others.