2015-09-29 06:29 AM
Hello,
I want to use STM32CubeExpansion_FwCryptographic_V3.0.0. In my code I do some test calling STM32_TDES_ECB_Encrypt function InputMessage = 9E 42 7D 2E 14 C9 83 23 InputMessageLength = 8 TDES_Key = D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF 00 00 00 00 00 00 00 00 I got OutputMessage = 00 B8 20 5E B2 AD D1 1C OutputMessageLength = 8 I then want to check it with http://tripledes.online-domain-tools.com/ and the result is different ....36 f9 12 61 fc 88 d3 0d I thought they had to be identical :am I wrong
? Regards2015-09-29 08:48 AM
Have you cross checked the online calculator with anything else you've built?
I know the early ST crypto libraries were reliant on turning the CRC peripheral's clock on, or dealing with the difference between F1 and F4 AHB topology, and the CRYP peripheral is reliant on a 48 MHz clock being generated from the Q tap of the PLL, so the PLL has to be running. You're using an F4 with the CRYP/HASH engine right? Or something else?2015-09-30 12:55 AM
Hello
clive1,
In fact I'm using STM32F407 without the CRYP/HASH engine. My board is running correctly and I test the result online with http://tripledes.online-domain-tools.com/ and also with the following script :// Crypto
var crypto = new Crypto();
var key1 = new ByteString(''D0D1D2D3D4D5D6D7D8D9DADBDCDDDEDF0000000000000000'', HEX);
var mcd = new ByteString(''9E427D2E14C98323'', HEX);
var deskey1 = new Key();
deskey1.setComponent(Key.DES, key1);
var result = crypto.encrypt(deskey1, Crypto.DES_ECB, mcd);
print(key1);
print(mcd);
print(result);
which gives the following result
D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF 00 00 00 00 00 00 00 00
9E 42 7D 2E 14 C9 83 23
36 F9 12 61 FC 88 D3 0D
Do you have some documentation on STM32_TDES_ECB_Encrypt function ?
Regards
2015-09-30 01:06 AM
STM32F407 doesn't have the hardware crypto engine so the benefits of using of ST's crypto library are gone. You can use 3-rd party 3DES implementation. Here are
https://github.com/amper43/3DES-ARM
quick (not tested by me). Also you really shouldn't use the ECB mode. Use CBC at least. I would recommend AES in CTR or GCM mode. >Do you have some documentation on STM32_TDES_ECB_Encrypt function ?
Here is thehttp://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00215061.pdf
of X-CUBE-CRYPTOLIB with documentation and sample code. Can anybody please share the distribution of the crypto library? ST's download pages of bothhttp://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1734/PF259409
andhttp://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1920/PF262570
require Flash plugin installed (for some reason) which I don't/won't have.2015-09-30 02:22 AM
Hello qwer.asdf
I had to communicate with an application that use TDES_ECB : I have no choice. I read the documentation but there is no indication except parameters descriptions.... I will have a look on other stuff for encrypting Best Regards2015-09-30 02:28 AM
Hello clive1
You are rightThe ST crypto libraries requires to turn the CRC peripheral's clock on, even without crypto engine...
With __CRC_CLK_ENABLE(); everything works fine.... Thank you2015-09-30 03:14 AM
@pipon.herve.001
Thanks for the link. I didn't know ST's crypto libraries aren't open source. It means we can't easily verify it or trust it being secure. I mean, even if there are no backdoors (which again we can't easily verify) there are dozen of possible side-channel attacks when the crypto is badly implemented.2015-09-30 03:41 AM
Not sure if it uses flash or javascript, either way the download procedure is you put the library in the shopping cart, and someone from ST decides if you're part of the axis-of-evil and approves your request or not. Honestly this is a bit of a circus as all this encryption code is widely available, and I can buy STM32F417 parts out of China easier than from Farnell or whomever.
ST uses the CRC peripheral to confirm the library is being run on STM32 parts rather than loaded on TI ones or whatever.Would be surprised if the code is entirely clean-roomed, the source might be interesting, but one can also disassemble the stuff and look/test for weaknesses. If someone has physical access to your part and is hacking it, you've got bigger issues. Shouldn't take much due diligence to see if it's wiping the stack or not.