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

Message-ID: <5c5086da436e40d18eaaff4f4ba6eb16@BLUPR03MB166.namprd03.prod.outlook.com>
Date: Fri, 20 Sep 2013 19:25:12 +0000
From: Marsh Ray <maray@...rosoft.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: RE: [PHC] further limitation: not writing secret to memory

From: Tony Arcieri [mailto:bascule@...il.com]
>
> Windows is the real problem here. It supports a proprietary API
> called VirtualLock to accomplish the same thing:
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa366895(v=vs.85).aspx

What part of

   // "Locks the specified region of the process's virtual address
   // space into physical memory, ensuring that subsequent access
   // to the region will not incur a page fault." - MSDN
   BOOL success = VirtualLock(void * base, size_t size);

is particularly problematic?

Locking large portions of memory for non-negligible periods of time
is generally a bad idea on any virtual memory OS. Most servers
are on hypervisors these days, so it's not even guaranteed to be
meaningful.

IMHO, the PHC should consider virtual memory an implementation issue and
not a requirement for candidate functions. But if there were some
function submitted that had an innovative approach to the issue,
it would be interesting to hear about it.

- Marsh

Content of type "text/html" skipped