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  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 19:16:53 +0200
From: Per Thorsheim <per@...rsheim.net>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] further limitation: not writing secret to memory

A good assumption, but the attacker would need access to the swap file. Physical computer access and no FDE, or somewhat control of the OS.

Another physical attack would be live memory extraction using Firewire DMA. Now that has a limitation today of approx 4GB memory, so excessive use of memory way beyond that would be a good thing.

The cold boot attack could also provide access to "frozen" keys/data in memory, this time by booting from external device with a minimum OS/size, and then search all "frozen" memory in the system, with or without access to computer drives.



Den 18. sep. 2013 kl. 19:07 skrev Krisztián Pintér <pinterkr@...il.com>:

> 
> 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