Installer projects in Visual Studio are for creating the Setup.exe and the MSI for installing the other projects in a solution. However, I discovered an oddity that caused havoc with our source control system. Continue reading
I came across a pattern in .NET that I’d not thought of before. The scenario is, I’m reading from a file and deserializing it’s contents (a List of ‘Foo’ objects). Exceptions can be thrown at two points:
Obviously, I want to make sure that the file handle is released if the deserialisation fails. However, I can’t deal with that in a single try block, as if the exception is in the file IO, then the file handle won’t exist to close in a finally block! Continue reading
The .NET framework is a bit confusing until you get your head round the components of it, and the way that Microsoft name things.
.NET has a thing called the common language runtime (CLR). (This is the .NET equivalent of the Java Runtime). Different versions are essentially different VMs, and can coexist. The CLR runs code that is an Intermediate Language (IL) (aka the Common Intermediate Language (CIL)). Whatever code you write in C# or VB.NET actually only gets partially compiled into IL code. It’s a lot like Java Bytecode.
The Base Classes are the library of DLLs for the framework (and are sometimes incorrectly referred to as the framework). Think of it as Win32 for .NET. These constitute the .NET API – and have different versions too. A different version of the base classes, though, does not mean a different CLR – for example, frameworks version 2, 3 and 3.5 all use the same CLR, but present a different external API and have different language features. Indeed, the base classes of framework version 3.5 are a superset of version 3, which are a superset of 2. This means framework 2 code will run on machines with the 3.5 installed.
(Note to self – must remember – C# version is independent of Framework version)
|
|
Framework Version 1.1 |
Framework Version 2.0 |
Framework Version 3 |
Framework Version 3.5 |
|
CLR |
1.1 |
2.0 |
2.0 |
2.0 |
|
Library versions |
1.1 |
2.0 |
3.0 (including 2.0 sp1) |
3.5 (including 2.0 sp1 & 3.0 sp1) |
Similar chart here:
http://www.leonmeijer.nl/archive/2007/06/11/50.aspx
…though the Microsoft guy who presented to me didn’t say anything about a CLR 3.0. I suppose there may be one which is backwardly compatibile?
More Windows forms stuff. I don’t like really complex Web forms controls ‘cos sometimes they seem a bit flakey – but I’m beginning to wonder if Windows Forms stuff is any better.
Two problems with the DateTimePicker. First, it can’t have a null value. What? You might not want to have a value in it? That’s craaazzzy! Inconceivable! What do you mean that your database tables allow null values in a DateTime column?
All you can do is set ShowCheckbox to ‘true’. This will give you a little checkbox, to turn on or off the editing of the value. You could then wrap the DateTimePicker, and return yourself null if the ‘Checked’ value is false.
Secondly, it has no BackColor property, so I couldn’t colour it pink when the field was invalid, meaning it had to have a value – therefore, the checkbox mentioned above has to be ‘Checked’. I managed to get around this by subclassing the DateTimePicker – but had some problems when you then focussed on it to try to edit it. My solution (below) was to turn off any background colour during editing…
I’ve been doing some Windows forms programming lately – not really my thing, but needs must. I’ve got an application which needs to dynamically create a form at run time, and so I’m using a System.Windows.Forms.TableLayoutPanel.
All the controls contained by the TableLayoutPanel resize automatically, and the TableLayoutPanel automatically provides scrollbars. “Great!”, I thought, “This will deal with large forms nicely.” Wrong!
The problem is when form has too many fields – it becomes deeper than the display area of the TableLayoutPanel. This is fine – the TableLayoutPanel should automatically add a vertical scrollbar, and adjust the size of the controls it contains to fit in the smaller area. Except it doesn’t. What I actually get is this:
Notice that I’ve got a vertical scrollbar, but it hasn’t resized the child components. This, they overlap some of the fields – and I now have a nice horizontal scrollbar. Arse.
I eventually found that others had had this problem and told Microsoft about it. However, they’ve decided not to fix it. Thanks Microsoft, that cost me an hour and half – it’d be wise to fix it. I found the answer from the same link – add a vertical scrollbar’s width as padding on the right of the TableLayoutPanel.
I keep using this snippet of code:
if( window.addEventListener ) {
window.addEventListener("load", fn, false );
} else if( window.attachEvent ) {
window.attachEvent("onload", fn );
}
It’s just a tidier way of attaching a function ‘fn’ to an event. It also allows multiple handlers per event. There could be another ‘else’ where we just assign the function to an event (e.g. window.onload = fn ) but that would only support one handler per event.
I keep forgetting how to do this, and have to do so every time I want to create a new SharePoint workflow.
Comments from my old blog:
Are you using your own project templates? I’m curious because using the MOSS Workflow Project templates (both state machine and sequential)–the templates that come with the MOSS SDK–and I have the snippets already available to me.
Anyway, just throwing that out there.
Nope, these are the ones out of the SDK. I’m not clear why, but in some VMs that I use the snippets aren’t immediately available after I install it. And normally the ‘Code Snippets Manager’ is already available too – but not always. I haven’t figured out what factor causes these things to occur :/
But yes Peter, you’re right – normally they should be available.
So, I’ve been forced to spend a couple of weeks modifying some code I wrote a couple of years back, in VB6. One word – crap. That’s the word for both the language, and my code.
Visual Basic 6 is just painful to code with. ‘Dim’? I’d say. The inability to return arrays from a function keeps catching me out. And I detest the way that no matter what I do, I can’t stop Visual Studio beeping errors at me and show message boxes when I try to leave an incomplete line so that I can copy and paste a variable name.
The worst part is, though, that it doesn’t really promote good program structure – well, not to me anyway. I’m often not entirely convinced that Object Oriented Programming actually reuses much code – but it does force it to be structured and organised. My code in this project, well, it isn’t. It’s suffered that sort of ‘evolutionary’ growth rather than proper, designed expansion. And some of it has to excapsulate an API that is archaic, irritating, and dangerous. (I’ve been debugging for memory leaks, dammit. Yes, this API forces me to allocate/deallocate memory).
What a sucky language. It really makes you appreciate Java/C#.
I was reading about security stuff in the .NET framework, and dealing with cryptographic classes in it, and it sort of set me wondering. Here are all these different encryption classes, with different block and keys sizes, cipher modes, all that jazz – but what are their performances like? Specifically, I’d read something saying how some ‘weaker’ encryption algorithms are better (in some speed-critical applications) ‘cos they’re faster. I wondered how much?
Thus, I decided to benchmark the Symmetric alogrithms in the .NET Framework – DES, Triple DES, RC2 and Rijndael. To make life interesting, I thought I’d try them with differenct key sizes and block sizes, and cipher modes.
So, I’ve linked to definitions of these factors, but for those who don’t want to read vast chunks of Wikipedia, here are my (simplified) definitions. For anyone really interested in learning how to program with encryption properly (and in learning why their 128 bit key probably isn’t 128 bits strong) I can strongly recommend the book ‘Practical Cryptography’ by Bruce Schneier and Niels Ferguson.
Symmetric ciphers are ones like you used when you were a kid. You have some operation that turns a message into garbage, and then the reverse of that operation turns that garbage into a message. Some algorithms don’t have a reverse – they are asymmetric ciphers, and are a whole different kettle of fish.
Keys are the password you use with your cipher. For example, if you’re cipher as a kid was to shift all letters in the alphabet, then the key might be the numbers of characters shifted. Big keys are harder to break. Think of it as being just like a password or PIN number. If I tell you that my PIN is 4 digits, you might be tempted to guess all 10,000 possibilities, and on average you’d figure my PIN out after 5000 tries. If my PIN was 8 digits, then there is 100,000,000 options – and you’re less likely to try all the possibilities, eh?
Block sizes. Well, okay, some ciphers work on blocks of data, rather than each byte (or each ‘letter’). These are block ciphers. There are also stream ciphers, where each byte is encrypted one by one. Anyway, in block ciphers there is a limit to how much data can be encrypted without ‘leaking’ information. Larger block sizes can encrypt more data without that leakage. (That’s not to say that the block has been decrypted, but an attacker could start to learn things about the contents of that block.)
Cipher modes don’t really have a parallel with how you did codes as a kid. I guess I would describe it that if the cipher is about how you make an apparently random set of bits, then the cipher mode is about how you then use them. There are lots of different modes, but the .NET framework classes only seem to support 3 – ECB (Electronic Cookbook), CBC (Cipher block chaining) and CFB (Cipher Feedback).
So, what are the algorithms:
The Test
I found a nice text file – “The complete works of Shakespeare” – as my test data.
For each algorithm, for each mode, key and block size, the test program encrypted and decrypted the data twenty times, and reported the average ‘time’ for each operation. I was using the Win32 QueryPerformanceCounter function, which doesn’t really return a time so much as cycles. However, all the tests were done on the same machine, so they’ll do just fine for comparison purposes.
Results
With the several factors tested, there are many ways of slicing the data. It’s worth noting that these results are pretty rough, as the times taken also include file IO operations, and with any modern PC there’s also something else happening at any single time. Also, the times are the total time taken to encrypt and decrypt, which might not be the same for each operation. Treat the results as a loose guide.
First let’s look at the raw results. You can get the results here (Excel file).
Unsurprisingly, DES is fastest – given it’s age, and the low level of security it offers now. Triple DES with the longest key it supports was generally slowest. RC2 covered the full range of results, which is also unsurprising, given it’s flexibility, and Rijndael sort of falls in the middle.
The first thing I noticed was how few tests there were using DES or Triple DES. RC2 and Rijndael are much more flexible in their use.
Next, it’s interesting to note that RC2, DES and Triple DES using Cipher Feedback Mode (CFB) were all very, very slow. They all seem to suffer very badly using CFB.
So, excluding the CFB results then (as they are so exceptionally slow), what do the other results show? Well, Rijndael does not suffer so badly in CFB, although CFB is slower.
ECB appears slightly slightly faster in the table, though examining the CBC Mode Graph shows little difference.
To compare the modes, I looked at just the operations done with the Rijndael cipher.
Again, we see little difference between ECB and CBC, so I guess there’s no reason not to use the more secure CBC mode over ECB (for an example of it’s weakness see here). Also, for 128 bit blocks (as required by the AES standard), CFB is as quick as ECB.
Rijndael is not great in CFB mode with blocks of longer than 128 bits.
Okay, so let’s focus on just one mode (CBC) and look at the results shown in the CBC Mode Graph. Well, it’s interesting to note that RC2 with a 112 bit key was quite quick – faster than with some shorter keys. However, it’s only about 6.5% longer to use 128 bit Rijndael – which is a key that is 14% longer. Doubling the key with Rijndael to 256 was only 10% longer than 128.
Longer blocks take longer to encrypt and decrypt. 64 bit blocks seems a little short these days, only being safe for up to a couple of hundred megabytes. 128 bits seems more reasonable. 256 bits seems excessive. Rijndael seems to have little penalty for using 256 bits over 128, though if you do, you’re not using an AES standard encryption.
Conclusion
DES and Triple DES are old. DES isn’t secure, and Triple DES doesn’t seem to offer much given Rijndael and RC2 being much faster than it.
In terms of cipher modes, these classes only seem to support ECB, CFB anc CBC. ECB is generally regarded as being a poor mode – it’s not very secure. CFB was typically slower than CBC, and as Microsoft have already implemented the classes, some of the advantages CFB (i.e. encryption and decryption being identical operations) have been lost.
So, then examining Rijndael in CBC mode, well, there is little penalty for using 256 bit keys or 256 bit blocks. However, it’s probably worth sticking to 128 bit blocks as 1) it is plenty, and 2) it is AES compatible.
All in all, I was surprised by how similar a lot of the results were for different algorithms, and I was surprised by how slow some of the CFB mode operations were.
To be honest, I can’t really think of a reason not to use Rijndael with 128 bit blocks, in CBC mode. Unless time is a really critical factor, 256 bit keys are stronger. Finally, the RijndaelManaged class in the framework is a managed class, rather than a wrapper for a COM object.
So, the winner is Rijndael!
Comments from my old blog:
This is a very informative article. I have just started looking into encryption, and I have come across nothing on the internet that is as concise as your article.
Will you be doing something similar with asymmetric encryption as well?
Yup, well, at some point. The truth is, in the .NET 2.0 framework, there isn’t a lot of other asymmetric algorithms. RSA is about it. I think in the .NET 3.0 framework there is elliptical curve, and that would be interesting…
So, yes, when I get around to it.
So, I was trying to do some encrypted comms over TCP, only rather than using SSL, I thought I’d try to RSA encrypt and decrypt at client and server myself. I know, it’s re-inventing the wheel – the point is to get to know the APIs though, and it seemed a good exercise.
I started getting an error though – “Key not valid for use in specified state”. Odd. I was importing the key from an XML file, using the FromXMLString() function. It all seemed to work just fine. So, WTF? It’s not like the code is complicated:
RSACryptoServiceProvider rsa = new RSACryptoServiceProvider();
rsa.FromXmlString(publickey);
byte[] encryptedData = rsa.Encrypt(data, false);
So what gives?
Well, eventually, I tracked it back to this – I was trying to send too much data. Not very much – less than a couple of hundred bytes – but this was too much.
The obvious thing to do was change the way this works to match the way it’s supposed to work – use RSA encryption to transfer the key to a block cipher, and then encrypt all your data with that block cipher. But I couldn’t be arsed – I just wanted to see the asymetric encryption work – so I reduced my data…
Comments from my old blog:
Sounds like you where in the 70-536 Self Study book from Microsoft. In chapter 12 doing some suggested practices.
Anyway.. that’s where I am and your message here on the blog helped.
I too will send a smaller file 
Yup, I think I was. It was a bit daft that they didn’t mention the limits on the size of the data.
But that book has a _lot_ of issues.