This is my discussion blog. The way it works is that when any pages in this wiki have a discussion page created for them, the discussion pages show up below. Also, any comments on my blog posts also show up here.

Nice Work

Hi Joey,

I read your blog for a few month now and it is great to see what you accomplished with your cabin. Keep expanding and blogging about it.

Greetings from Germany, Andreas

Comment by A.Steinel
discussion

re. protobufs - i think that would be an improvement: it seems like a good idea to decouple language-specific data structures from the protocol, if only to make debugging easier, but it seems like a good idea also to allow for better extensibility (e.g. writing different client/servers implementations)...

An interesting approach I have found is the language-neutral kaitai.io specification system. it's a YAML-like metadata description language that translates into multiple languages like Java, Python, PHP, Ruby, C++ but, unfortunately, not Haskell just yet. I find it an interesting alternative to protobufs because you are not bound by a certain data format - you can just write your own binary language (or port existing ones) by specifying its metadata clearly... --?anarcat

discussion

Not sure if you're aware of the Linux network emulation framework, but if not: https://wiki.linuxfoundation.org/networking/netem — that will let you simulate all kinds of terrible networks.

discussion

I'm not a user of it yet, but by chance I noticed your activity mixed into the git-ssb-web feed the other day, including commits on keysafe, which I had never heard of before.

Then today, looking over the project's github repos, I noticed an attempt at a Shamir's Secret Sharing backup system. It seems to work by just sending the shares to your choice of friends. As I understand it, unlike email, it not possible for them to delete the message.

Although compared to keysafe's independent servers, it seems much more possible for two people you know to both have been compromised (or just to collude, but presumably they'd have a good reason for doing so).

- NickNovitski

wifi !

As anarcat points out you can probably cover that distance with wifi. In Catalonia we have a huge commons network (guifi.net) of more than 32.000 nodes with 16+ mile links and several optical fiber towns as well.

Don't you have any wifi/wimax (LMDS) provider on your zone? The price and power consumption will be lower and the bandwidth and latency much better.

Comment by i
wifi?

"a few miles" away seems like something that could be bridged with a high speed WiFi link. at the montreal mesh, we have successfully built a 3km link using 5GHz frequencies. this was done with two Ubiquity Powerbeam M5-400-ISO devices. it's obviously line of sight and unidirectional links, but it works well, from what i've heard.

some basic docs are here and here, i can dig out more if you're interested...

Comment by anarcat
comment 2

I don't know of any good way to do it. Ideally, git would have a way to signal a redirect from one mirror of a repository to another one, and could learn the new url.

I have created empty repos on github with the same names as the deleted ones, and in their README put the url to use. Not an ideal solution as it could confuse people and scripts.

In my case, all the projects were not hosted on github, only mirrored there (except for github-backup). So, googling will find their websites and git repos still.

Comment by joey
removing github repos

Hello,

do you know of any way to leave a pointer on github to the new location?
You are famous :-) so you can just put the links in your blog, but if anyone at all cares about my hacks they won't find it unless I tell them there.
But I couldn't find any way - the "bio" is only twitter-size, and there's no other text field I see that's independent of the repos themselves so it would survive their removal.

Thanks.

Comment by behemothchess
HOWTO firmware collision

Of course, what we really need to worry about is not ASCII art, but binary firmware published by git repository. The linux firmware repository, for example.

Here's how to use the SHA1 collision generation attack to modify a firmware file so there are two versions, one of which runs a malicious exploit and the other which does not. The good version can be distributed, and then replaced by the bad version without the replacement being noticed.

  1. Identify the first instruction run by the firmware at boot. Replace with a jump to 129 bytes after the current end of the firmware.

  2. Use the resulting file as the input the the collision generation attack. (If you wan to target this being stored in a git repository, include a git blob header in the data used to generate the collision.) Now you have two 128 byte chunks which when appended to the file in #1, result in two different, SHA1-colliding files.

  3. At the end of each of the two different files, append the same payload. Since the SHA1 hash function is in the same state at the end of each file in #2, appending identical data to each file yields new files that also collide.

The payload examines the memory in the 128 byte colliding area. If it sees the "good" version, it runs the instruction that was originally replaced with the jump, and jumps back to the second original instruction. If it sees the "bad" version, it runs the remainder of the payload, the exploit.

Obviously there is some trickiness to do with relative addresses and returning registers to the original state when jumping back in the "good" version etc. But this should be very doable for any assembly programmer; it should even be possible to completely automate it.

Comment by joey
Re: Common prefix and suffix

@tanmail sorry, you're entirely wrong.

Once the common prefix and the collision data have been fed into SHA1, both the "good" and "bad" SHA1 calculations have the same internal state. So, any common suffix after that will result in the same SHA1.

If you don't believe me (or the paper that says that same thing in a more mathy way), you can easily verify this with the published SHA1 collision files.

Comment by joey
Re: comment 5

@nomeata, I'm sure it would be harder to limit the collision to printable characters. How hard I don't know (even after reading the paper).

AIUI, they're using a SAT solver; it might be that it could be modified to remove solutions that use unprintable characters, and it might only have to work a "little" harder.

Or it might take the obvious worst case of needing to run the collision generator repeatedly until it finally finds a suitable collision.

Comment by joey
comment 5
Getting a collision that has a certain form (valid ASCII, no \, for example) is, AFAIK, much harder than a general collision. I wanted to use a MD5 collision to break Haskell’s type safety via Typeable, but failed because of that. Also, would the prefix have to have a certain length?
Comment by nomeata
Common prefix and suffix

Hello,

I do not think your idea is applicable as it is, because what you are using here is two files, with a variable part (the first line of ASCII art), a common prefix (everything before that line), but also a common suffix (everything after that line). If your variable part is designed to that the concatenation of the common prefix and that part gives the same hash with the two versions, that will not be the case for the concatenation of the common prefix, that part and the common suffix. Therefore, the two versions of the complete files with not have the same hash, only their first three lines do, but nobody verifies files integrity by taking the hash of its first three lines…

It may be possible to mount such an attack, but I think it would be quite more complicated…

Comment by tanguy+joeyh.name
comment 3

As far as I know, you do not need a 192 byte prefix, it should be able to be any length you choose. "192" does not appear in the paper. The 192 bytes that appear before the good/bad chunk in the SHA1 colliding pdfs consists of the regular header of a pdf document. A prefix consisting of some C code would work just as well.

To make files that result in colliding git blobs, one only has to add at the front of the above prefix eg "blob 5000\0". The SHA1 collision generation attack then proceeds as normal. Once you have its results, you just strip that blob prefix from them, pad them up to the selected size of 5000 (eg by adding more common C code at the end), to get files that can be checked into git and will yeild colliding blobs. The need for the file size to remain fixed is the only real complication here.

Comment by joey
Prefix

Hello Joey,

neat post. As far as I can tell, you also need to get the SHA calculation in the proper state, though For example, just the two different string parts will not compare equal, you need the 192 bytes of prefix, too. Also, you cannot prefix the blobs with a common prefix and get the same result. So I would think that there is still significant "cryptographic" effort needed to apply this to git.

Best regards

Thomas

Comment by tv.joeyh.name
comment 1
misterbonnie             7*yLN#!NOK
misterbonnie             mFMC^&*FMM'
misterbonnie             | *'     _\
misterbonnie             |  =|MM|\MM  but i like
misterbonnie              \V    c_)|   putting ascii art
misterbonnie               |\   __ /   in my code :(
misterbonnie               |    __/
misterbonnie               \     |
misterbonnie                \ 
Comment by joey
comment 3

@Joachim I was aware of haskell-tor when I built this. I chose not to use it for a bunch of reasons including, it does not suppport tor hidden services, it's not been peer reviewed, tor has a much more active development community that's working on a next generation of hidden services amoung other things.

Comment by joey