Path: csiph.com!usenet.pasdenom.info!news.albasani.net!newsfeed1.swip.net!uio.no!hist.no!ntnu.no!not-for-mail From: Bent C Dalager Newsgroups: comp.lang.java.security Subject: Re: secure erasure of Java key/password buffers Date: Tue, 17 Jul 2012 14:15:51 +0000 (UTC) Organization: Norwegian university of science and technology Lines: 31 Message-ID: References: NNTP-Posting-Host: microbel.pvv.ntnu.no Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: orkan.itea.ntnu.no 1342534551 12962 129.241.210.179 (17 Jul 2012 14:15:51 GMT) X-Complaints-To: usenet@ntnu.no NNTP-Posting-Date: Tue, 17 Jul 2012 14:15:51 +0000 (UTC) User-Agent: slrn/pre1.0.0-18 (Linux) Xref: csiph.com comp.lang.java.security:253 On 2012-07-17, mortadelo wrote: > Hi everybody, > > I’ve just stumbled across some crypto interface code written in Java where buffers of (sensitive) data/keys are not explicitly erased (zeroed out) after use. Coming from a C programming background where explicit zeroing out of memory after use is highly recommended, I’m wondering whether this should also be done in Java. I understand that it’s impossible to guarantee efficient erasure of all possible instances of a data object in Java. If you are going to pursue this then you should first decide what degree of perfection you demand. Even C cannot guarantee that a deleted piece of information is in fact deleted, because the language cannot know of any copies that might exist in page files, swap files, caches, etc. You need the active participation of the OS to make sure such copies are deleted, and even the OS cannot know if its various storage devices contain extraneous copies of the information (such as routinely happens on an SSD for instance). For /this/ you would need the active participation of the hardware drivers and ultimately the hardware itself. Security can be infinitely expensive depending on your demands, so having a clear idea what exactly your demands are is essential. Personally I never quite understood the purpose of the char[] replacement for JPasswordField.getText() because with all the object copying, paging, caching and other shenanigans that happen all the time in a modern computer, zeroing out the char array seems like such a very very weak form of security. But perhaps very very weak is just exactly what is called for in some area or other that I am not familiar with. Cheers, Bent D -- Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd powered by emacs