[Remops] Encrypting Remailer filesystem

[Lance Cottrell]

The decrypted message will eventually be sent in the clear, that is with that remailer’s layer of encryption removed.

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.

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

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

	-Lance

--
Lance Cottrell
loki at obscura.com




> On May 27, 2019, at 9:48 PM, Grant Taylor <gtaylor at tnetconsulting.net> wrote:
> 
> On 5/27/19 12:39 PM, Stefan Claas wrote:
>> I am refereing to the pool, or the location where the remailer and it's files, including the pool, resides.
> 
> ACK
> 
>> IIRC as soon as a Remailer receives it's files it decrypts them so that the packets are then encrypted for the next hop and for an exit the files are decrypted in the pool (if they are final) prior leaving the pool. Someone please correct me if I am wrong!
> 
> Thank you for the clarification Stefan.
> 
> I don't see a good way on Linux (or any other OS that I'm aware of) to have messages be unencrypted for Mixmaster, yet inaccessible (as if encrypted) beyond standard OS file system access control mechanisms.
> 
> This makes me wonder if this might not be a security related bug in Mixmaster and that perhaps it shouldn't permanently decrypt messages until it's ready to send them out.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 
> _______________________________________________
> Remops mailing list
> Remops at lists.mixmin.net
> http://lists.mixmin.net/mailman/listinfo/remops

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mixmin.net/pipermail/remops/attachments/20190528/b89ee330/attachment.html>