May 30, 2013

NIST 800-131A Standard Summary

Read through the NIST 800-131A document and have tried to summarise the standard here. I have excluded all time limited options for this and mention here only the standards that are deemed always acceptable.

Encryption

Triple DES Encryption is being deprecated and only 3 key triple DES is now acceptable. SKIPJACK encryption is no longer acceptable. AES Encryption has 3 approved key lengths: 128, 192 and 256.
From the following Rijndael AES differences link it seems that the AES encryption algorithm is a form of the Rijndael algorithm except that it has a fixed block size. Essentially, if you want to use Rijndael as AES you need to make sure that:

  • The block size is set to 128 bits
  • You are not using CFB mode, or if you are, the feedback size is also 128 bits

Digital Signatures

There are three digital signature algorithmns approved: DSA, ECDSA and RSA. It seems that for RSA that this equates to a key size of at least 2048 bits.

Random Number Generators

The following are listed as the standards currently acceptable as specified in the SP 800-90 document: HASH, HMAC, CTR, DUAL_EC.

Digital Signatures

Basically this section says that the key length must be of at least 112 bits.

Hash Functions

SHA1 is no longer acceptable for digital signature generation HOWEVER, for “… hash-only applications (e.g., hashing passwords and using SHA-1 to compute a checksum…”, it is still acceptable (see page 14, end of section 9). SHA-224/256/384/512 are all deemed acceptable for all hashing function applications.

Message Authentication Codes

HMAC based hashing functions are always acceptable when the key size is at least 112 bits

Command Line Parameter Accessors in .NET

How can strings containing white space be passed as command line parameters?
Here is the test console program:
class Program
{     
    static void Main(string[] args)
    {
        Console.WriteLine("Main(string[] args)=" + string.Join(",", args));
        Console.WriteLine("Environment.CommandLine=" + Environment.CommandLine);
        Console.WriteLine("Environment.GetCommandLineArgs()=" + string.Join(",", Environment.GetCommandLineArgs()));

        Console.WriteLine("");
        Console.WriteLine("Press any key to continue ...");
        Console.ReadKey(false);
    }
}
Using the following as command ine arguments:
Test -b:"Dummy User" "whataboutthis?" /x'Does this work' /a:another a"rgument
Produces this (the command line arguments are comma separated):
Main(string[] args)=Test,-b:Dummy User,whataboutthis?,/x'Does,this,work',/a:another,argument
Environment.CommandLine="C:\Users\...\bin\Debug\TestAccountName.vshost.exe" Test -b:"Dummy User" "whataboutthis?" /x 'Does this work' /a:another a"rgument
Environment.GetCommandLineArgs()=C:\Users\...\bin\Debug\TestAccountName.vshost.exe,Test,-b:Dummy User,whataboutthis? ,/x'Does,this,work',/a:another,argument

Looks like quotation characters "" can be used to enclose a part of a command line that contains white space, the quotation characters themselves are removed. Placing matching quotation characters around/within a command line argument ensures that it is interpreted as a single command line argument even if it contains whitespace characters. Quotation characters are stripped from the command line parameters as they are processed so they will not appear in the arguments.

Summary
Main(string[] args)
  • Gives access to ONLY the command line parameters themselves.
  • Executable is NOT included as a command line parameter.
  • Quotation marks can be used to capture a parameter or part of a parameter containing whitespace
Environment.CommandLine
  • Gives access to the raw command line
Environment.GetCommandLineArgs()
  • Gives access to ALL the command line parameters.
  • Executable is first command line parameter.
  • Quotation marks can be used to capture a parameter or part of a parameter containing whitespace