I'm happy to have another partner- in- debunking- broken- crypto here and so a little giddy at seeing the 'tzs comment, but he missed some stuff.

Grab the source code and you'll see that --- at least as regards the cryptography components of this application --- it's practically the "Hello World" example from the MSDN System.Security.Cryptography documentation.

That's not in itself a problem; lots of "hello world"-grade libraries are useful. Unfortunately, like every other low-level crypto library, the MSDN documentation does an appalling job of showing how to write a secure cryptosystem. Blame the docs, blame Microsoft, blame the developer, but this program gets a bunch of things painfully wrong.

By way of bona fides and to start this off: I'm pretty sure that using PBKDF2 to generate the key and the IV for AES-CBC is broken; it produces a deterministic repeating IV for every message encrypted under a given key. Had the default mode for AesManaged been CTR, or had the developer chosen CTR mode, this would be a devastating problem; it would mean attackers without knowing anything about the key or even the encryption method could, in seconds, discover that CTR mode with a repeating nonce had been used and decrypt the messages. Fortunately, since the .NET default is CBC, it just subtly weakens the cryptosystem instead of killing it.

Why-oh-why derive the IV from the key? An idiom in modern cryptosystems: generate a random block and tack it to the front of the message.

Do you want to entrust your secret messages to developers who get this wrong? Only if you want to do that developer a favor. It's fine if you do, but I recommend trusting your real secrets to GPG/PGP.

There are significantly worse problems with this library (at least, I think; I read it for just a few minutes). Exercises for the interested reader.