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-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 18 Sep 2013 12:58:25 -0500 (CDT)
From: Steve Thomas <>
Subject: Re: [PHC] further limitation: not writing secret to memory

> On September 18, 2013 at 12:07 PM Krisztián Pintér <> wrote:
> 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?
This would not work as you can simply xor two values together to remove r. (m0 +
r) + (m1 + r) = m0 + m1

> 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.
I really don't see the point in all of this. Since if the attacker is on the
authentication box then they can access the passwords as users login. Bypassing
the need to even crack passwords. You could use page locked memory. I'm pretty
sure page locked memory (or what ever it is called) never gets written to swap.
Content of type "text/html" skipped

Powered by blists - more mailing lists