Hi all,
We’ve had discussion in this thread about new functionality in Paradox alarm binding that I will probably have to implement if we want to support new firmwares of ethernet communication controller where encryption is required and not optional anymore. This will also improve the security of the binding of course.
Is there anyone here who has experience with this alghoritm and do you know if it’s supported in standard JDK crypto API?
Hi Joao,
thanks for the answer. From what I read here: https://proprivacy.com/guides/aes-encryption
The key expansion uses Rijndael rotation alghoritm which I was not familliar with so far.
Could you please just check this thread to confirm that I’m looking into the right direction: https://www.samiam.org/key-schedule.html
If I use the “Expanding a 256-bit key” as a reference should I be able to create the key and then successfully encrypt the data?
I think I managed to create the key expander in java as posted here: https://www.samiam.org/key-schedule.html
I used Sam Trenholme’s page as reference and mostly refactored his C code into Java code. I also checked your python coding and I see that the resultant tables are the same as yours (atable and ltable). Sam has a method that generates the tables every time which I use also.
I also checked the test vectors that the guy provided and it seems that the key expander works fine.
Just wanted to ask you few particular things related to Paradox IP150 and this encryption:
Which password is used as initial key(PC password, IP150 password or something else) ?
Once I expand the password to a 240 bytes array do I have to manipulate it (rotate or something else) for every packet or so or it stays static until the password is changed on the Paradox system?
I’ve read again your code and I’m a bit confused… according to the guides for 256 bit key I need to loop until the bytes array becomes 240 bytes full.
I see in your keygen you loop until your index reaches 60. Why is that? Is the key shorter?
Also I’m curious about code on lines 278 and 280 in the encrypt method. Does that mean that you fill in the key to a complete 32 bytes and fill the message payload to complete 16 bytes with 0xEE?
There are existing APIs which you can use. Please check below link: https://stackoverflow.com/a/10759422
Based on this answer I can add that adding extra bytes is due to block size of AES which is 16 bytes.