I supposed to write this weeks ago though, anyway. Here is vyw, it’s a client side file browser. Vyw actually is a continuation of this post. At least the idea was already popped up around that time, but I only had the chance to tinker around it few weeks ago.
So the idea was to have this fully functional file browser, or specifically, images browser with thumbnail view, which usually achieved with server-side app, backed only with nginx.
You wont need this if you already using services like imgur, or dropbox. But since I’m not really using both services. And I already store (almost) all my picture files on my private server anyway, so hey, why not!
Vyw actually is supposed to be made to speed up my blogging activity, especially when it’s involving posting some random image, you know, like this
Ummm, suddenly lose the mood to write about the technicals stuff, so here is the list of stuff I need to fix / not there yet:
Fix nginx config example in contrib folder
Add example config for setup with 3rd party image resizer service
Add example config for setup with nginx image filter module
Navigation bar (not sure if useful)
The only concern left for me is, separation between public and private contents. While all the files is considered public, I can only allow some people to browse them. And this is impossible to do with nginx, short of rearranging the directory structure and create root for each contents (publicly browsable v.s. browsable only with secure link). I don’t know.
But anyway, I kind of in the mood for writing about things I did last week.
So it just came to me that it’s probably about time to rotate my SSH keys, random public keys started to piled up at my GitHub and Bitbucket account and I decided to remove them all and start with the new one. Then I went to also removing old keys from some of my servers. Few days later apparently my DNS proxy refused to connect since I forgot to change its key. That when I realized that apparently Go implementation of SSH currently doesn’t have support for reading the new Ed25519 key.
After some digging, I found out that openssh also using new format for this key. Its ASCII layout is based on PEM format, but the base64 blob no longer using ASN.1’s DER encoding. The new Key protocol using simple length prefixed format and described at PROTOCOL.key file located in the root of openssh source folder.
The current Go’s SSH implementation actually supports Elliptic Curve crypto but only specific to ECDSA based keys. Adam Langley already wrote Ed25519 primitives for Go but seems not bothered to integrate it to SSH.
I started with looking at internal structure of the private key, using ruby oneliner:
It’s easy to read, the first 15 bytes is a C string (null-terminated byte array) purposed as file identifier (AUTH_MAGIC), then the next 4 bytes is a big-endian 32-bit integer representing the length of cipher name used to encrypt this key, it’s a none since I’m not using any encryption. The next 4 bytes is the length for key derivation function name, it’s also a none here. The default value for cipher name is aes256-cbc and for the kdfname it’s bcrypt if there’s encryption involved. This 4 bytes length and data pattern is repeated for the whole message. For example the next 4 bytes is the length of options for the key derivation function, the structure is nested, another length prefixed byte array. The fields is salt and rounds count. If encryption is used the salt length is 16 bytes by default and the round is 16. Above we have none of these so the kdf option length will be 0 (4-bytes zero). Next 4 bytes is the number of the key, It will be always 1. But I guess in the future there’s a plan for supporting multiple keys in a single file or something.
Next 4 bytes is the length of our public key structure. 0x33, 51 bytes, but wait it looks a bit strange, let’s compare it with the public key file first:
Okay this is weird 1 nibble is actually missing from the private key representation above specifically in this line 00000030: 7368 2d65 4323 5353 1390 0000 0200 1238 sh-eC#SS.......8. This is really weird since things will totally broken if it’s really the case with openssh. But fortunately it’s not.
Now i just can’t believe in ruby, at least not to its builtin base64 decoding system. Not sure what happened here and when I test it with non binary base64 strings, it actually decode as expected. Anyway, let’s use saner implementation for now:
That’s better. Now let’s continue with our public key structure, there’s a key type ssh-ed25519 and the public key itself. One of the interesting properties of Ed25519 is its key is simply byte array, it’s not a representation of big prime whatsoever. And I noticed that in a single private key above, the public key is actually stored 3 times. In the private key structure there’s a 2 check ints, a 32-bit integer repeated twice. a public key, and the 64 bytes private key, which actually contained public key as its last 32 bytes.
My implementation to decode and read the key is at GitHub. It’s on public domain, and doesn’t support encrypted private key for now. I also haven’t bothered to add tests. Probably later.