SHA-1 Algorithm and Decryption in CF

Copy link to clipboard
Copied
Hello there,
I am trying to decrypt a string and I get the following error message:
"The SHA1 algorithm is not supported by the Security Provider you have chosen."
This is a small description of the system:
OS: Windows Server 2003
CF Version: 8, STANDARD
Web Server: IIS
I have successfully worked with encryption/decryption in the past, but on Enterprise versions of CF. I am wondering if the fact that CF is standard has to do with the problem.
Thanks,
Copy link to clipboard
Copied
ColdFusion 8 documentation shows supported algorithms for decrypt() are CFMX_COMPAT, AES, BLOWFISH, DES and DESEDE. So I guess that's your answer
Copy link to clipboard
Copied
It sounds like you are talking about a hashed value, not an encrypted string. You should not be able to reversed a hashed string (not easily anyway).
Copy link to clipboard
Copied
SHA-1 is a hashing algorithm, not an encryption algorithm. As cfSearching said, it cannot be decrypted. It is a one-way street.
Jason

Copy link to clipboard
Copied
I got more information on this matter. We are a getting an encrypted XML text generated from a SAML 2.0 SSO system. The XML text contains user credentials. On our end we are supposed to decrypt the file and parse the XML file to complete the login process.
I got a couple of booklets on SAML 2.0 SSO but I cannot find what key is being used to encrypt the message, which I believe I need to know to successfully decrypt it.
Copy link to clipboard
Copied
I cannot find what key is being used to encrypt the message, which I believe I need to know to successfully decrypt it.
It would kinda defeat the object if you didn't

Copy link to clipboard
Copied
Then the only way I can think to decrypt this message is by using a public/private key configuration. Sorry my post is kind of incomplete. I am just helping out a colleague that hit a brick wall with this.
What I initially thought was for example that if they encrypted the message using XYZ or AES encryption, I'd just pass that parameter (XYZ or AES) to my CF code to decrypt it.
Copy link to clipboard
Copied
Using public & private keys is called asymmetric encryption, and is far more complex. I don't think CF supports it out of the box but I have used libraries in the past that allow it.
You need symmetric encryption here, just a basic AES/AESEDE encryption. You need to know the algorithm they used, and the key they used to encrypt it. Armed with both those bits of info, you can decrypt it.
If you don't have access to the key that would imply you're not allowed to be viewing this data?
Copy link to clipboard
Copied
How do you know that he needs symmetric encryption? It is very likely that it is using asymmetric.
ColdFusion does not have any helper functions for Asymm crypto, but Java supports it out of the box, so in that sense, so does CF.
I have a blog post on using Asymm (PKI) crypto here: http://www.12robots.com/index.cfm/2010/7/19/Using-Asymmetric-Cryptography-in-your-ColdFusion-Applica...
However, that said, I suspect one of three things.
1. The message is using symmetric crypto and you need to know the algorithm and key. I think these is the least likely
2. The message was encrypted using your organizations public key, so you need to decrypt it using your private key
3. The message is not actually encrypted at all. It is a regular SAML message that is *signed* using PKI and you simply need to verify the signature. The message would be signed with the SAML providers private key and you would verify it with the SAMl providers public key.
Typically, a SAML message is not somethign you need to decrypt. Assuming you are USING the SAML service not PROVIDING it.
Also, I doubt that the SAML message contains the credentials. That is not typically how SAML works. Why would you need the credentials? The point of SAML and federated ID is that you can pass the user off to another authentication provider. They auth provider verifies the ID of the person and then passes you a SAML message stating whether or not they are who they say they are. The message is "signed". All you need to do is verify that signature to ensure that the ID provider has not been spoofed and then see if the user passed auth. You should not need their credentials at that point.
Hope this helps. If I am misunderstanding what you are trying to do, then let me know.

Copy link to clipboard
Copied
Thank you very much! This was very helpful 12Robots.
I checked your blog. So if they are using assymetric encryption, Would I need to add the bcprov-jdk16-145.jar file to my coldfusion lib directory then use Java to be able to decrypt the message in CF? The client is sending me an XML file with information about a user, you are right, not credentials.
I suspect that they are using scenario 2. I was surprised with how little information I found online regarding this topic. I came across your blog while making some Google searches.
Copy link to clipboard
Copied
Actually, you don't need the BouncyCastle library because you are not generating keys. So everything you need is already in your Java VM.
Jason

Copy link to clipboard
Copied
I got more information about the context of my question. The client is sending the SAML message (SAML response) for us to decrypt. I attached a picture with the dump of a struct. The text on xmltext is what my colleague is trying to decrypt. They also sent him some sample encrypted text which I guess is for testing the decryption.
Jason it is probably scenario 2 or 3 of your previous response. I will get involved and figure out what is exactly going on. So in this case, the customer that we are workign with, they still must send me a private or public key to make the decryption, am I correct?
Copy link to clipboard
Copied
Sorry, that screen shot is no good.

Copy link to clipboard
Copied
Jason, this is what I got from the client on the message they are sending me.
OIF uses Symmetric Cryptographic Algorithm to encrypt SAML message. There are 2 pieces of SAML message level security -
- 1. Encryption- Symmetric Cryptographic Algorithm. The ETS IDP metadata XML provided earlier has the certificate which OIF uses to encrypt to the SAML. The SAML consumer on your end must use same certificate to decrypt.
- 2. XML Signature - OIF also signs the SAML (XML) message with certificate, on peerless end SAML consumer must verify the signature. Again the certificate used to Sign is part of ETS IDP metadata XML provided earlier.
Copy link to clipboard
Copied
So they sent you a screen shot that was too fuzzy to read? I mean that the quality is bad. I can't read it, even if I open it and zoom in.
Copy link to clipboard
Copied
OK, well, it sounds like you know where to get the key. They sent it in the "ETS IDP metadata XML provided earlier". So now all you need is to figure out where that is and what algorithm it uses.
Jason

Copy link to clipboard
Copied
Hi Jason,
First I tried your example of Assymetric encryption and got it working in seconds. It's a good working example just in case I have to do asymmetric encryption in the future. Good post!
Anyways going back to my problem,
They finally sent me the key and the algorithm type (AES) in an XML file (they call this file a certificate) that I parse from location X. Based on my conversation with one of the tech guys on the client side, the XML contains a "signature" and a "key". They call this a certificate. I don't recall the function decrypt in CF as having a parameter for a "signature" but at least I know that we were provided a key. Now my problem is this:
The key specified is not a valid key for this encryption: Illegal key size or default parameters.
I updated my JCE jar files and the problem still persist. We all swear that we have the right key and stuff. But now we are running into this. I asked them to tell me the size of the key in bytes. I understand that CF supports AES encruption in 16, 24, and 32 if I recall correctly.
Thanks,

Copy link to clipboard
Copied
I also updated my JCE jar files to support encryption 128 bits or higher. But the message: "
The key specified is not a valid key for this encryption: Invalid key data length |
Still persists.
Copy link to clipboard
Copied
Where did you put the jar files? If you put them in the normal <coldfusion>/lib directory then that is not correct. They belong in the <coldfusion>/runtime/lib/security/ directory.
Also, how long is the key? Is it a string or a serialized JavaObject?
Jason

Copy link to clipboard
Copied
I put it in the right place:
C:\ColdFusion8\runtime\jre\lib\security
And I did this to confirm that it changed from 128 to 2147483647
<cfset variables.maxKeyLen = createObject('java', 'javax.crypto.Cipher').getMaxAllowedKeyLength("AES") />
This is my max allowed encruption on this instance of JVM: <cfoutput>#variables.maxKeyLen#</cfoutput>
The key is very long and I think it is a string. The key has 1484 characters.
Copy link to clipboard
Copied
If it has that many characters then it is likely an encoded Object. With so many characters it is likely more than *just* the 256-bit key. Can you find out from them what exactly that string represents?
Jason

Copy link to clipboard
Copied
It is supposed to have information about the identity of a user to allow single sign on. The message is generated from PeopleSoft and it uses the SAML protocol. I am still digging information on this scenario. I was dragged into this to help and ended up taking it over.
Copy link to clipboard
Copied
Are you talking about the key or the message? The message can be as long as it needs to be and can contain that data. The key can only be 128, 192, or 256 bits long and won't contain anything but the key.
If you are trying to use the message as the key then you are confused.
Jason

Copy link to clipboard
Copied
Ok, let me explain. The original message that they send is a gigantic string and I just need to decode it like this. form.SAMLResponse is what I get from PeopleSoft.
<cfset variables.xmlResponse="#CharsetEncode( BinaryDecode(form.SAMLResponse,"Base64") ,"utf-8")#">
That gives me a XML file that I parse and among many XML elements there are two elements in the XML file with this: data to decrypt and a key. Based on the instructions that my colleague received from the client, that key should decrypt the message. And I am repeating what I was told almost textually. I saved the XML file and sent it over to the peopleSoft developer and explained to him what is going on. He told me he wanted to look further into it (which probably means shelf the issue until someone around here puts more pressure to cooperate with us) because the key is supposed to decrypt the message. I find myself fascinated with this and want to get it done.
Initially I was very confused because they had sent us before a IDP metadata file containing a certificate which had a key. But neither keys work.
Copy link to clipboard
Copied
If the key is actually *WITH* the data to be decrypted, please tell the provider that I said they were stupid, then give them a good, hard sack punch.
If they are even a little smart, then that is not the key you need.
Jason


-
- 1
- 2