Very low priority, but hopefully is easy to add by adapting existing code: adding $sha224 as an identifier and also enabling it to be used as the hash in $hmac

While $sslhash supports sha256, it doesn't support sha384 and probably doesn't need to support sha224 as far as server certificates go either.

It turned out the reason that Snoonet used MD5 for their SASL Certificate fingerprint is because that happens if nobody went into the configuration file to change the ircd's default, and servers are not likely to change it to sha384 or sha224, while sha256 and sha512 have been common.

Unless both mIRC and the server the server are ignoring the hashname defined in the certificate, there does appear to be handshake support for sha224 already in mIRC, because I created a self-signed certificate in OpenSSL using sha224 as the hash, and everything worked out on both sides and //whois $me showed that it was using this certificate.


The code for sha224 is exactly the same as sha256 except for 2 minor things. First, the magic constant used by sha256 that begins with 0x6a09e667 is changed to a different magic constant beginning with 0xc1059ed8, but is still 256 bits long. After it finishes doing the same hash operation done by sha256, instead of returning a 256-bit hex string from all 8 32-bit variables chained together, sha224 returns only the hex of the first 7 of them.


While at first glance it can seem that sha224 has no value because, if it's shorter than sha256, then sha256 must be better because it's longer.

However there are a couple of things that sha224 has going for it

  • Defense against the length-extension attack
    This is 1 area that sha224 and sha384 have an advantage over their sisters sha256 and sha512. By withholding 32 and 128 bits respectively from the finishing internal state, that gives the same bit strengths of resistance against a length extension attack, so in some situations sha224 could be stronger than sha512.
  • digest length 56
    sha224 outputs 56 hex digits, which would allow $sha224(string) to match the max length of a literal Blowfish key. It's not as good as what you could get if Blowfish could accept binary keys, but it's fairly simple. The 56 length here is just a coincidence, because 224 was originally chosen because it was a multiple of the 56 bit (not byte) length of the obsolete DES. SHA224 is referenced in RFC 3874.


For interested forum readers, I could demonstrate the length extension attack to them. It assumes a scheme where they share a secret with someone else, and they try to authenticate each other's messages by using $sha512(secret + your public message) as the signature. It would be easy for me to create any string and appended it to your message, and then to quickly create the signature of $sha512(secret + your public message + my any message) that would be the correct signature as if you sent message content that you did not, but it would appear to be a valid message 'signed' by that same secret key. And this would not require me to know the content of the 'secret', and that secret could be of any length.

The alias below helps you do these Steps:
1. Create a secret string of any length and content
2. Create a public string of any length and content
3. Combine the 2 strings together into a &binvar variable, with the secret portion first
4. Create the $sha512 hash of the combined string as a signature.
5. Publish only 3 pieces of information: The public message, that sha512 hash signature, and the byte length of the combined string used to create that signature.

I can create a message that could be appended to your &binary variable, and along with it I could quickly forge a new sha512 hash signature, and my new signature hash would match the combined message as if someone who knew the secret had created the entire combined message.

However, even though sha224 is much shorter than sha512, it would be much more difficult, though not impossible, for me to create a forged signature for my message being appended to yours - if the signature used sha224 instead of sha512. I would need to create 4.3 billion different sha224 signature hashes in order to create a list where 1 of them is guaranteed to be the correct signature for the combined string where my string appended to yours. But at least it's not impossible.


This next alias would create the info I would ask from any challengers, and it's easy to see that it only sends me information about the public message, and the sha512 hash 'signature' of the combined string, as well as the length of the string used to create that hash. I'm asking for the mime or byte values of the public string instead of the text, to avoid confusion in case the forum page messes with the message.

alias length_extension_demo {
  var -s %public message of any content or length goes here
  var -s %secret of any content or length goes here
  ; put both messages into their own &binvar
  bset -tc &secret 1 %secret
  bset -tc &public 1 %public
  ;combine them together into a 3rd &binvar
  bcopy -c &combined 1 &secret 1 -1 | bcopy &combined -1 &public 1 -1
  set -s %signature $sha512(&combined,1)
  ; and here are the info items i would need:
  echo -agc ctcp #1 send/post this: length = $bvar(&combined,0) hash = %signature
  echo -agc ctcp #2 send/post either #2 or #3: $encode(&public,bm) $bvar(&public,1-).text
  echo -agc ctcp #3 send/post either #2 or #3: $bvar(&public,1-)
  echo -ag which both contain the public message: %public
  echo -ag maroon can then publish any message of any length which can be appended to your message
  echo -ag along with another sha512 hash.
  echo -agc ctcp and you cannot create any message of that same length $bvar(&combined,0) whose sha512 hash is
  echo -ag %signature
  echo -ag where appending the maroon string would not match the sha512 signature published by maroon