[Mono-bugs] [Bug 44848][Wis] New - Zeroize data upon GC collect

[bugzilla-daemon@rocky.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by spouliot@videotron.ca.

http://bugzilla.ximian.com/show_bug.cgi?id=44848

--- shadow/44848	Sun Jun 15 14:30:42 2003
+++ shadow/44848.tmp.27836	Sun Jun 15 14:30:42 2003
@@ -0,0 +1,38 @@
+Bug#: 44848
+Product: Mono/Runtime
+Version: unspecified
+OS: All
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Wishlist
+Component: misc
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: spouliot@videotron.ca               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Zeroize data upon GC collect
+
+Description of Problem:
+
+After I recently added the code to zeroize the private keys for DSAManaged 
+and RSAManaged, Ben told me that the BigInteger code could still leak some 
+secret information in temporary buffers. This is difficult to fix while 
+keeping good performance (e.g. when generating new keypairs) as only a 
+very small portion of buffers actually contains secret data.
+
+The same situation is also true when manipulating strings (like passwords) 
+or other objects that do not zeroize their informations because they're 
+seldom used to handle secrets (e.g. data received from a web page in an 
+SSL session).
+
+So the wish is "Would it be possible to zeroize all buffers in the runtime 
+when the GC reclaims them ?" (and not when they are allocated).
+
+If so I believe that the performance impact would be much lower in the 
+runtime (C) than in the class library (C#). It would also be much safer 
+because it will (a) clear all data, (b) act as a second (albeit late) 
+zeroize for sensitive data. Anyway this shorten the vulnerability window.