Hidden volumes

[d-e-s-o]

I started looking into implementing hidden volume support. I first wanted to get the opening and closing done. I was thinking about adding a reveal and hide subcommand to the storage command (names up for debate).
I am not sure about the creation of a hidden volume, though (which likely will have to come eventually and I'd like to have a story for it; I haven't checked if there is something else that we would need to support). storage create seems a ambiguous. storage create-hidden somewhat too long and not in-line with the other subcommands? Not sure.

(I did ponder creating a new top-level command but could not really work that nicely)

The other question is whether to open the encrypted volume if it is not already opened or not (the hidden volume resides inside the encrypted volume and hence the latter must have been opened to begin with).
My take would be to not open the encrypted volume but rather fail the operation. The main reason is that I would like to have symmetry between reveal and hide, and when we hide we have no information as to whether the encrypted volume was already opened before or whether that was done as part of reveal.

Do you have thoughts on this matter, @robinkrahl?

[robinkrahl]

I was thinking about adding a reveal and hide subcommand to the storage command (names up for debate).

Sounds good.

storage create seems a ambiguous. storage create-hidden somewhat too long and not in-line with the other subcommands?

I think the most consistent solution would be to have another level of subcommands, but that’s too complex for this use case. So I’d prefer storage create-hidden.

My take would be to not open the encrypted volume but rather fail the operation.

I agree.

You should also keep in mind that there is the NK_get_SD_usage_data_as_string function that returns the possible range for the create command. I don’t support it in nitrokey as it returns a string instead of a data structure, but I have opened a pull request to fix that.

[d-e-s-o]

Thanks for your response! I actually like the additional subcommand idea. I'll see what it looks like.

[d-e-s-o]

Another interesting topic is that of password management for hidden volumes. The way I understand it, multiple hidden volumes can exist and the one to open is selected based on the password provided.
I am not sure how to best map that to our existing infrastructure for entering secrets. We could, just as we do for PINs, use pinentry to let the user enter the password and we cache it. We'll also have an environment variable representing that password as we do for the User & Admin PIN.
For the case where a user has multiple volumes we could document that the user would have to clear the PIN if he/she wants to open a different volume (I consider that case rather unlikely or at least not frequent).

The alternative would be to always ask for the password (no caching). That does not fit very nicely into our existing design (I guess), but it may be workable.

Perhaps there are more options.

[robinkrahl]

Another interesting topic is that of password management for hidden volumes. The way I understand it, multiple hidden volumes can exist and the one to open is selected based on the password provided.

That’s my understanding too.

The alternative would be to always ask for the password (no caching). That does not fit very nicely into our existing design (I guess), but it may be workable.

I would prefer this option. As the password is only used for this operation, I think it’s fine not to cache it.

[d-e-s-o]

Okay, then I think we are in agreement here. I hope to make some progress by the end of the week.

[d-e-s-o]

No more issues found to be worth a discussion. Closing this issue accordingly.