Lunatic Experiments

The hit counter for my blog has just the 10,000 hit milestone today. I had planed to release a comedic themed encryption library for Powershell that shows how some of the functions of GPG can be imitated in Powershell. However, I have not yet finished that library. Instead, I have decided I would release a virtual memory management library I wrote in C#.

One of the projects I'm working on right now required a better understanding of the CPU architectures used today. This inevitably lead me to want to be able to use ASM in C# code. So I decided to start studying NASM and ASM in general, and then found that the .NET heap has execution protection. I then found that I can control the protection bits by calling the virtual memory management functions in the kernel32.dll library. This library is a .NET wrapper for those functions.

The library is documented, but I don't have any example uses that I can release at this time. While I don't have any examples to release today I can say that this library is useful for executing either precompiled or dynamically generated native code.

The library is released under the GNU General Public License.
VirtualMemory.7z

On the topic of ASM: I have read a few negative comments in the past about how well the .NET Framework is able to optimize the native code result of an assembly, particularly in the use of SIMD instructions. I feel I should comment on my experience while developing this library. I tested the execution time of two algorithms written in both NASM and C#. The execution time of the first algorithm I tested was ~10 times faster in NASM than what I got from the C# version. On the other hand, the execution time of the second algorithm I tested was only ~10% faster in NASM than in C#, and only after a couple hours of work to optimize the NASM code.
According to my calculations, the speed result of the second algorithm in C# came very close the theoretical limit of my CPUs capacity, close enough that there would be no way to achieve that speed without the use of wide SIMD instructions. This indicates to me that the JITter in .NET Framework is capable of using SIMD instructions properly, while the same JITter may not always understand the algorithm being JITted. This is actually completely inline of my expectations for any compiler.

I just found something that has reminded me that the U.S.A. is not a democracy. I just discovered that section 1305 of H.R.2346 has the explicit purpose of allowing the Secretary of Defense the unrestricted right to prevent the publication of any photograph taken by US Armed Forces "relating to the treatment of individuals engaged, captured, or detained after September 11, 2001," and this right can not be circumvented by the Freedom of Information Act.
From what I can see, section 1305 was removed from the bill by the House of Representatives, however, passed by the Senate.

It is argued that the events of September 11, 2001 occurred because of an anti-American mentality. It is clear by the date used that the bill is designed to censor evidence of wrong doing by Bush Administration. Condoning actions made by a previous administration that would reflect negatively against the U.S.A. can only perpetuate this anti-American mentality. I can only suspect that anyone that attempts to prevent the publication of the evidence of any act condones the act represented by the evidence.

In summery, I can not see how section 1305 of H.R.2346 could benefit the U.S.A. so I am explicitly stating my dissent to this bill. I hope that anyone with the power to stop ratification of section 1305 does so, and that whoever wrote it is removed from D.C.

I am including a copy of section 1305 for your information.

This is a must see. http://wave.google.com/
This is the best collaborative software that I have seen. The best thing is that it will be free to use and organizations will have the ability to set up their own private wave servers. I am very exited about this and, as you might already suspect, I do have plans for this once it moves into the public.

Today, I went back over the scripts that I use in Powershell to perform encryption to give them and update. I wanted to have a simple script that will perform encryption over a string, using a string as a password, and return a string, because strings are easy to manage in a shell. (I had been using a really complex but really awesome object based encryption script.) Before I started I took a look at what was available on the web. As it turned out there isn't much out there and what is out there is garbage. In particular I saw http://poshcode.org/116 with it's hard coded salt and weak IV selection. It's key schedule as a whole is worthless.

So I open up PSPad and start typing. About an hour of research and 104 lines of code later, I now have a string encryption script that better adheres to cryptoanalytic recommendations, is easier to use, and even supports compression before encryption. I'm normally used to being the first to release any script of any specific genera and don't have any reason to speak down on any other script in that genera. However, in this case, seeing as how poorly the predecessor handles key information, I have to strongly recommend switching to my script as soon as possible if you have been using the script linked to above. To be serious now, since you're data is important enough to encrypt, I would bet you would be rather upset if someone managed to crack your password when your encrypted data does get leaked.

The cryptanalysis of my script is quite simple. The stream cipher is Rijndael, and the key schedule is RFC2898 with a random 256 bit salt that is tacked on to the cipher message(just as it should be). Don't understand all that? Don't worry. The only weakness here will likely be the passwords you use. I'm sure you have heard it a hundred times: make passwords that are hard to predict and change passwords as often as possible. You can make the password as long as you want and use any characters you want. Also don't store passwords anywhere someone else might see them. For further cryptanalysis look up Rijndael and RFC2898.

I had to add in compression because the moment just before encryption is the last chance you get to do compression. Not only is it the last chance, but generally also the best time to perform compression. Compression works best on uncompressed data and when there is a great amount of it. Compression also will not work at all on encrypted data. Beware that compression will not work for very small parcels of information. You'll want a string of at least 1500 characters before you can get any benefit out of using compression.

Library-StringCrypto.ps1

I can't imagine any uncool way to use this so if you find a use for this I would like a comment here or on Twitter @aitsusan so I can hear about it.

Important Update:

I have already rewritten this script. The changes are wide enough to make the old version and the new version incompatible, but I'm going to use the same script name anyway, because I feel this update to be very important for the security of any person that uses this script.

If you have Library-StringCrypto.ps1 version 1.0 please download version 2.0 now.

The change is an addition of an HMAC. What this means is that now the script can more effectively detect any corruption of modification to the encrypted data. In version 1.0 no direct method of detecting corruption was implemented. This raises a potential security hole where an attacker could modify the cipher string in a way that would result in garbage being returned in the decrypted string, and not having any exception thrown.

The lack of a HMAC before could have caused a script, that did not on it's own perform any authentication, to reveal some information about the encrypted data to an attacker or could have caused the script to otherwise behave in an unexpected manner. Now, with the HMAC in place an exception is thrown before any of the data is decrypted, none of the remaining encrypted data can be leaked and the script should then terminate.

Check out this blog post from the Powershell Team. It shows how you can make variables in Powershell behave as global static properties. Be sure to grab the New-ScriptVariable script.
Note that it uses the Add-Type cmdlet available in Powershell 2.0. If you don't have version 2.0 then Add-Type can be replaced with my New-CAssembly script. It's a really easy conversion. In fact I already converted it and is available from my SkyDrive.