Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by krbdev.mit.edu (8.9.3) with ESMTP id UAA14414; Tue, 1 Apr 2003 20:16:32 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h321GWK0005892 for ; Tue, 1 Apr 2003 20:16:32 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h321BJKb026911; Tue, 1 Apr 2003 20:11:41 -0500 (EST) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h3217bU8008345; Tue, 1 Apr 2003 20:07:37 -0500 (EST) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.9.3) id UAA16614; Tue, 1 Apr 2003 20:07:37 -0500 To: krb5-bugs@MIT.EDU Subject: zapping sensitive data before freeing From: Ken Raeburn Date: Tue, 01 Apr 2003 20:07:37 -0500 Message-Id: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-RT-Original-Encoding: us-ascii Content-Length: 560 See the thread "use of memset and optimization" in the krbdev list archives, starting 7 November 2002, also reported on the RISKS, cryptography and cypherpunks lists. When freeing key data, we should first zap the contents, with something better than memset since gcc can optimize that away in certain cases. A memset call with a pointer to volatile should be sufficient, though we probably don't want all key data to be volatile everywhere. Changing krb5_free_keyblock isn't enough; we should also zap key schedules, ASN.1 buffers that hold key data, etc.