EEPhil
Number 28
Thanks, but It'll take me longer to decipher the pages I can access than it would to crack the keys .Don't recall how I found it, but:
Thanks, but It'll take me longer to decipher the pages I can access than it would to crack the keys .Don't recall how I found it, but:
But how do you persuade the Humax to encrypt a file that it hasn't created by recording.On the face of it (not going into the nitty-gritty), I didn't find the concept hard to follow. You create plaintext blocks that are mainly zeros, and see what comes out of encryption/decryption (being symmetrical, the operations are identical). That reveals a byte of the key. Then you build some more complex plaintext guided by the previous result, and get the next byte... and so on.
If it's symmetric, by getting it to 'decrypt' an unencrypted file (presumably by manipulating the flags in the .hmt file).But how do you persuade the Humax to encrypt a file that it hasn't created by recording.
How do these two statements marry up? If it's two-key, why have we only been talking about one key?3DES does encryption with key 1, decrypt with key 2, encrypt with key 3 - decryption is the reverse.
I'm pretty sure the 2000-T will be using 2-key 3DES too..
I think that the long string (derived from the MAC address and serial number) is split into smaller keys. If I am correct, with the HDR-FOX, key 1 = key 3 so there are effectively two keys derived from the main string.Everything I've read says it's symmetric, but maybe that's just DES. Easy to test: pass some plaintext through the decryption twice and see if it comes out the same. It would certainly be easier to implement in hardware if it is symmetric.
How do these two statements marry up? If it's two-key, why have we only been talking about one key?
So it is possible to overwrite the default encryption key at boot then.I wonder why I didn't think of that... I took a different approach of setting the encryption key on my HD to the same as my main HDR, then I can just rsync the recordings across and watch them on the HDR (or decrypt them there if I want).
I suggested this a while back and was told that there is no such key.*Is it possible to to set the encryption key so that the output equals the input?
That's an interesting idea, it effectively converts the Triple DES to just DES and (conceivably) could result in software decryption at 2.4 MiB/s. However, I don't know whether we have direct access to K1 and K2 individually, or if they are derived from K outside our control.If you make key 2 = key 1 too then two of the passes will cancel each other out so that decryption should just involve a simple one pass procedure. If you do this on the HD-FOX, will this speed up the processing?
Okay, I now see my mistake: it's symmetric-key as opposed to symmetric, and the encryption & decryption algorithms are different (although use the same processing elements applied in a different sequence). I have been under a longstanding misapprehension that encryption and decryption were identical.Everything I've read says it's symmetric, but maybe that's just DES.
You almost definitely know this now but 3DES uses a key bundle which is comprised of 1, 2 or 3 separate 56-bit keys with check bits making the input length 64-bits.How do these two statements marry up? If it's two-key, why have we only been talking about one key?
Yes, that's definitely possible.So it is possible to overwrite the default encryption key at boot then.
It's most likely that K1 & K2 are just the first and last 64-bits of the 128-bit input key - easy enough to test.That's an interesting idea, it effectively converts the Triple DES to just DES and (conceivably) could result in software decryption at 2.4 MiB/s. However, I don't know whether we have direct access to K1 and K2 individually, or if they are derived from K outside our control.
It certainly is. I tried af123's pointless test first with an external (Java) encryption library that allowed just key1 & key2. When I got it to work, I went back to the standard Java libraries which will only work with the 24 byte key - and this had key3 = key1.If I am correct, with the HDR-FOX, key 1 = key 3
Just a thought, and I'm going to look into this later, I've just discovered that the 2000T (and maybe others) have a System ID. On the 2000T that is given as a 4 byte hex number in System Information. 6 byte MAC, 14 byte serial number and 4 byte System ID = 24 bytes. It can't be that simple - can it?I'm pretty sure the 2000-T will be using 2-key 3DES too..
All the Humax boxes I am familiar with have a System ID; it is checked when applying software updates to try and prevent people from bricking their boxes by applying an update intended for a box with different hardware.I've just discovered that the 2000T (and maybe others) have a System ID.
It isn't. No combination of the three items worked. Neither did truncating them to 16 bytes.It can't be that simple - can it?
That is easy. I can fill a .ts file with some bytes and get the Humax to decrypt it - piece of cake. Unfortunately, we want to encrypt it to follow the method in the paper that BH referenced. I'm not sure I can do that.If it's symmetric, by getting it to 'decrypt' an unencrypted file (presumably by manipulating the flags in the .hmt file).
I think what's needed here is:It's most likely that K1 & K2 are just the first and last 64-bits of the 128-bit input key - easy enough to test. For the HD model, that's a really interesting idea that should really speed up decryption.
- A utility to enable the user to manipulate the key(s);
humax# nugget cryptokey
Native key: dc d3 21 01 02 03 36 33 37 31 30 35 37 36 33 30
Using key: <no custom key in use>
humax# nugget cryptokey 01.01.01.01.01.01.01.01.01.01.01.01.01.01.01.01
Using key: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
humax# nugget cryptokey
Native key: dc d3 21 01 02 03 36 33 37 31 30 35 37 36 33 30
Using key: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
humax# nugget cryptokey -clear
Cleared custom encryption key.
humax# nugget cryptokey
Native key: dc d3 21 01 02 03 36 33 37 31 30 35 37 36 33 30
Using key: <no custom key in use>
humax# stripts -d1 -@@ Ambulance_20180426_2123 l
SD recording.
Encrypted: 1
+ Total size: 59125760
00000000: 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 ................
Key appears correct.
Processed in: 72.30s
humax# stripts -d1 -@@ Ambulance_20180426_2123 l
SD recording.
Encrypted: 1
+ Total size: 59125760
00000000: 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 ................
DES key detected.
Key appears correct.
Processed in: 29.86s