C Anderson.
| the pinning/zeroing approach was shown in a KB article on encrypting
| files (
http://support.microsoft.com/default...b;en-us;301070 or
| ms-help://MS.VSCC.v80/MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.KB.v10.en/enu_kbv
| bnetkb/vbnetkb/301070.htm)
As I stated, the GC can move the string, ergo you are only zeroing the last
copy of the string, not each time the string moved. Also you may be working
with an alias of the string. Which may or may not be a problem.
Further the "contract" for a string states it is immutable, going behind the
frameworks back to change it is "Breaking the contract".
| I was actually using it on a byte array and not on a string. So, the
| issue about bstr storage hadn't yet arisen
System.String storage <> BSTR storage. System.String is stored in the .NET
heap (its a .NET object). BSTR is stored in a COM heap (its a COM object).
Although both hold "strings", both are very different objects...
A byte array is a reference type, if you assign the array to other variables
you can have duplicates (aka aliasing) again this may or may not be a
problem...
Keith Brown's book "The .NET Developer's Guide to Windows Security" from
Addison Wesley contains a plethora of information on security under Win32 &
specifically .NET. I want to say it included a discussion of "zeroing"
memory. You can access the book on-line at:
http://www.pluralsight.com/keith/book/html/book.html, unfortunately I don't
remember which topics discussed "zeroing" memory.
| the sizeof routines are where my focus has been and I would appreciate
| comments on those
The runtime knows how objects are laid out. This layout can change & does
change between version of the framework. (1.0, 1.1, 2.0, 32-bit, 64-bit) I
sincerely wish you luck on "defining" a consistent "algorithm" for a managed
SizeOf. Unfortunately I don't have links handy to blogs that discuss the
layout changes... I can look if you like.
Hope this helps
Jay
"c anderson" <st*********@hotmail.com> wrote in message
news:ut**************@tk2msftngp13.phx.gbl...
|
| the pinning/zeroing approach was shown in a KB article on encrypting
| files (
http://support.microsoft.com/default...b;en-us;301070 or
| ms-help://MS.VSCC.v80/MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.KB.v10.en/enu_kbv
| bnetkb/vbnetkb/301070.htm)
|
| I was actually using it on a byte array and not on a string. So, the
| issue about bstr storage hadn't yet arisen -- it would have eventually
| since I have some read-only properties that return sensitive data, pass
| keys in constructors, &c. the SecureString call looks like a good fit
| for this and I am grateful for the suggestion.
|
| the posted question about a sizeof operator arose from looking at how
| len(object) works -- it behaves as a byte count for most types, as a
| length for strings (necessitating a 2*len(strvar)), and fails for an
| array type.
|
| the sizeof routines are where my focus has been and I would appreciate
| comments on those -- current versions are appended to the end of this
| post. the approach handles zero-length arrays, n-dimension regular
| arrays (behavior in a ZeroMemory scenario has NOT been tested yet), and
| arrays of arrays (this last was by happenstance and would be of no use
| in a ZeroMemory scenario -- how to differentiate between this and
| n-dimensional is unclear). jagged arrays fail (but I am uncertain as to
| how to catch these without diving into each element -- in which case I
| could compute a size). there are other cases in which it use makes no
| sense, but these would be logical bugs on the part of the developer
| using the functions (e.g. an array of generic objects that resolve to
| other types -- obviously the size of the object array would not be
| meaningful)
|
| *** Sent via Developersdex
http://www.developersdex.com ***