Showing posts with label How-to. Show all posts
Showing posts with label How-to. Show all posts

Tuesday, January 28, 2014

Keys, Locks, and Public Key Cryptography

One of the things that I find dismaying is the lack of general understanding of public key cryptography.  This is an attempt to rectify some of that in simple terms, without math or talk of elliptic curves or very large prime numbers or random seeds, presented as an easy-to-comprehend familiar analog.

Assume first an unbreakable lock.  Yeah, I know, I just lost you.  In the physical world, there’s no such thing.  Every lock can be picked, or if not picked, then opened with bolt-cutters or worse.  Let’s ignore those things for the time being, just for the sake of getting our heads wrapped around how public key cryptography works.  I can explain the unbreakable part later.

For our unbreakable lock, we have a key.  This is the only key we have, and no one else has a copy of this key.  In order to ensure that no one else can open our lock, we must keep this key secret.  We must never let go of it, or share it, or hand it to someone else who can easily make a copy of it.  We can, however, back it up and make copies for our own use, as long as those copies are similarly never shared.  In order for us to trust the security of the lock, the security of its associated key is paramount.

Furthermore, let’s up the ante a little bit and assume that we’re in a bizarro fantasy world where you’re surrounded by people with photographic memories who really are out to get you.  You’re not just paranoid.  If you so much as use your key in plain sight, any one of them can, from memory, reproduce your key and open your lock, taking anything you wished to secure, including your own identity (in effect, they can pass themselves off as you and act on your behalf without your knowledge).

Your lock is then equivalent to a public key in public key cryptography.  You can show it to anyone.  You can pass it around, secure in the knowledge that it is unbreakable.  To protect something you need only secure it with that lock.

Let’s say you hand that open lock to someone else, so that they can send you something securely.  All they need to do is put what they’re sending to you in some container and close the lock.  They can’t reopen it, because they don’t have the key, only you do.  They know at the moment they close the lock that only you (or rather, only the holder of the key associated with that lock, whether that is you or not) will ever be able open the lock and receive what they sent.

This is equivalent to asymmetric encryption.  The public part of the public/private key pair is used to encrypt something so that only the holder of the private key (the key that fits the lock) is able to decrypt it, even though the entity performing the encryption doesn’t have or need the private part.

There’s a healthy amount of skepticism in this bizarro fantasy world, though.  Many of its inhabitants don’t believe that lock is yours, and you are asked to prove ownership (incidentally, this is how you prove you own the Bitcoin you spend).  You can’t just wave your key in front of anyone, though, because as soon as you do all those photographic memories will go to work and everyone will be able to produce the key that opens that particular lock.  Instead, you have to prove that you own the lock without ever showing the key.

Easy enough…  you turn around and, making sure no one is looking over your shoulder, you open the lock.  Hide your key once more, and then display the opened lock for everyone to see.

This is how signatures work.  You have proven ownership of the private key associated with the public key, without ever showing the private key itself.

Now, for the unbreakable part.  The reason our lock is unbreakable is because in public key cryptography we’re talking about a mathematical relationship between the public and private keys, through a cryptographic formula that is available for all to see and review.  This isn’t a simple mathematical relationship, but it is one that has been reviewed and examined by some of the very best mathematicians worldwide, all of whom have varying interests in securing this relationship or breaking it.  Those with a vested interest in breaking the relationship or finding some algorithmic flaw that would allow the private key to be determined or reverse-engineered or brute-forced, given the public key, have come up with nothing (so far).  Those with a vested interest in securing the relationship and coming up with something even better have been unable to (again, so far), and have posited that it would take more energy than what is available in the universe to crack this code.  There is plenty of incentive to crack it, the person or people that can would then be able to single-handedly control and manipulate the world’s wealth and information.

Think about this, though…  Let’s assume that some moustache-twirling villainous type has found a flaw in the algorithm, and with dreams of unlimited wealth and power has decided to keep that information to him- or her self.  There are many others worldwide, who don’t share that villain’s desire or ideology, and who would be looking at those same algorithms with the knowledge to understand them and their implications, bent on preventing exactly that situation from occurring…outing the villain and at least rendering his plans ineffective by publishing information about the flaw and fixing it, if possible.  This has happened many times already, through RC2, MD5, DES, Triple-DES, SHA1, etc., just to name a few algorithms whose weaknesses have been found.

Even when the reward for cracking these algorithms is nearly unlimited wealth, power and control, on an individual level it’s far easier to get someone to show their private key through malware, key-loggers, screen captures, human error, misplaced trust, and the like; or simply beat it out of them.  All those photographic memories out there can then take a picture of it and steal your wealth, your identity, your life.  We, as people, are the weakest link.

del.icio.us Tags: ,,,

Wednesday, May 15, 2013

Getting Hg-Git working on Windows 7 (64-bit) with TortoiseHg

Just posting in case I need to remember how to do this again.

I am using TortoiseHg at version 2.8 (Hg version 2.6).

Open a Windows Command Prompt as an Administrator, then:

hg clone https://bitbucket.org/durin42/hg-git/Path_To_TortoiseHg_Installation\hg-git”

The location of hg-git I got from the Mercurial Wiki, and on my system the Path_To_TortoiseHg_Installation is C:\Program Files\TortoiseHg.

For the next step, enabling the extension, the advice at ffuts.org / blog came in handy.  The first comment at the bottom did the trick.  Instead of updating your Mercurial.ini file with this line:

[extensions]
hggit = C:\Program Files\TortoiseHg\hg-git

When I tried this, I kept getting a “failed to import module” error when verifying the extension was enabled using the hg help extensions command.  The solution was in the first comment… instead of the above, point to the hggit directory inside the hg-git directory/repository, as follows:

[extensions]
hggit = C:\Program Files\TortoiseHg\hg-git\hggit

Once I made that change, everything started working and the extension was properly enabled.

Technorati Tags: ,,,,,,,,
Windows Live Tags: Windows,TortoiseHg,version,Mercurial,extension,advice,solution,repository,hggit
WordPress Tags: Windows,TortoiseHg,version,Mercurial,extension,advice,solution,repository,hggit

Wednesday, December 22, 2010

Enabling Code Coverage in VS2010 without MSTest

Just so I don’t forget how to do it…

The command-line sequence is as follows:

  1. Instrument the assemblies that you want to provide code coverage information using VSInstr.exe (32-bit version at %VSInstallDir%\Team Tools\Performance Tools\VSInstr.exe, or 64-bit version at %VSInstallDir%\Team Tools\Performance Tools\x64\VSInstr.exe) with the /COVERAGE switch.
    This will write two new files for the instrumented assembly (if PDB’s are available) named after the instrumented assembly and its PDB file with the pdb.instr extension.  The original assembly is renamed to AssemblyName.Extension.orig and the original PDB is left unchanged.

    A side effect of this instrumentation is that your assembly will now have a dependency on VSCoverX.dll (where X is 80, 90, or 100, depending on the Visual Studio version).  This dependency is what sends your coverage information to the performance profiler.
  2. Start the performance profiler using VSPerfCmd.exe (32-bit version at %VSInstallDir%\Team Tools\Performance Tools\VSPerfCmd.exe, or 64-bit version at %VSInstallDir%\Team Tools\Performance Tools\x64\VSPerfCmd.exe) so that it can begin collecting code coverage information.  The command-line is /START:COVERAGE /WAITSTART /USER:”%USERDOMAIN%\%USERNAME%” /TARGETCLR:vn.n.nnnn /OUTPUT:”pathToCodeCoverageResultFile.
  3. Perform your tests (using the same bit-ness that you’re profiling, 32-bit or 64-bit), either manually or using whatever automated testing framework you wish.
  4. Stop the performance profiler using VSPerfCmd.exe with the /SHUTDOWN switch.
  5. As a last step, rename your *.orig assemblies back to their original names, either deleting or renaming the instrumented versions.

You should now be able to open the code coverage file at pathToCodeCoverageResult in Visual Studio to examine the code coverage information, or create an XML report using VSPerfReport.exe.

Technorati Tags: ,,

Saturday, November 13, 2010

Accessing Subversion over SSL

In a previous post, I was trying to get communication with my Subversion repository secured (somehow...either over SSL or using SVN+SSH).  Well, I finally did that...nearly a year ago...and forgot how.

Now, I have to do it again.  Lesson learned: If you ever have to research how to do something, blog about it so that others can benefit and so you can repeat it.

Instead of using the binaries available on Tigris, this time I'm using the CollabNet package (version 1.4.6).  They distribute a very nice and convenient installer that also includes and configures Apache for you (I de-selected the SVNSERVE option during installation because I don't intend to serve the repository through that channel).

This is a test installation that I'm preparing for a demo (still trying to convince my company to dump VSS, and now TFS, in favor of a system that works for all of the technologies, languages, and IDE's that we use).  I instructed the installer to put Apache on "localhost" at port 8080; after all, I'm a Windows developer who works with Web applications, so I need to keep IIS available on port 80.

When the installer completes, open the Services console and start the Apache daemon.  Browse to http://localhost:8080 as a sanity test just to make sure that Apache is, in fact, running and configured correctly (at this stage, at least - we still need to configure a repository and tell Apache where it is).

Next, create a test repository with the following command (the repository name "test1" isn't important, it will be deleted later once the setup is verified; and the repository path C:\Repositories is the repository root I gave to the CollabNet installer).
svnadmin create C:\Repositories\test1

Now I should be able to access the repository at http://localhost:8080/svn/test1, and "WOO-HOO!!!", I can.  The browser shows me "Revision 0: /", just as it should.

The information found at http://www.neilstuff.com/apache/apache2-ssl-windows.htm (Create Self-Signed Certificate and Enable SSL in Apache 2.0.X) helped me get the SSL working (later I found this as well).  I found that I didn't need to install OpenSSL since the CollabNet distribution came with it (it is in the httpd subdirectory of the installation directory), but I did need an OpenSSL.cnf configuration file (here and here).  I also didn't need to install Apache since that was done by the CollabNet installation.

So now that I am able to access the repository through either http://localhost:8080/svn/test1 or https://localhost/svn/test1, I want to force access through SSL and disallow any access on port 8080.  There's no use serving an encrypted version if the same content will also be served in plaintext.

Edit the httpd/conf/httpd.conf file (relative to the CollabNet installation directory) to contain the following lines:
<Location />
  SSLRequireSSL
</Location>

Now http://localhost:8080 returns Forbidden, but https://localhost gives the Apache installation page.  Great, so everything is encrypted over the wire, but we're still allowing everyone (anonymous) access.  Moving along...

This page gives instructions on setting up the Apache server to use SSPI (Windows) or Basic (password file) authentication, or a combination of both of them working together (e.g., to support internal development staff as well as external contributors for whom you might not want to create Windows accounts).  Note that there is an error in the "Multiple Authentication Sources" section.  The advice given says that both AuthAuthoritative and SSPIAuthoritative should be Off, although the example shown states "SSPIAuthoritative On".  This should, in fact, be "SSPIAuthoritative Off".