You are here

illumos

Time-based One-time Passwords

Josef Sipek - Sat, 11/10/2018 - 19:59

Recently I ended up playing with  Time-based One-time Passwords as a second factor when authenticating with various services. When I saw an RFC referenced in the references section, I looked at it to get a better idea of how complicated the algorithm really is. It turns out that TOTP is very simple. So simple that I couldn’t help but put together a quick and dirty implementation in Python.

TOTP itself is documented in RFC 6238. It is a rather short RFC, but that’s because all it really says is “use HOTP and feed it these values”.

HOTP is documented in RFC 4226. This RFC is a bit longer since it has to describe how the counter value gets hashed and the resulting digest gets mangled. Reading it, one will learn that the HMAC-SHA1 is the basic building block of HOTP.

HMAC is documented in RFC 2104.

With these three documents (and a working implementation of SHA1), it is possible to implement your own TOTP.

The Key

If you follow those four RFCs, you’ll have a working TOTP. However, that’s not enough to make use of the code. The whole algorithm is predicated on having a pre-shared secret—a key. Typically, the service you are enabling TOTP for will issue you a key and you have to feed it into the algorithm to start generating passwords. Since showing the user the key in binary is not feasible, some sort of encoding is needed.

I couldn’t find any RFC that documents best practices for sharing the key with the user. After a while, I found a Google Authenticator wiki page describing the format of the key URIs used by Google Authenticator.

It turns out that this is a very common format. It uses a base32 encoding with the padding stripped. (Base32 is documented in RFC 4648.)

The “tricky” part is recreating this padding to make the decoder happy. Since base32 works on 40-bit groups (it converts between 5 raw bytes and 8 base-32 chars), we must pad to the nearest 40-bit group.

The Code

I tried to avoid implementing HMAC-SHA1, but I couldn’t find it in any of the modules Python ships with. Since it is a simple enough algorithm, I implemented it as well. Sadly, it nearly doubles the size of the code.

Warning: This is proof-of-concept quality code. Do not use it in production.

import struct import hashlib import base64 import time # The pre-shared secret (base32 encoded): key = "VGMT4NSHA2AWVOR6" def HMAC(k, data, B=64): def H(m): return hashlib.sha1(m).digest() # keys too long get hashed if len(k) > B: k = H(k) # keys too short get padded if len(k) < B: k = k + ("\x00" * (B - len(k))) ikey = "".join([chr(ord(x) ^ 0x36) for x in k]) okey = "".join([chr(ord(x) ^ 0x5c) for x in k]) return H(okey + H(ikey + data)) def hotp(K, C, DIGITS=6): def Truncate(inp): off = ord(inp[19]) & 0xf x = [ord(x) for x in inp[off:(off+4)]] return ((x[0] & 0x7f) << 24) | (x[1] << 16) | (x[2] << 8) | x[3] return Truncate(HMAC(K, struct.pack(">Q", C))) % (10 ** DIGITS) def totp(K, T=time.time(), X=30, T0=0, DIGITS=6): return hotp(K, long(T - T0) / long(X), DIGITS=DIGITS) # pad to the nearest 40-bit group if len(key) % 8 != 0: key=key + ("=" * (8 - (len(key) % 8))) key=base64.b32decode(key.upper()) print time.ctime(), time.time() print "TOTP: %06d" % totp(key)

This code is far from optimal, but I think it nicely demonstrates the simplicity of TOTP.

References

Categories: illumos

Building ripgrep on illumos

Minimal Solaris - Alexander Eremin - Tue, 11/06/2018 - 17:57
Last night I tried to build ripgrep (grep on steroids). Of course I used Nexenta, but everything below will work for any illumos distribution. ripgrep is written in Rust and we can get the latest Rust version with pkgin (many thanks to Jonathan Perkin):


$ pkgin search rust
...
rust-1.30.0 =        Safe, concurrent, practical language
...
$ pkgin install rust
$ export PATH=$PATH:/opt/local/bin

Building ripgrep:


$ git clone https://github.com/BurntSushi/ripgrep
$ cd ripgrep
$ cargo build --release
Updating crates.io index

warning: spurious network error (2 tries remaining): no Content-Type header in response; class=Net (12)
warning: spurious network error (1 tries remaining): no Content-Type header in response; class=Net (12)
error: failed to update registry `https://github.com/rust-lang/crates.io-index

Caused by:
failed to fetch `https://github.com/rust-lang/crates.io-index

Caused by:
no Content-Type header in response; class=Net (12)

Bang! If you have such error:  clone crates.io-index git to the .cargo directory in your $HOME:


$ cd ~/.cargo
$ git clone --bare https://github.com/rust-lang/crates.io-index.git

Then create .cargo/config file:


$ cat .cargo/config
[registry]
index = "file:///home/alhazred/.cargo/crates.io-index.git"

Now build will successful:

$ cargo build --release
...
$ ./target/release/rg --version
ripgrep 0.10.0 (rev fb62266620)
-SIMD -AVX (compiled)
+SIMD -AVX (runtime)

Now you can compare the ripgrep speed and performance with usual grep. See Andrew Gallant's Blog for more information. .
Categories: illumos

New v9os iso and repository archive

Minimal Solaris - Alexander Eremin - Wed, 10/31/2018 - 12:39

Well, two years later, I decided to upgrade v9os. As a result, after the noise of the servers under my ear I have a little bad hearing at the moment :). But iso was rebuilt with spring changes from the illumos (unfortunately the system is panicking after later commits, I hope to solve this out later).
Some things were fixed, some components were updated, pkg and caiman were moved to python 2.7. I’ve a more powerful server now and I hope that further updates will be forthcoming in this winter.
Site design was also a bit updated.
Categories: illumos

My Logbooks

Josef Sipek - Wed, 08/01/2018 - 19:15

Recently a friend asked me about what I use for my pilot logbook. This made me realize that my logging is complicated and that I should probably make a blahg entry about it.

All in all, I have three logbooks to keep track of my flying.

Good ol’ paper logbook

This is the “official” one. In other words, if the FAA wants to see my logbook, that’s what I’ll show them. There’s not much more to say about it.

ForeFlight

This is my casual logbook. A while back I entered everything in, including more accurate counts (full stop vs. touch+go) and better divided up time counts (PIC vs. solo). I use this logbook to answer questions like “How much time do I have?” and “Am I current?”. It is also useful when chatting with people and I want to dig up an entry.

I also use it to keep track of  Hobbs vs.  tach time since I pay based on tach time.

A Repository

This is my custom analysis and archive logbook. In this Mercurial repository, I keep a giant JSON file with every entry with even more detail than what’s in ForeFlight.

Alongside it, I also keep a list of latitude/longitude/altitude information for each airport I’ve been to.

From these two files, I can generate various plots. For example, here is one:

This is a plot of all the airports I’ve ever landed at—color coded based on the year of my first landing there.

This repository also serves as a backup of my paper logbook (in case my physical logbook burns up, gets water damaged, etc.) and an archive of other flying related data. I accomplish this by keeping scans of the paper logbook, copies of any GPS tracklogs I’ve recorded, and so on in a couple of subdirectories.

Post-flight

At the end of each flight, I add an entry to my ForeFlight logbook. Usually, I have ForeFlight recording a tracklog, so a large part of the entry is auto-generated. The bits of info that I add manually are:

  • tach time (useful for billing)
  • time out/off/on/in (I’m trying to figure out how much time I “waste” on the ground to improve my planning accuracy)
  • landing counts
  • any remarks I wouldn’t remember later

Then, when I’m home and have time (this can be later that day, or 3 days later), I pull up the ForeFlight entry, improve/edit the remarks, double check that all the counts make sense (if needed I pull up the tracklog to recount the number of landings, etc.), and then write an entry into my paper logbook.

If I filled up a page of the paper logbook, I scan the two pages and drop them into the repository.

Depending on how I feel, I may update the repository logbook JSON file then and there or at some point later (in the past I’ve even waited for a month due to laziness). Usually, visiting a new airport is motivating enough.

Categories: illumos
Subscribe to OpenIndiana Ninja aggregator - illumos