[Remops] Encrypting Remailer filesystem

[Grant Taylor]

On 5/28/19 11:07 AM, Lance Cottrell wrote:
> The decrypted message will eventually be sent in the clear, that is with 
> that remailer’s layer of encryption removed.

Agreed.

/Eventually/ being the operative word.  As such, there is a timing 
component to the attack.  Meaning that either the sniffer needs to be 
ongoing.  If it's not ongoing, then there is a smaller time window.

It's an exposure.  I don't know how important it is.

> Having only the decrypted versions stored means that an attacker would 
> have more difficulty seeing which incoming encrypted email corresponds 
> to each decrypted outgoing email.

How so?

Are you implying that an attacker could get the keys and decrypt the 
message to see the encrypted and decrypted?  Where as if it's decrypted, 
it's much more difficult to see the encrypted counterpart?

> Generally, if an attacker owns your box, there is trouble. It is likely 
> that they could get encryption keys and all the rest.

Agreed.

I'm more thinking about the possibility of a misconfiguration / 
privilege escalation that would allow another non-privileged user to 
access the pool somehow.  Say after an admin naively does a chmod -R 777 
/ or some such ill-advised activity.

> Can you describe the attack and revealed information that this issue 
> would allow, but which would not expose much worse at the same time?

No, I don't have an example (save for the chmod above).  I'm more 
thinking out loud ~> discussing.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mixmin.net/pipermail/remops/attachments/20190528/8367b4a9/attachment.bin>