On 06/06/2020 21:12, Rich Freeman wrote:
> My point remains:
>
> The header is as secure as the disk.  If the disk is secure against
> brute-force, then so is the header.

I never said otherwise. This was, in fact, explicitly stated in my
concluding remarks of my original post where I say "If using a password,
a strong password is a must." It was also emphasised once more in my
response to your previous email, towards the end.

But it also doesn't mean that one might not want to take additional
preemptive steps following an attack, depending on the circumstances
surrounding the attack.

On 06/06/2020 21:12, Rich Freeman wrote:
> Maybe we're miscommunicating, but it seems like you're moving the
> goalposts here.
> ...
> Your original point was, "The problem here is that a leaked header
> immediately means a compromised volume."

I believe we're on the same page and it's indeed due to miscommunication
and I suspect this is where the main point of miscommunication lies.
You're taking my statement out of context. No doubt, I most certainly
could have phrased this part better and made it clearer. It may not have
been obvious but that sentence was aimed specifically in the context
where a weak password is used or, especially, when a password has been
compromised and how being able to change said password might have little
effect. In which case the point still stands - when a password is
compromised, there is a possibility that changing said password may not
necessarily be the end of the matter as the (old) header may or may not
have been leaked too either as part of the same or a previous attack -
not necessarily involving physical access.

On 06/06/2020 21:12, Rich Freeman wrote:
> The whole reason you're using encryption is to
> protect the data if your disk is stolen/etc.  If they steal the disk
> they get the header too.  So, if a leaked header means that your
> volume is compromised, then a stolen disk does so as well, which means
> your encryption is worthless.

This is probably another point of confusion. You make a strong case
about a stolen drive, but this was never a case I specifically argued
about. If the whole drive itself is stolen then there's little to
discuss as there's nothing that can be done post facto to mitigate the
circumstances, so any points raised re a leaked header or a change of
password can be thrown out of the window and the only hope in such a
scenario is that the password used is strong enough to safe guard
against guessing attacks. So this case is largely irrelevant re some of
the points I made.

Perhaps it seems that the goalpost moves because I never set one - my
original email was a _general discussion_ on the different
considerations that one might want to have if using a password and how
the ability to change a password may lead to a false sense of security.
Clearly, at the end of the day how exactly all these points fit together
is dependent on the threat model and what scenarios are more and less
likely to happen, which I also pointed out but perhaps not as clearly as
I should have. And so is the analysis, assessment of implications, and
steps to take following an attack.

The only time I referred to non-password methods (such as detached
header) was in response to your previous email re header security.
Retrospectively, I admit I too may have taken your point into a
different, more general direction that takes the discussion beyond the
scope of just passwords. For which I'm certainly liable.

I hope this clarifies the matter.

Best Regards,
Victor