0

So at my workplace, I have a .NET based web application, that has to pick up an encrypted parameter in a querystring.

Those supplying the encrypted string is an external contractor and they prefer (almost demand. cant change contractors though, the higher ups decide that stuff...), to use Microsoft's Crypto API to encrypt the string.

Well, fair enough, AFAIK I can decrypt that with C#, but after endless searching I am still at a loss on how it works.

That means I cant even supply example code, and I am stuck in this bind until I can decrypt this string.

What I have is:

I have the common password they encrypt with and I have to use to decrypt it with.

Encryption settings are: "CALC_AES_128" hash: "CALC_MD5". The string is encrypted, then hashed.

So I want to unhash it, and decrypt it.

I know its a lot to ask but how do I go about it?

jww
  • 97,681
  • 90
  • 411
  • 885
Frederik T
  • 533
  • 2
  • 10
  • 30
  • 1
    You can't "unhash" (short of using rainbow tables, which I assume doesn't apply since it is presumably salted). That is like saying you want to "uncrop a photo". Normally, you compare the hash to what you get when you perform the **same operation**. – Marc Gravell Sep 05 '13 at 07:13
  • +1 @MarcGravell A Hash where you can "unhash" is known technically in the Crypto business as a "Broken Hash". – Aron Sep 05 '13 at 07:16
  • I thought a string hashed with md5 could go both ways? – Frederik T Sep 05 '13 at 07:16
  • 1
    No, an md5 hash cannot be unhashed (except for rainbow tables). Let's put it this way: an MD5 hash is always 16 bytes, regardless of what you put in. If that could be unhashed, it would be the most awesome compression technology *ever*. You could watch a 10 hour HD movie from 16 bytes... – Marc Gravell Sep 05 '13 at 07:17
  • @FrederikT That is because its a Broken hash. But but technically speaking, another property of hashes are that they are typically smaller than the original information. HENCE, due to pigeon hole theory, you can "unhash" into MANY strings. – Aron Sep 05 '13 at 07:18
  • @MarcGravell, actually md5 is truly broken. You can use a form of Trial and Improvement, there are known functions for applying to known text that cause a small delta to the hash text. – Aron Sep 05 '13 at 07:20
  • Also given that AES typically is used with a random IV (for security, and to prevent a form of replay attack) AES followed by a HASH is meaningless given that both AES and your hash remains unbroken. Your external contractor is talking out of his rear end. – Aron Sep 05 '13 at 07:24
  • @Aron agreed, it isn't exactly what I'd choose for anything involving security, but a per-user / per-context salt will at least make things more awkward – Marc Gravell Sep 05 '13 at 07:24
  • "Software developers, Certification Authorities, website owners, and users should avoid using the MD5 algorithm in any capacity. As previous research has demonstrated, it should be considered cryptographically broken and unsuitable for further use." http://www.kb.cert.org/vuls/id/836068 – Aron Sep 05 '13 at 07:27
  • Ok, though i am adept with C#, security is something i know nothing of, and reading what i can about that kind of cryptography makes my head spin. So let me ask the experts: 1: Is it possible to get something usable out of a string encrypted with CALC_AES_128 thats then hashed with CALC_MD5. 2: Is the external contractor playing me for a fool and should i force them for something else? 3: If thats the case, whats safest way to send private information in a querystring parameter? Obscure it so to say. – Frederik T Sep 05 '13 at 07:29
  • 1
    1. Not possible physically, mathematically...maybe 2. Yes 3. Plaintext over HTTPS (make sure to turn off compression). – Aron Sep 05 '13 at 07:39
  • Hmm... thought as much. Well it IS an https connection, i just want to at least obscure the information just to be safe. I have gotten the greenlight to just go full plaintext over https, but it doesnt sit right with the developer inside me. – Frederik T Sep 05 '13 at 07:42
  • 3
    Plaintext over https is fine. Just make sure that the client verifies the server's certificate. If your certificate verification accepts an attacker's certificate, they can intercept your connection. – CodesInChaos Sep 05 '13 at 08:58

1 Answers1

1

Your external contractor doesn't know what he is talking about.

Hashes are used as a trap door function, a way to recognize something without been told what that thing IS. It is a digital fingerprint. The way a CRYPTOGRAPHICALLY SECURE hash is made, means even given the hash and the algorithm it is difficult to create an object that matches the fingerprint.

AES is a non-deterministic cypher. The non-determinisism comes from the Initialization Vector, which is meant to be a random number each time (not hard coded from a die roll, ahem Sony). This means for all intents and purposes, the output of AES is pure random (unless you have the key). Good cyphers are all designed to produce data that is statistically random (thus there is little data to form an attack from).

So by feeding data into a function that creates random data, then putting it into a trap door function, you have produce something that is truly difficult to decode (difficult in this sense is mathematically, you actually need more energy than exist in the universe to compute this).

As for how to send data across in a secure manner (secure as in against prying eyes on an unsecure network) in the query string? There is a well known protocol that .net supports that does this very well. Its called HTTPS.

Aron
  • 15,464
  • 3
  • 31
  • 64
  • And there is no easy way to obscure the sensitive information? – Frederik T Sep 05 '13 at 07:59
  • Each layer of encryption is going to provide inconvenience. The more secure it is the more inconvenience it will be. The point of security is it is inconvenient...The more bit of stuff needed to make it work...the more bits of stuff the attacker needs to attack the system. – Aron Sep 05 '13 at 08:11
  • You could drop the HTTPS completely and have the contractor tunnel in via a VPN. That might be more secure... But if you need a full security system in place... as luck would have it I am open to contracts at the moment :P. But yeah...HTTPS should work fine...unless you don't trust your webserver or your contractor...in which case you are pretty screwed. – Aron Sep 05 '13 at 08:13
  • Heh, well sorry, i dont have much to say in this matter. Either way, i have informed my superiors that their encryption suggestion is a no go and we have to go with HTTPS. I can longer into obscuring it later on, but thats just me personal beef. – Frederik T Sep 05 '13 at 08:16
  • 1
    AES by itself is deterministic. It's a block-cipher, and thus just a keyed permutation. It's only a specific mode of operation that consumes the IV and introduces randomization. – CodesInChaos Sep 05 '13 at 08:56
  • @FrederikT [Security through obscurity](http://en.wikipedia.org/wiki/Security_through_obscurity) has no place in real security. Real security is based on algorithms and protocols that are safe when the specifications are public. Also, relevant article: http://blogs.msdn.com/b/ericlippert/archive/2011/09/27/keep-it-secret-keep-it-safe.aspx – ntoskrnl Sep 05 '13 at 14:39