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
signature.asc
Description: OpenPGP digital signature
