1 |
On 06/06/2020 21:12, Rich Freeman wrote: |
2 |
> My point remains: |
3 |
> |
4 |
> The header is as secure as the disk. If the disk is secure against |
5 |
> brute-force, then so is the header. |
6 |
|
7 |
I never said otherwise. This was, in fact, explicitly stated in my |
8 |
concluding remarks of my original post where I say "If using a password, |
9 |
a strong password is a must." It was also emphasised once more in my |
10 |
response to your previous email, towards the end. |
11 |
|
12 |
But it also doesn't mean that one might not want to take additional |
13 |
preemptive steps following an attack, depending on the circumstances |
14 |
surrounding the attack. |
15 |
|
16 |
On 06/06/2020 21:12, Rich Freeman wrote: |
17 |
> Maybe we're miscommunicating, but it seems like you're moving the |
18 |
> goalposts here. |
19 |
> ... |
20 |
> Your original point was, "The problem here is that a leaked header |
21 |
> immediately means a compromised volume." |
22 |
|
23 |
I believe we're on the same page and it's indeed due to miscommunication |
24 |
and I suspect this is where the main point of miscommunication lies. |
25 |
You're taking my statement out of context. No doubt, I most certainly |
26 |
could have phrased this part better and made it clearer. It may not have |
27 |
been obvious but that sentence was aimed specifically in the context |
28 |
where a weak password is used or, especially, when a password has been |
29 |
compromised and how being able to change said password might have little |
30 |
effect. In which case the point still stands - when a password is |
31 |
compromised, there is a possibility that changing said password may not |
32 |
necessarily be the end of the matter as the (old) header may or may not |
33 |
have been leaked too either as part of the same or a previous attack - |
34 |
not necessarily involving physical access. |
35 |
|
36 |
On 06/06/2020 21:12, Rich Freeman wrote: |
37 |
> The whole reason you're using encryption is to |
38 |
> protect the data if your disk is stolen/etc. If they steal the disk |
39 |
> they get the header too. So, if a leaked header means that your |
40 |
> volume is compromised, then a stolen disk does so as well, which means |
41 |
> your encryption is worthless. |
42 |
|
43 |
This is probably another point of confusion. You make a strong case |
44 |
about a stolen drive, but this was never a case I specifically argued |
45 |
about. If the whole drive itself is stolen then there's little to |
46 |
discuss as there's nothing that can be done post facto to mitigate the |
47 |
circumstances, so any points raised re a leaked header or a change of |
48 |
password can be thrown out of the window and the only hope in such a |
49 |
scenario is that the password used is strong enough to safe guard |
50 |
against guessing attacks. So this case is largely irrelevant re some of |
51 |
the points I made. |
52 |
|
53 |
Perhaps it seems that the goalpost moves because I never set one - my |
54 |
original email was a _general discussion_ on the different |
55 |
considerations that one might want to have if using a password and how |
56 |
the ability to change a password may lead to a false sense of security. |
57 |
Clearly, at the end of the day how exactly all these points fit together |
58 |
is dependent on the threat model and what scenarios are more and less |
59 |
likely to happen, which I also pointed out but perhaps not as clearly as |
60 |
I should have. And so is the analysis, assessment of implications, and |
61 |
steps to take following an attack. |
62 |
|
63 |
The only time I referred to non-password methods (such as detached |
64 |
header) was in response to your previous email re header security. |
65 |
Retrospectively, I admit I too may have taken your point into a |
66 |
different, more general direction that takes the discussion beyond the |
67 |
scope of just passwords. For which I'm certainly liable. |
68 |
|
69 |
I hope this clarifies the matter. |
70 |
|
71 |
Best Regards, |
72 |
Victor |