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  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]
Date: Wed, 18 Sep 2013 19:07:10 +0200
From: Krisztián Pintér <>
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.

Powered by blists - more mailing lists