new opmsg trickery

Theres two news to the opmsg:

First: I added brainkey personas, a similar thing to
BTC brainwallets. If you use these, you do not need
to send your pubkeys around anymore. It's an experimental
feature. The key is derived via PBKDF2 function with HMAC
with a lot of iterations and salt, so to prevent large
scale (or huge-scale) dictionary attacks. True, I could have used
memory-hard functions for that but a) Argon2 or friends
are not yet part of OpenSSL and b) if I understand correctly,
you can still use it on massive paralleled ASCICs if you
accept additional computation cost for re-creating matrices
on the fly. So a+b let me chose PBKDF2 over Argon2.
Brainkey personas are also deniable personas, which underlines
the concept of linked/deniable personas.

Second: you can im/export your persona keys as QR codes
now, to make it more convenient to exchange pubkeys
due to ubiquitous (what a word!) dumb phones that can send around screenshots.
Its inside its own git repo that you can find here.
Most of the effort was finding and integrating small
footprint QR encode/decoding libraries.

DoH trickery

Made a posting about DoH integration and latency measurement.

Bitcoin Census trickery

I wish I could have posted this on my gh-pages blog site,
but apparently I do not have sufficient skills to embed
script tags into their markdown rendering.
So, in order to show some fancy maps I have to use this blog again.
Stay tuned, and regularily check both of my blogs for updates;
because gh-pages is better for embedded code snippets while
this seems better for embedding HTML.

I published my BTC mapping engine hoschi.

It will crawl through the BTC p2p network, fetching all
addresses it can. The obtained raw data may be used for
further analysis like mapping it to geo locations or building
graphs of the connected nodes in order to spot unusual network
setups or to locate mining farms.

For instance, scanning through the BTC testnet, yields this map:



The cool thing is that github will automatically render
geojson files and also cluster the points for me.
The map for the BTC main network is too large to be rendered
on gh.
Nevertheless, I was actually interested in big nodes:


which are connected to more than 1000 other BTC nodes in
the network. In my census, I found ~272k mainnet BTC nodes,
~1k of which are big-nodes. These could either be just
long running nodes so that a lot of other nodes have had
the chance to connect to it, or nodes located nearby
mining farms in order to distribute mined blocks quickly
across the p2p network. However, it may also be possible
that mining farms use their own BTC software not answering
to getaddr requests.
Some of the big nodes seem to be special indeed, as whois lookups showed weird registrar naming entries such as Data Bureau.

Other interesting occurences were nodes that tried to
join testnet and mainnet, heavily multihomed nodes, or
nodes distributing multicast or otherwise special IP addresses. According to my census, IPv6 is already much more widespread than
one would think. 22% of the BTC nodes were IPv6.

QDNS rebinding trickery

I am trying to do some posts via my gh pages.
I will cross-link my posts on this blog in future,
so you don't need to update your bookmarks.

Both blogs will stay free of advertisement or
influencer shit in 2018 as before, except the usual C++11
(now C++17) attitude towards Rust coders. :p

harddns usability

I updated harddns to make use of standard TLS certificate
checking. Usage of pinned certs is now optional. If they
exist inside /etc/harddns/pinned, they have to match
in order for the resovle to succeed. If there don't exist
any pinned certs, the common X509 chain verification
is applied.
This should make harddns much more usable, as
there are plenty of X509's from google endpoints
which may appear if the resolver web API is contacted.

OpenSSH call-graph trickery

There was a discussion on twitter some weeks ago
about current call graphs of larger software projects.
I noticed that my instrumentation package from 2005, 2007
and 2010 failed to work with current openssh versions.
I made a small writeup why and also publish call
graphs for a sshd session of OpenSSH 7.4p1 server.

opmsg saving you from OpenSSH 0days

As I am interested in Crypto and its implementation,
being it my own projects or competing ones, I often take a deep
look into the OpenSSL and LibreSSL projects to estimate
what can potentially go wrong and where special care
must be taken while swimming with sharks.

I have already written and complained here in past about the
shiny OpenSSL 1.1 API changes. I think its safe to say that opmsg
and drops have been the first larger projects being neatly
ported to the 1.1 API, while still being aligned to older
OpenSSL installations and LibreSSL, cross platform of course.
How many projects do you know - and heavily use libcryto
or libssl - can do that?

OpenSSH for example can't. OpenSSH-portable on Linux suffered
similar hard times due to the new 1.1 API. No pain, no gain.
While OpenSSH upstream declined to make
OpenSSH-portable ready for the 1.1 API (at least yet),
there was still demand for it, since lots of newer distros
were simply not able to build their openssh packages with their
own shipped libcrypto packages. Thats why the Fedora project
adopted patches (this one is already fixed after my report).
However they introduced some double-free conditions by
means of RSA_set0_key() and similar functions. You can read
my report and see in the patch how the order of function
calls has been changed to fix the double-frees.

You can thank me later that I saved your Fedora boxes
from an ssh 0day.

dropsview ncurses trickery

If you were ever curious about what a GUI frontend designed
by me would look like, here you go.

Hand crafted without any GUI builder but with much love
and ergonomics and minimal dependencies. It allows you
to manage your personas and op messages easily and to
send instant messages to your peers without the command
line hassle. And most importantly: without anyone watching
and processing even the meta data.

If you have a static IPv4 (or v6), consider running a
drops node. Its small footprint and you don't necessarily
need to participate in messaging. You can just run it in 
background as a message hub.

KDE trickery

I published my writeup about CVE-2017-8422 and CVE-2017-8849,
including the PoC for smb4k.

Note, that this helper is most likely not installed by
default on KDE systems. However, other helpers which are
installed by default are affected too, such as kcm_systemd which
could be leveraged to overwrite arbitrary files.

The most complicated thing about the PoC was to setup
a proper Qt/KDE 4/5 build environment; so I decided to
just use dbus-send with a binary blob instead, rather
than creating my own QVariantMap. 

OpenSSL constant hell

Last week, someone opened a bug for opmsg, saying it
wont compile with recent versions of gcc.
I am happy that I've been noticed about it, since it shows
people are using opmsg. The "bug" however is not within
opmsg, its about the way OpenSSL changes their function
definitions (breaking the API!) in between minor versions
of OpenSSL.

What exactly happened?

In above screendump you see two functions constp() and
constpp(). They will serve as an easy, down-stripped demo.

While with constp() the const char * declaration
by the programmer is more like a promise to the caller
that the data at which ptr points to, will not be written to,
this is different when the type changes to a double
pointer. You can pass char * variables to constp() without
any problem, because constp() just promises you to not modify
the pointee data. It would be allowed to do so for char *
variables, but it confines itself to this promise, which
is good practise to show the user of the API "Hey, we
wont modify your data as you pass it to us." 
There are no problems if you would change a foo(char *) 
declaration to a foo(const char *) because the later declaration 
just promises more to you, and you lose nothing by foo()
making additional promises to you.
The takeaway is: you can pass a char * variable to a
function that wants a const char *. Both foo()
functions are accepting the same type. You can see
this by the compiler accepting the call to constp()
for a char * variable.

Thats different when a double pointer is involved as
with the constpp() function. Here you have to pass
a const char ** because otherwise the pointer value itself could
be assigned a char * by which const objects could be modified.
This would violate the const correctness of the program
and obsolete the const keyword. Thats why the foo(char **)
and foo(const char **) arguments are really different types.
In other words, you cant just add a const keyword to
double pointer function arguments as you could do it
with single pointers. You end up having entirely different
function signatures.

Now, guess what OpenSSL has made with the

DH_get0_key(const DH *dh, BIGNUM **pub_key, BIGNUM **priv_key);

and

RSA_get0_key(const RSA *r, BIGNUM **n, BIGNUM **e, BIGNUM **d);

functions? They "just" added a const to the BIGNUM
double pointers somewhere after the 1.1.0 version
already introduced a new API. Thats a warning for
C11 programs (one that you should not ignore) but even
worse, as you can see in above demo, its an error for
C++11 programs.

So, I had to add a wrapper function for the functions
in question which call the right functions, depending
on the OpenSSL version.


If you want to read more about the double pointer
const topic, its described here.