[solved] How to generate keyfile for encrypted array?

[walle]

How do I generate a keyfile to my not yet started array?

 

I finally made the step from Ubuntu server with bunch of unorganized Docker containers, to have a new fresh install of Unraid.

 

I have not yet started the array (only precleared my disks), I could start it by type a passphrase, but because I want it to autostart I want to use a keyfile that I can save remotely and to be fetched on array start (https://lime-technology.com/forums/topic/61973-encryption-and-auto-start/?tab=comments#comment-648148 but with scp/sftp). But I can't find any information about how to generate this file (I assume I'm not supposed to use my trail key).

 

Do I have to generate the keyfile in a special command (like ssh-keygen), or can I use any file like a high-resolution photo of my dinner (would be awesome to able to hide the key in a photo album)?

 

Edited August 29, 2018 by walle
Solved

[tr0910]

Any file is good so your dinner photo is fine. unRaid will use the first 8mb of the file and ignore the rest (need to confirm 8mb part), so it could even be a huge file.

I like your dinner photo but Ssh keygen might be more safe from a crypto standpoint.

[walle]

Thank you for your reply, I was too inpatient so I used a 2mb+ image as the keyfile. Is this good enough or should I change the key? If I need/want to change it, how do I do that (if possible)?

[pwm]

8 hours ago, tr0910 said:

Any file is good so your dinner photo is fine. unRaid will use the first 8mb of the file and ignore the rest (need to confirm 8mb part), so it could even be a huge file.

I like your dinner photo but Ssh keygen might be more safe from a crypto standpoint.

The underlying encryption for the disks are using 128-bit or 256-bit encryption. No key randomness can give more security than this limit. So the reason that quite a lot of data is processed from the key file is just to cover for the key file potentially having bad random data.

 

In the end, the weakest link with a key file is that it's a file. If the user has 1 million files then it's only 2^20 files to test. And the attacker doesn't need encryption skills to figure out which file.

 

But even if not knowing which file to use, selecting the correct file to unlock with is basically 20 bits of security. Requiring two files to be concatenated and used as key file would improve the security since it isn't just 2^20 files to test anymore, but suddenly 2^40 file combinations. And concatenating and testing arbitrary combinations of two files out of 2^20 files represents a huge amount of time. But this concept also fails in reality, because the attacker must be expected to have access to the script that makes the concatenation.

 

In the end, no special tool needs to be used. Any reasonably large file that contains some form of randomness is good enough. And photos fulfills these requirements. But the problem is stopping an attacker from figuring out which file and how to get access to it. So automatic startup using file data outside of the machine is really only a protection from a stupid burglar that walks away with the machine and only has access to the data they carried away.

[walle]

On 8/26/2018 at 1:26 PM, pwm said:

The underlying encryption for the disks are using 128-bit or 256-bit encryption. No key randomness can give more security than this limit. So the reason that quite a lot of data is processed from the key file is just to cover for the key file potentially having bad random data.

 

In the end, the weakest link with a key file is that it's a file. If the user has 1 million files then it's only 2^20 files to test. And the attacker doesn't need encryption skills to figure out which file.

 

But even if not knowing which file to use, selecting the correct file to unlock with is basically 20 bits of security. Requiring two files to be concatenated and used as key file would improve the security since it isn't just 2^20 files to test anymore, but suddenly 2^40 file combinations. And concatenating and testing arbitrary combinations of two files out of 2^20 files represents a huge amount of time. But this concept also fails in reality, because the attacker must be expected to have access to the script that makes the concatenation.

 

In the end, no special tool needs to be used. Any reasonably large file that contains some form of randomness is good enough. And photos fulfills these requirements. But the problem is stopping an attacker from figuring out which file and how to get access to it. So automatic startup using file data outside of the machine is really only a protection from a stupid burglar that walks away with the machine and only has access to the data they carried away.

Sorry, forgot this thread.

 

I agree with you that a long random password that's manually entered to start the array, is probably the most secure option we currently have. But I want this to be automatic and in this case a file on a remote server have the benefit of I can revoke access and also have the possibility of log the IP that's trying to authenticate from. But I agree with you that a somewhat competent digital forensics investigator that's gets the hands on a running array, it isn't much of a challenge to offload the data from the server. I'm just trying to protect my data from the average (stupid) burglar.

[pwm]

12 minutes ago, walle said:

I'm just trying to protect my data from the average (stupid) burglar.

Most people don't need to worry about more than a normal burglar - or about being able to send in a drive for warranty replacement even when the drive interface is dead so the content can't be overwritten.

But it's always good to notify people about potential limitations. Lots of uses have heard about AES-256 and thinks AES-128 is too unsafe to use - and then use a 20-30 bit password to unlock their 256-bit encryption key (assuming that each character of English text is worth about 3-4 bits of security).

 

And lots of users wants "extra high" security so they use key files representing maybe a million bits of security (regarding the randomnes of the file contents) to unlock a 128-bit AES even when nothing they do can make the system safer than the 128-bit AES key. And then they follow  up by forgetting that their server only has 100k files and an attacker can ignore the amount of noise in the "key" photo and just try the 100k files one-by-one. Or read the configuration file that names the key file and the host that stores the key file.

 

Hopefully the new web site can result in people stepping in and reworking the FAQ texts.