Subscribe via Email

Subscribe via RSS


Recent Posts

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Find which bay an HP blade server is in

So here’s the situation. We have a bunch of HP rack enclosures. Some blade servers were moved from one rack to another but the person doing the move forgot to note down the new location. I knew the iLO IP address but didn’t know which enclosure it was in. Rather than login to each enclosure OA, expand the device bays and iLO info and find the blade I was interested in, I wrote this batch file that makes use of SSH/ PLINK to quickly find the enclosure the blade was in.

Put this in a batch file in the same folder as PLINK and run it.

Note that this does depend on SSH access being allowed to your enclosures.

Update: An alternative way if you want to use PowerShell for the looping –


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.)

Enable & Disable SSH on ESXi host via PowerCLI

I alluded to this in another post but couldn’t find it when I was searching my posts for the cmdlet. So here’s a separate post.

The Get-VMHostService is your friend when dealing with services on ESXi hosts. You can use it to view the services thus:

To start and stop services we use the Start-VMHostService and Stop-VMHostService but these take (an array of) HostService objects.  HostService objects are what we get from the Get-VMHostService cmdlet above. Here’s how you stop the SSH & ESXi Shell services for instance:

Since the cmdlet takes an array, you can give it HostService objects of multiple hosts. Here’s how I start SSH & ESXi Shell for all hosts:

As an aside here’s a nice post on six different ways to enable SSH on a host. Good one!

Notes on using Git from behind a firewall, tunneling SSH through a proxy, Git credential helpers, and so on …

Thought I’d start using Git from my workplace too. Why not! Little did I realize it would take away a lot of my time today & yesterday …

For starters we have a proxy at work. Git can work with proxies, including those that require authentication. Issue the following command:

Or add the following to your global config file:

Apparently this only works with Basic authentication but since version 1.7.10 it works with NTLM authentication too (I didn’t test this). That’s no dice for me though as there’s no way I am going to put my password in plain text anywhere! So I need a way around that.

Enter Cntlm. Cntlm sits between the proxy and your software. Its runs on your machine and authenticates with the proxy/ proxies you specify. (The config file takes password hashes instead of the plain text password). Your programs talk to Cntlm without any authentication; Cntlm then talks to your proxy after proper authentication etc. Cntlm is quite portable. When installing it creates a service and all, but you can run it by launching the exe file and pointing it to the config file. Very convenient. I quickly created a shortcut with this and pinned to my taskbar so I can launch Cntlm whenever required (and it stays in the foreground, so closing the window will close Cntlm).

This way I can pull repositories over https. When I tried pushing though, I was stuck. I am asked for a username/ password and while I am entering the correct details it keeps rejecting me:

Turns out that’s because I use 2 factor authentication so I must create an access token. Did that and now I can push!

But that’s not very ideal as I don’t like storing the access token someplace. It’s a long piece of text and I’ll have to paste it in Notepad and copy paste into the command prompt each time I push.

Notice above that I am using HTTPS instead of SSH as is the norm. That’s because SSH won’t work through the proxy. If SSH works I could have used keys as usual. The good thing about keys is that I can passphrase protect it so there’s something known only to me that I can type each time. And if I ever need to revoke access to my office machine I only need revoke that key from GitHub.

SSH can’t be tunnelled through the HTTP proxy. Well not directly at least, through there is connect.c which is an SSH over HTTP proxy. Luckily it has Windows binaries too so we can try that.

But before that I want to see what I can do to ease access tokens an HTTPS access.

Turns out Git has ways to ease entering passwords or access tokens. Starting with version 1.7.9 it has the concept of credential helpers which can feed Git with your credentials. You can tell Git to use one of these credential helpers – maybe the GNOME Keyring – and Git will get your credentials from there. Older version of can use a .netrc file and you can do the same with Windows version of Git too. You can also cache the password in memory for a specified period of time via the cache credential helper.

Git 1.8.1 and above has in-built support for Windows (via the wincred helper). Prior versions can be setup with a similar helper downloaded from here. Both helpers store your credentials in the Windows Credential Store.

So it is not too much of a hassle using Git with HTTPS via an proxy like Cntlm and using the in-built credential helper to store your credentials in the Windows Credential Store. And if you ever want to revoke access (and are using two-factor authentication) you can simply revoke the access token. Neat!

Back to SSH. Here’s the Wiki page for connect.c, the SSH over HTTP proxy I mentioned above.

The Wiki page suggests a way to test SSH through connect.c. But first, here’s what the SSH link for one of my repositories look like:
. The hostname is, the username is git, and the path I am trying to access is rakheshter/BatchFile (i.e. username\repository). Let’s see if I can connect to that via connect.c:

The syntax is straight-forward. I launch connect.c, telling it to use the proxy at (where Cntlm is listening) and ask it to connect to on port 22 (the SSH port). The -d switch tells connect.c to emit debugging info.

From the output I see it fails. Bummer! My work proxy is blocking traffic to port 22. Not surprising.

Thankfully GitHub allows traffic over port 443 (the HTTPS port). Must use hostname though instead of Let’s test that:

Superb! It works.

Now all I need to do is open/ create %HOMEDRIVE%\.ssh\config and add the following lines:

All this does is that it tells SSH to launch connect.c to pass SSH connections through my proxy. Further, for any connections to (on port 22), connect to on port 443 instead.

Simple! Once I do these I can start pushing & pull Git over SSH too. Not bad eh.

While writing this post I discovered that connect.c is already a part of the Windows version of Git, so there’s no need to download it separately. Super!

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: