Slashdot Mirror

It looks like it's possible using Magiclantern open-source firmware for Canon cameras: https://www.magiclantern.fm/fo...

Interesting. But it should be pointed out that the implementation is very badly done from a security perspective. I only spent a few minutes looking at it and found several showstoppers in both design and implementation. Among them:

1. The basic file encryption algorithm is a stream cipher construction using a simple LFSR as the stream generator. This is almost certainly trivial to break; standard LFSRs are in no way designed for cryptographic security. I suspect the LFSR was used for performance, and I'm sure it does in fact perform much better than, say, AES in CTR mode (where AES is used to generate a bitstream XORed with the plaintext in the same way the LFSR output is). While no good stream cipher is likely to match the LFSR performance, there are several that would provide moderate performance and high security, such as ChaCha20 -- or perhaps even a reduced-round variant like ChaCha12 or even Salsa20/12.

Note that someone has contributed an XTEA implementation which is much better, security-wise, than the LFSR but actually slower than AES. If you're going to do that, just use AES.

2. Even if the LFSR-based encryption algorithm were good, it uses 64-bit keys, which is just too small. Oddly enough, when you use the provided RSA mode for asymmetric write-only encryption (decryption can only be done on your PC), the author seems to recommend a 4096-bit RSA key size, which is roughly equivalent to a ~160-bit symmetric encryption key, and which is quite slow. It makes no sense to use such a huge, slow RSA key to protect small symmetric keys.

3. Password hashing uses the same LFSR plus some shifting and masking. Almost certainly insecure, and there's really no reason at all not to use a good password hashing algorithm like Argon2, or at least scrypt.

4. In asymmetric mode, the code appears to use random padding for RSA operations. There are really good reasons for the PKCS#1 v1.5 and RSA-OAEP padding modes that are normally used. It's possible that a very careful analysis of this implementation may show that under certain operational assumptions random padding is okay... but I seriously doubt that any such careful analysis has been done. I would never bother doing anything of the sort and would simply use OAEP. (Or, better yet, avoid RSA and instead use an elliptic curve algorithm -- less tricky to use correctly, faster, smaller keys and even the provides possibility to derive keys from passwords. There's really no reason to use RSA for anything anymore unless you have to interoperate with legacy infrastructure that already uses it.)

5. RSA key generation is done on-device, with the private key written to the SD card, then later deleted. You can't actually delete things from SD cards, not with any confidence. Much better to do keygen off device so only the public key ever exists on the SD.

6. A glance at the RSA key generation code throws up a number of red flags. I suspect the key generation is buggy.

7. I didn't find the random number generator, but given all of the above, I'd be shocked to find that it's actually good. A bad RNG can easily destroy the security of the best cryptographic design.

When I get some time (ha!) I'm going to see if I can get ML running on my 70D and hack together a better version, using Curve25519 ECDH and ChaCha20 with 128-bit keys, with asymmetric keygen done off-device, and a decent PRNG plus the best seeding mechanism available. To make it more usable, I'll see if I can keep the last few dozen per-file keys in RAM, which will allow the photographer to look at the images on the camera, until the camera is turned off. More paranoid users should be able to disable the retention of keys in RAM.

Sounds like a fun project. One which I may or may not get to before 2025 or so...

It looks like it's possible using Magiclantern open-source firmware for Canon cameras:

https://www.magiclantern.fm/fo...

I think what is being requested in the article is AES grade encryption. What magiclantern provides might be better than having nothing but is still far from being AES. As stated by the author, "the encryption [he] implemented is *not* military grade." For cameras that are taken by border security guards, a make-shift XOR "encryption" probably is not going to be good enough.

It looks like it's possible using Magiclantern open-source firmware for Canon cameras: https://www.magiclantern.fm/fo...

Ty AC, more here
"io_crypt - encrypt your photos while you shoot them"
http://www.magiclantern.fm/for...

As soon as warranty is up on my 6D I'll try it out.

Unfortunately, Magic Lantern development for the 6D has been pretty spotty. An unofficial release is available; check out this thread for instructions/info. If you don't want to try on your 6D, definitely give it a go on a T2i. It's truly amazing software.

"One of ML's newest features is a module named Dual ISO, which takes advantage of the sensor in some of Canon's high-end cameras (such as the 5D MK II and MK III)"

Nope. Dual ISO works on *most* Canon DSLRs, not just the 5DII/5DIII. More info here. Technical paper from the developer here.

Oh yeah, Magic Lantern is one of the most amazing and useful pieces of software I've ever come across. If you own a Canon DSLR, you owe it to yourself to check it out.

Exactly, and Magic Lantern has been doing that amazing work since the 5D II. Tried it on my 5D2, it's a really good piece of open source software.

Now that is a kickass hack! Seriously, taking hardware with limited functionality and actually adding (not just restoring) functionality to it that was not planned for it is pretty cool.

This is not like the "triple core" or "double core" CPUs being "hacked" into quad-cores when the crippling was just the setting low of a line or setting of a jumper on the chip. That was back when they were making all the chips quad cores and then crippling them as needed to meet market need: more dual cores were being purchased because of the lower price point, so the manufacturer just intentionally "disavowed" the extra cores on those chips, just to make a sale at that price point.

Of course, due to some hardware limitations, it can just record bursts of 59 frames at a time (probably RAM buffer limits since the RAW video takes up hella lot of data):

The 50d can already shoot DNG silent bursts with maximum resolutions of 1592x1062 (buffer is full at 59 frames) in 1x mode and 1992x1080 (buffer is full at 53 frames) in crop mode thanks to @smeangol http://www.magiclantern.fm/forum/index.php?topic=5481.msg37526#msg37526

@coutts has found the stubs for the 40d which means it is 'likely' that the 40d can do raw video and DNG bursts however it will need porting and developing.

@Smeangol is having some success in porting the raw recording feature however some other developer assistance may be required to iron out bugs.