Wednesday, June 29, 2011

Milestone, MCTS for SharePoint 2010 App Dev (70-573)

As of today, I am an MCTS in SharePoint 2010 (Application Development).

:)

It feels GREAT!  The test is harder than it looks!

Saturday, June 25, 2011

Dual 9-Segment LED Display Module with Points


DRAFT SPECIFICATION
Dual 9-Segment LED Display Module
With Points
By @SparkDustJoe
Open Hardware, No trademark or patents

I’m not great with microcontrollers and surface mount components, so I’m putting out this spec document and hoping someone runs with it.
What I’m looking for is a module with 2 digits, capable of displaying some simple English or Latin alphanumeric characters, and a few special characters (think degree symbol, apostrophe, +/-, etc.).  The module also includes 4 dots next to each digit (to the right) for decimals, colons, am/pm indicators, etc.
This module will have either traditional serial (9600/8N1) or SPI serial inputs with cascade capability, and the possibility of being addressable.  
The diagram at the top is a simplified version of what I’m looking for.  The actual individual digit height should be closer to 3”-5” (read, three to five INCHES) high with individual surface-mount LED’s grouped together to make up the segments.  For easy mounting behind glass or acrylic, the components should be on the opposite side as the LED’s, and with the possible need for a MAX7219 (or equivalent) chip along-side the microprocessor, the board will be have to be double-sided.  The segments and points should be close enough to the left and right sides to allow for easy stacking side-by-side for longer displays (think clocks, scoreboards, etc.).  Mounting holes at the top and bottom are acceptable and preferred.  If the usual slant or angle found in most LED/LCD displays push the dimensions outside the realm of possible, then the digits and points should simply be vertical.
The actual data input should be easy and intuitive for the end-user to allow for quick development.  The schema for commands should allow for direct segment control or simple alphanumeric input.  The simplest form would be “AcVV”, where A is an address between 0 and F (up to 16 stacked modules allowed),  c is the command type, and VV would be the values of the left and right digits OR the middle and right sets of points respectively.  In the case of the points, they are turned on or off like flags in a 4-bit number, 0 being all off, F being all on.  For direct segment control, the command would look more like “AsXXXYYY”, as that requires a larger input to accommodate all the bits.  Any invalid or malformed command is simply dropped.

Commands (always lower case):
a = ASCII input (not every character can be displayed in 9 segments, upper and lower case are treated as the same)
d = Digit input (0-9, A-F, upper and lower case are treated as the same)
p = Points (binary flags for each of the 8 points).
s = Segment (raw binary control of the 18 segments)
e = Erase (no other input, just blanks all segments and points, and removes them from memory, the module is still considered "awake")
b = Blank (no other input, just blanks all segments and points, but leaves them in memory until a wake command is received.  Essentially puts module to "sleep".  All future commands will still affect memory, but they will not be displayed)
w = Wake (display current memory to the segments and points)
; = separator, more than one command on a line allowed when separated

Examples:  

“FaWY” would set module 15’s digits to the characters W and Y.  

“4e” would blank the digits and points of module 4

“3pF0” would turn all the points in module 3 in the middle ON and on the right side OFF.

“0d 9;0p06;1d45;1p08” would set the digits on module 0 to blank and 9, and set the points in the middle OFF, and the middle two right-most points ON, and the digits on module 1 to 4 and 5, with the middle points OFF, and the top right-most point ON.  This displays [ 9:45’] (for a clock, 9:45 PM).

For actual segment control, each segment is a bit in a 9-bit number as follows (refer to the diagram at the top):

A=1 (lsb), B=2, C=4, D=8, E=16, F=32, G=64, H=128, I=256 (msb)

Add up the numbers and pass hexadecimal to command “AsXXXYYY” (x = left, y = right). 

This example is open to tweaks for performance in whatever platform it is developed, but any command set used must be fully documented.

To achieve the addressable access, perhaps a 16 position hex encoder or dip switches can be used in a manner that the on-board micro controller reads at boot, but then doesn’t bother to check it again until next boot.
The serial inputs can be copied across the board to the opposite side, so that all modules receive the same data at the same time when connected in a string.  If this will be the problem with the SPI bus, then the micro controller can echo any commands it received to the next module.  This may introduce unwanted propagation delay.  Perhaps a trace on the board can be soldered or unsoldered to select a slower, standard clock rate (or baud), or a much higher but still standard clock rate (or baud).

If the performance allows, and if the costs of the final board are tolerable, this spec can be expanded to 4 digits, with corresponding points.  The inputs to all the commands would be doubled.

I hope this spec is straight-forward enough to get some creative juices flowing.   I look forward to seeing what anyone builds from this, and I am releasing this design spec as OPEN HARDWARE, NO TRADEMARK, NO PATENTS.

I own one of these little guys, but it's on the small side, not able to be stacked, doesn't allow colons AND decimal points, just doesn't cut it.  Don't get me wrong, it works great, but... it's limited. 

Thursday, June 23, 2011

Demise of The Multiple Length String of "a" 's

Ok, well I've discovered an important thing about .NET String objects.  They suck, for the following two reasons:

-They are immutable, meaning every alteration to a string you make produces a NEW COPY of the string in memory.  So if you append 10 items to a string in a loop, you will have 10 progressively longer copies of the string in memory! (in that specific case, use a StringBuilder object instead, much more efficient)
-They are by default Unicode, which is a good thing if you're dealing with web-text, or multiple languages.  Not so good with testing crypto code or passing certain types of passwords.  Use SecureString's instead or just deal with raw byte arrays.  For example, if I build a string of single byte 'a's, in memory that becomes a string of DOUBLE byte 'a's in Unicode.  Boom!  Just that fast I've doubled my memory usage for that one string!

These two reasons drove my testing rig for Skein into using 4GB of memory (that's GIGABYTES, with a G) every time it hit the larger strings.  That was the reason I created a "low memory" test that used shorter and fewer strings for doing full-bodied but not over-burdening line-item tests.

So, what have I learned?  Don't use strings!  At least not for this purpose.

Also, I learned that if my documentation says I do something, I BETTER BE FUCKING WELL DOING THAT THING!  :(  I had listed my encryption functions as using a specific type of padding, when in reality I was doing a completely different type of padding!  Not completely incompatible, but now that I've fixed it, this is a breaking change

Unfortunately this also means this will potentially break my GoogleAuthCLONE if the old DLL is replaced with the new DLL, any old accounts might get blown away.  Such is development....

Friday, June 17, 2011

Return of The Multiple Length String of "a" 's Part II

Ok, much improved.  The whole process of tests now only takes 20 minutes, not 60 (all 966 tests), and the throughput is now:

256bit 778MB takes 44-45 seconds
512bit 778MB takes 44-45 seconds
1024bit 778MB takes 51-52 seconds


This is a DRASTIC improvement, but I still feel like I can do better.  Basically what I did was go back to good ol' C++ routines for the cores of the ThreeFish functions, and unroll EVERYTHING!  Only the MIX and INVMIX functions right now are actual functions, and normally where there would be loops, I actually wrote out the individual steps and removed as many array/pointer look-ups as possible.


With a few compiler tweaks, I might be able to squeeze more performance out.  Also, as I've discovered in testing, my memory usage needs to improve, and I need to make sure that my C++ routines zero out memory properly when they are done with their local buffers.  I've already done some of that in this version (which I will push up to CodePlex later today).


NOTE: (landmine) For whatever reason, my C++ routines will NOT use the intrinsic _rotl64 and _rotr64 functions.  The functions don't even seem to work under Visual Studio 2010 SP1 with .NET 4.  I had to write out the rotates as two shift functions:


*Y = (UInt64)(*Y << N) + (UInt64)(*Y >> (64 - N)); //ROTATE LEFT
*Y = (UInt64)(*Y >> N) + (UInt64)(*Y << (64 - N)); //ROTATE RIGHT


Whether or not the intrinsic functions would give me any kind of speed boost I have no idea.  If I "_forceinline" these functions I might even get a tad more speed, but at 20 minutes for a full battery of tests, I'm going to just push up this version for now and call it a small victory.

[UPDATE:  Ok, _forceinline is a BAD idea, it takes 10 times as long to build, and it actually reduces the performance versus not using it, so don't do _forceinline on the mix functions]


I am consistently getting the same hash results for all my tests, and all my code still passes the NIST Known Answer Tests (much faster might I add), so the outputs that I posted previously should still work for any implementation if you are so inclined to use them.

Saturday, June 11, 2011

Return of The Multiple Length String of "a" 's

After some performance tweaking on the C# compiler, and some unrolling of the core ThreeFish functions (meaning, taking the function calls and actually putting them into the main flow of code, and removing all loops and explicitly iterating through the algorithm).  The code files are HUGE now, but this removes most stack pushes/pulls, and removes a lot of array look-ups.  Also, the testing program was still compiling as "Any CPU" which I've rectified to x64.  I plan on rerunning the full battery of tests with these improvements.  Stay tuned...

Saturday, June 4, 2011

Google does Two-Factor Authentication, and so do I

So, Google has rolled out their version of Two Factor Authentication, requiring you to use your phone to generate a time-based One Time Pad (TOTP) code in order to log into your account.  I like it.  It's good they took the initiative even for free e-mail accounts.  I do have several criticisms, mostly with the draft doc of TOTP, but I will post those another time, as they aren't show-stoppers for me.

The idea is: you can't log into your account without an additional pin or code generated from something that isn't on the login page, it has to come from some other device in your possession, which is unique to you.  This follows the mantra "Something you are [user ID], something you know [password or passphrase], and something you have [your phone, smart-card, or other token generating device]."  This makes the account more secure.  Banks use this same approach to keep online accounts secure, World of WarCraft has its own variant, and there are a few others.




Honestly, I wish more providers did this (I'm looking at YOU FaceBook!).

The Google Authenticator app is meant for Android devices, iDevices (iPhone/iPod etc), and Blackberry devices that have cameras, although you can manually enter the info if the device can't read a QR barcode that is generated when you set up Two-Factor Authentication. 

During activation of the Two-Factor process, an 80-bit random number is created at that time and made part of your account.  This is needed to generate the TOTP codes.  It's this 80-bit key that makes your Authenticator unique. 

<side note>
Google also prevents any other device or service from logging into to any Google service!  Now what?

For every device that you want to authorize, you generate a unique password that is completely random, and Base32 encoded so that all you have to enter are lower case letters and numbers.  This becomes your "password".  So your iDevice now has a different password from your Android, from your Blackberry, from your... whatever other thing logs into Google.  Also if that... thing... gets lost, you can revoke the password for JUST THAT ONE THING!  GENIUS!  Now you don't have to change every password you own if one gets compromised!
</side note>

Sometimes, though, you may want to log in to Google and may not have your [insert device here] handy in order to get your TOTP code.  This is one criticism I have, but it's more of an annoyance.

Enter my GoogleAuthCLONE project for Windows!


Now you can securely have your accounts stored in Windows and generate the codes when you need them without having to reach for your [device].  This can also READ barcode image files (like a bmp, jpg, etc, one barcode per file).  That way if you screen cap the setup process with Google, you can come back to this program and just read the barcode to prevent "fat fingering" your information. 

Also, as you can see in the pic, you can generate barcodes that your [device] can read if it has a camera and the Google Authenticator app.  This way if you have all your accounts in this program, and your [device] meets some terrible event (theft, data wipe, bad custom ROM install, etc.), you can re-enter all your accounts without having to reset every single Google account in the process.  In the case of theft, though, reconfiguring your accounts might be a better course of action.  All accounts are stored behind a good password (as enforced by the program) and encrypted on disk using the ThreeFish algorithm which is part of the Skein hash algorithm


Complexity is enforced by requiring a length of at least 8 characters, 1 number, 1 special character, AND upper and lower case letters.

Get it from the CodePlex page, and if you have problems with it, comment there or below this post.  This is released under the Apache 2.0 License which is spelled out on the CodePlex page.  The original Authenticator program developed by the Google dev team was released under the same license. My work was inspired by their program, but it is not a derived work.

[Disclosure:  I wrote the .NET implementation of Skein/ThreeFish that is being used here but I was not one of the original team members that created Skein and ThreeFish.  I figured this was a good real-world example of its use.  Eventually, I might add Skein to the list of available HMAC algorithms used to generate the TOTP's, which would be, unfortunately, incompatible with the Google version.  I'm also using a 3rd party toolkit for the barcodes.]

Cheers!