PBKDF2 for Compact Framework

Filed in Software Developement Leave a comment

Our company wanted to use a secure method of remote login using Windows Mobile devices. The go to method for secure password storage and authentication is with PBKDF2 (as described at this very informative password storage article), however the compact framework lacks the necessary classes (see the Rfc2898DeriveBytes Class). The compact framework is completely capable of the PBKDF2 logic, so it was just a matter of porting the logic into the Compact Framework environment.  You may see that some others have created their own versions of PBKDF2 (or attempted to at least), like OpenNETCF (withPasswordDerivedBytes and HMACSHA1) or BouncyCastle (though not specifically available, the components exist to product a PBKDF2 function).

What i found after initially researching this topic was that OpenNETCF has a broken implementation and BouncyCastle was a lot of extra work just to get what i wanted (not to mention the massive footprint). What i really wanted something small, simple, and something that used as much built-in framework as possible.  The solution was reasonably simple, port the minimum required framework from the desktop assemblies into a small compact framework library.

I needed to port at the very least the HMAC, HMACSHA1, and Rfc2898DeriveBytes. In porting i decided to also include DeriveBytes, and KeyedHashAlgorithm (mostly for consistency and completeness).  I additionally included a small subset of the (internal) Utils class.  The port is almost verbatim, though a few changes were required, i’ll detail the most obvious ones below.  The result is an almost identical PBKDF2 library to the desktop assemblies which allows you to generate on desktop or CF and validate on desktop or CF, both functions will generate the same hashes.

Minor Modifications

  • HashAlgorithm.HashValue is protected internal, so i cannot access it directly from HMAC (i use the ever so slightly slower .Hash instead).
  • Buffer.InternalBlockCopy is replaced with Array.Copy (probably slightly slower)
  • All attribute decorations were removed
  • All exceptions generate less than preferred exception messages (i don’t have access to the internal resources to get the full exception message).

*** WARNING ***

I cannot guarantee the safety of this library, it SHOULD be identical in operation as the desktop library but porting could have introduced one or more bugs. Please do your own due diligence and inspect the code for yourself before using it in any security critical way.

If anyone does discover an issue please let me know so i can correct it.

The project is now hosted on Codeplex, the source is available for anyone to use (New BSD License).  Enjoy.


Important note when updating LINQ-to-SQL view fields

Filed in Software Developement Leave a comment

I am working on a complex project right now where I am using LINQ-to-SQL with some complicated views. I need to at some times updates some of the fields on these views. I know this is possible because you can achieve this in SSMS (note that you can only update fields which already exist, NULL outer join fields will not update since they don’t actually exist). Anyways, I would get my row via the view from the data context, then update the property corresponding to the field. But when I called SubmitChanges() nothing would happen, the database would not be updated.  So to debug I would attach the data context logger to Console.Out so I could visualize why it wasn’t working. The log was empty on the SubmitChanges() call, which was troubling.

The solution to this problem is to make sure your views have a Primary Key field set. By default your views won’t have this property set because it’s ambiguous on a view. But you can specify this in the property editor when the field is highlighted. If your view doesn’t have the equivalent of a primary key then you are SOL because you cannot update a view field without a PK.  Once I specified the PK on the view, the updates started working.

This behaviour, while it make perfect sense, is simply not obvious and very difficult to track down if you don’t realize what the problem is. It’s too bad there isn’t some sort of warning from LINQ-to-SQL when you generate a view with no PK field set.  Anyways, simple solution to an otherwise difficult to track down problem.

, , , ,

AsyncTask in MonoDroid the .NET way (Task Parallel Library)

Filed in Software Developement 2 Comments

I was looking into how to implement an async task in android last night, specifically to download some content from the web in the background.  Obviously, I was interested in using mono for android, so I started off by created a new ICS project and started researching AsyncTask<T1, T2, T3> which is what I had remembered looking into a while back.  It didn’t take long before I realized that this strategy was not the direction I wanted to go. My main problem with the AsyncTask framework is that you must extend the class for each specific type of task you want to perform. You can param it with generics, but really I just hate cluttering the project with all these extended classes (I’m not on that java bandwagon, even a little).

I wondered how .NET did this natively. I know that in the past I have usually just used the ThreadPool and sometimes the BackgroundWorker (though very rarely).  But I figured by 4.0 .NET must have come up with a decent solution for async task management. The answer is the Task Parallel Library (or TPL).  Even more interesting is the new async task framework (in .NET 4.5) but I will wait until the new visual studio is RTM before I jump on that.

TPL has a lot of features that I consider very useful, the biggest being that it’s agnostic to your task and that it supports hierarchical task control.  Tasks are defined using delegates (lambda’s) and you can combine any number of tasks into simple or complex hierarchies that will execute according to your needs.  The only downside to TPL is the lack of native progress reporting, though the work around to this is so easy it’s hardly a downfall.

I wrote a (VERY) simple monodroid app to showcase how to leverage the TPL.  This demo simply starts a progress counter on a background task, updates the UI with regular progress updates, and allows immediate cancellation of the task.  The primary task also includes a continuation task that would perform task clean up.

using System;
using System.Threading;
using System.Threading.Tasks;
using System.Linq;

using Android.App;
using Android.Content;
using Android.Runtime;
using Android.Views;
using Android.Widget;
using Android.OS;

namespace AsyncTaskTest
    [Activity(Label = "AsyncTaskTest", MainLauncher = true, Icon = "@drawable/icon")]
    public class Activity1 : Activity
        private TaskScheduler Scheduler { get; set; }
        private CancellationTokenSource Cancel { get; set; }
        private Task<int> ProgressTask { get; set; }

        private Button Button { get; set; }

        protected override void OnCreate(Bundle bundle)


            Button = FindViewById<Button>(Resource.Id.MyButton);
            Scheduler = TaskScheduler.FromCurrentSynchronizationContext();

        protected override void OnResume()

            Button.Click += ButtonClicked;

        protected override void OnPause()

            Button.Click -= ButtonClicked;

        private void ButtonClicked(object sender, EventArgs e)
            if (ProgressTask == null || ProgressTask.Status == TaskStatus.RanToCompletion)
                ProgressTask = CreateTask(1000);
                Button.Text = "Cancelling...";
                int val = ProgressTask.Result;
                ProgressTask = null;
                Button.Text = string.Format("Cancelled at {0,3}%", val);

        private Task<int> CreateTask(int count)
            Cancel = new CancellationTokenSource();
            var task = new Task<int>(() =>
                var progress = 0;

                foreach (var i in Enumerable.Range(1, count))
                    if (Cancel.IsCancellationRequested)
                        return progress;

                    progress = i * 100 / count;

                    Task.Factory.StartNew(() =>
                        Button.Text = string.Format("{0,3}%", progress);
                    }, Cancel.Token, TaskCreationOptions.None, Scheduler);


                return 100;
            }, Cancel.Token, TaskCreationOptions.None);

            task.ContinueWith(_ =>
                Button.Text = "100% DONE";
            }, Cancel.Token, TaskContinuationOptions.None, Scheduler);

            return task;

As you can see, the lack of native progress reporting is replaced simply by a new temporary task that’s started with the UI scheduler. By using the scheduler like I have, you can perform UI operations in the middle of a background task, without making the thread context complain about access.  I like the simplicity of this TPL, but I really cannot wait to get into .NET 4.5 with the new async task framework, things will be even simpler and cleaner.

if you want to try out this demo code, just create a new mono for android application in visual studio, and replace the Activity1.cs source code with the source code above. I tried to keep the demo code as simple as possible so I was really only showcasing what the TPL could do in monodroid.

, , , , ,