phc-discussions - 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-next>] [day] [month] [year] [list]

Message-ID: <1345886200.20130918190710@gmail.com>
Date: Wed, 18 Sep 2013 19:07:10 +0200
From: Krisztián Pintér <pinterkr@...il.com>
To: discussions@...sword-hashing.net
Subject: further limitation: not writing secret to memory

maybe not thoroughly interesting, but i was worrying about large memory use, in the light of the priciple of "clean memory of secret data". large memory hugely increases the chance of being written to a the swap file. after this, cleaning secret becomes virtually impossible.

the worst case would be if the attacker accesses the first piece of data written to the memory, and brute-force searches for a password that produces that particular data. effectively skipping the entire memory hardness.

maybe it is enough to simply xor the values with a random constant? the random value will not likely be swapped, being used frequently.  would it create any vulnerabilities? like if i have access to m0+r, m1+r, m2+r, m3+r, knowing the way how mi values are generated, i can infer r?

another straightforward solution would be encrypting the data, for example with salsa12, using a random key. the problem with this approach is that it adds some more processing on the defender side, but not on the attacker side. i wonder if there is a theoretical possibility to use some randomization, but in a way that can not be skipped.