Solved Can't format an encrypted .eli device

[canihazsekooriti]

I'm trying to format an encrypted .eli device with either ufs or create a zpool inside of it. I know you can do partitioning/formatting outside of an .eli device and encrypt the contents of a partition that way. Like here for example. But that leaves metadata unencrypted. So I'm trying to partition/format an .eli device that's encrypted, but I'm getting errors:

1) I managed to create a gpt partition table inside of an .eli device and create a partition. But I get "newfs: /dev/md1.eli.elip1: could not find special device".
2) If I want to create a zpool on an md1.eli device I get "cannot create 'someroot': one or more devices is currently unavailable".

Is there a way to just format an .eli device with a UFS or create a zpool there? Notably, I can create a zpool on a plain, unencrypted /dev/md1.

 

[SirDice]

But that leaves metadata unencrypted.

What metadata are you talking about?

I managed to create a gpt partition table inside of an .eli device and create a partition.

Show the output of gpart show

 

[canihazsekooriti]

What metadata are you talking about?

The geli's stuff? Plus all the partitioning structure reveals there may be an encrypted partition there.

Show the output of gpart show

 => 40 4194224 md1.eli GPT (2.0G)
   40 4194224 1 freebsd-ufs (2.0G)

And that's the partition md1.eli.elip1 that gives me an error if I want to create a newfs /dev/md1.eli.elip1on it.

 

[SirDice]

The geli's stuff?

Which is available anyway, because it needs to figure what to load?

Plus all the partitioning structure reveals there may be an encrypted partition there.

No, it doesn't. It will just show the 'normal' partitions, no indication that they're encrypted.

And that's the partition md1.eli.elip1

No, that would be md1.elip1, why are you sticking .eli in there twice?

 

[cracauer@]

The only headerless encryption I am aware of is Linux cryptsetup in the appropriate mode. But (obviously) you get no "help" in which cypher is selected in what mode when you want to activate it.

 

[canihazsekooriti]

No, that would be md1.elip1, why are you sticking .eli in there twice?

Hmm, that's what it shows me if I do the listing

ls -l /dev/md1*

md1.eli.elip1
Should I just use md1.elip1? That's a little confusing that it shows /dev/md1.eli.elip1, but also nice in some way.

The only headerless encryption I am aware of is Linux cryptsetup in the appropriate mode.

That's what I've been using, and it works well. So, it's impossible to achieve this with geli or FreeBSD in general? (Outside of maybe openssl'ing geli's source data)

 

[SirDice]

Hmm, that's what it shows me if I do the listing

Did you add another layer of encryption on top of md1.eli? That would get you to md1.eli.eli.

 

[canihazsekooriti]

Did you add another layer of encryption on top of md1.eli? That would get you to md1.eli.eli.

No, I'm playing with just one layer of encryption now. (Before, maybe..same error though)

 

[cracauer@]

That's what I've been using, and it works well. So, it's impossible to achieve this with geli or FreeBSD in general? (Outside of maybe openssl'ing geli's source data)

Just make sure that you are actually headerless with cryptsetup. By default it has a header.

FreeBSD doesn't have a headerless block device encryption, although I imagine it wouldn't be too hard to hack it up.

 

[canihazsekooriti]

Just make sure that you are actually headerless with cryptsetup. By default it has a header.

I know, but plain mode doesn't.

FreeBSD doesn't have a headerless block device encryption, although I imagine it wouldn't be too hard to hack it up.

Thanks for letting me know. At least, the header is encrypted.

And I guess this solves this issue of trying to format an .eli device because not being headerless beats the whole point of trying not have any signature of partitioning/storage present.

 

[zirias@]

FreeBSD doesn't have a headerless block device encryption, although I imagine it wouldn't be too hard to hack it up.

The question is what it would be good for. It's not like a harddisk full of "random data" in an otherwise operable system would be all too "plausible", after all.

If that's what you're after, you'd need more than some headerless encryption, you'd need to hide your encrypted volume inside unused space of a "dummy" root filesystem ... and this system needs to look as if it would be used regularly ...

Also, https://xkcd.com/538/

 

[cracauer@]

And I guess this solves this issue of trying to format an .eli device because not being headerless beats the whole point of trying not have any signature of partitioning/storage present.

Even if you don't have a header, isn't it quite obvious what is going on when there is a partition or disk with nothing but uncompressable binary blobs on there?

 

[canihazsekooriti]

The question is what it would be good for. It's not like a harddisk full of "random data" in an otherwise operable system would be all too "plausible", after all.

If that's what you're after, you'd need more than some headerless encryption, you'd need to hide your encrypted volume inside unused space of a "dummy" root filesystem ... and this system needs to look as if it would be used regularly ...

Naturally.

 

[canihazsekooriti]

Also, https://xkcd.com/538/

Come git it. Haha, just kidding.

Even if you don't have a header, isn't it quite obvious what is going on when there is a partition or disk with nothing but uncompressable binary blobs on there?

It's just deterrence.