phc-discussions - Re: [PHC] further limitation: not writing secret to memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 20 Sep 2013 18:40:04 +0200
From: Krisztián Pintér <pinterkr@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] further limitation: not writing secret to memory

Tony Arcieri (at Friday, September 20, 2013, 1:10:58 AM):

>> it also does not help on a virtual server

> Well, on a virtual server you have no secrets from the hypervisor,
> and other things to worry about like cross-VM sidechannels:

that is for sure, but if we follow the principle of no branching no indexing on secret, it is not an issue. the issue is that while we might be able to tell the opsys not to page memory, the opsys can not communicate this information to the host VM.

our attack model is, assuming a server hosting virtual servers, having unencrypted swap file:

1. a raid on the server site, confiscation of the hard drives
2. a not properly erased rolled-out hard drive

i agree that this is very slim of a threat. but one must agree that a scheme being not sensitive to that kind of attack is a value. how important it is could be debated.

btw during my years on this planet i have learned that mathematicians can do everything. i might be wrong though.