Friday, May 6, 2016

opmsg chacha20-poly1305 trickery...

... and a lot of hassle checking out the new OpenSSL 1.1.0 API 

Support for chacha20-poly1305 stream cipher with AAD (poly1305)
thats causing erection to so many cryptographers recently
has been added to opmsg.Its only available to > OpenSSL 1.1.0,
so be sure your peer is also using it when you send
op messages like that.

The more tricky part is the new API that comes with
OpenSSL 1.1.0. Despite fixing a lot of issues in their
TLS implementation, the OpenSSL project still seems to
have enough time breaking their own API by:

1. Making structures opaquewhich means you cant longer
   declare EVP_MD_CTX and other types on the stack. So you are
   forced to use EVP_MD_CTX_create()/EVP_MD_CTX_destroy()
   since the type is forward declared now.

2. At the same time, removing the EVP_MD_CTX_destroy()
   function and adding _new()/_free() functions which do
   the same (!).

3. Declaring macros for EVP_MD_CTX_destroy(xxx) (with braces!)
   so that unique_ptr<> deleters eventually also break.
   1-3. alltogether make sure that no matter how you declared
   your variables, the OpenSSL team decided to throw your
   code to trash.

4. As if this isnt enough, EVP_PKEY_type() has been removed,
   even if its usage has been encouraged by various code
   examples in their manpage.

So OpenSSL decided to open a wiki to track the amount of
open source projects they offended by causing quite good
amount of time thats needed to rework the code.
Theres definitely more to be added there in future.

Nevertheless, opmsg is now OpenSSL 1.1.0 ready and still
works fine with lower versions and LibreSSL.

If its possible for you, you should consider switching to
LibreSSL , as everything is more smooth and straight there.
(But I think LibreSSL project should also offer https:// :)

Thursday, April 28, 2016

opmux := (opmsg|gpg) trickery

Whenever you are tempted to type gpg, you should type
opmux since now().
I recently pushed opmux to the git that allows for easy
use of opmsg and gpg in parallel and to seamless integrate
into your MUA by just pointing the gpg-path to the opmux
binary and adding keyid-format long to your gpg config

Since then, opmux will transparently choose the right
binary for decryption, based on message markers used
by either world. On encryption, in whatever world the
key-id is found, it is passed along to it. If no key-id
is found, both pubkey databases are shown so the user
can select one. Be sure to nevertheless have a look
at the opmux part of the file.

Here are some Enigmail screenshots on sending, decryption
and debug console:

Tuesday, March 8, 2016

ZeroCopy sshttp

This time we trick sshttp into utilizing the
splice(2) syscall to achieve zero-copy of the
network data thats muxed across the sockets.

If you want to give it a try, pull sshttp git 
and checkout the splice branch. Everything else
goes the same.

Using splice() instead of read()/write() inside
the core loop has a performance benefit. In the ideal
case (SPLICE_F_MOVE is honored by kernel), instead
of copying megabytes of data, the PTE's inside the kernel
are just set up to point to the internal pipe buffers.

sshttp may still run at 100% CPU (which is perfectly OK
when downloading huge files) but has more throughput at the
same time. Below is a screenshot of a parallel download
of a 5MB file (per 30 http clients) and a strace showing
the splicing thats happening inside, which is basically
a poll/splice loop.

Friday, January 29, 2016

packet trickery

Refactored my libusipp packet framework's receiving
functions (sending will be optimized later) to:

o Reflect new libpcap API, in particular things
  changed about selectable fd's and immediate mode.
  It works best if you just pull & build libpcap,
  as most distros and OSX may have outdated libpcaps
  installed (you will notice by missing symbols)

o refactoring sniffpack() functions to not longer rely
  on dynamically allocated memory but using fix buffers
  and offsets to handle incoming packets (much) faster.
  The new[]/delete[] memory allocation was a hangover from
  the 90's when I initially didn't build it with QUANTUM in mind.

o Implementing RX classes for string and fd receiving (tuntap

o Adding support to allow sniffing from file:// devices
  to debug via wireshark packet captures later on.

o support QoS data on wifi links

Some things in libpcap still suck, for instance the timeout
function doesn't accept stuct timeval and cannot be called once
a capture handle has been activated. This forces me to
keep my own timeout functionality which is sub-optimal.

As usual, be warned about API changes in libusi++: I add/change
whatever I feel is needed there. API stability is not my
main goal.

Happy QUANTUM your IoT! :p

Friday, December 11, 2015

Ads trickery

For whatever reason the cluster-maps widget began to
distribute ads via their feed.

As I have strong no-ads policy here, I was forced to delete
it. Thats a bit unfortunate as I really liked it and
it was a cool widget to see where visitors came from.
Wrong move!

If anyone knows how I could disable the ads w/o
disabling the entire cluster-maps widget or knows about
an ad-free alternative to it, please leave me a comment.

Thursday, December 10, 2015

deniability trickery

Pushed some new changes to opmsg git:

o deniable personas: opmsg now supports OTR-style messages
  that are signed and integrity protected but still deniable
  so your peer cannot proof you wrote a certain message. Nothing
  in the message format changes and you can use deniable messages
  as any other ones. Please check the README about this topic.

o Its now possible to specify more than one -E target persona to
  support Cc/Bcc of emails. Please note the slight mutt config
  changes: '%r' vs. %r if you are going to use Cc (also check

Thursday, December 3, 2015

randup trickery

We at opmsg team take security very serious. Really.

So at times we end up digging in underlying libs which
we use, to understand entropy and key generation.
Since we take security so serious (really), we are very Nazi
about entropy. If we find anything that might be an issue
or could be an issue if used in certain environments,
we take all necessary actions to protect you.

So this time we inform you, our valued customer, that
usage of libressl in certain Linux environments could
be dangerous with regard to key generation. In nested
container environments (cloud!) the state of the PRNG
may be cloned and there is nothing you, our valued
customer, can do about it via the libcrypto API.
Thats why we, who take security very serious, informed
the libressl team and proposed a solution.

PoC and solution may be found here. Please note that
this is different from the CLONE_PID issue in past
which allowed for reuse of pids but is no longer possible
on recent Linux kernels.

Beside that, opmsg team acknowledges time and effort libressl
developers invest into the project and found libressl
code clean and mature. We continue supporting and recommend
use of libressl in opmsg.

Thursday, November 19, 2015

more packet trickery

Pushed some more changes to libusipp git:

 o 802.11 stuff for better frame handling (wanna chat
   about wireless firmware exploits? Come talk to me [1] :)
 o No longer needing libdnet for ARP objects, which means
   that ARP and EAPOL is now also available on OSX. So since
   now you as well bypass your favorite 802.1x Switch-Nazi with
   your oh so cool iShit

[1] Me also interested in any patches already existing to
    use the radiotap pflags channel element for TX (e.g.
    setting TX channel per packet. the channel flag only seems
    to notify about RX channel for captured packets and is
    ignored for transmission?).

I know: the libusipp API is not very stable, but I dont mind.
All my github projects requiring libusipp properly build with
latest pull.

Friday, October 23, 2015

da packets

Ported libusi++ to OSX. While doing so it was necessary
to lowercase all the enums like IPPROTO_UDP as the Xcode
compiler also tries to expand the enums (unlike gcc).
And as macro definitions pollute the global namespace
from either netinet/in.h or dnet, this was necessary. Its much
cleaner code now and also works with -pedantic.

While porting libusi++ to OSX, it was therefore necessary
to adjust some of the other code to reflect lowercase
enums, such as QI. Also polished QI to work against the
Darwin TCP stack, so its now possible to QUANTUM INSERT
into Safari. Seems like the Darwin TCP stack requires nonzero
TCP window and Safari ACKed GET requests before accepting
the (injected) reply.

After all TCP/IP stacks evolve over time and theres enough
relaxing space in the RFCs to break INSERT tools by small
semantic changes in the TCP stacks (sometimes called finger
printing). So dont expect QI as-is
to work in 10 years. Interesting to see that such quite simple
technique still contains some pitfalls.

All in all that was fun with lost packets. Tomorrow biking
to lost places to shoot some nice pictures of lost sofas. :)

Thursday, September 17, 2015

opmsg BoringSSL tests

Recently tested opmsg against G's fork of OpenSSL, named BoringSSL.

Thats more of a smoke test rather than a recommended
setup. BoringSSL is downstripped and does not provide
certain algorithms like ripmed or blowfish. It is
also missing the brainpool EC curves. It also does
not offer the CFB modes for any of their block cipher
algorithms. Some functions for EC-POINT conversions have
had to be re-implemented. After that, it cleanly builds
with BoringSSL.

If you know what you are doing (e.g. not using any
missing mentioned algorithms or modes from above)
AND you dont have peers that use brainpool EC curves,
you may use opmsg linked against BoringSSL.

The main reason for G was most likely to be upper
hand for new algorithms like ChaCha20 from DJB which
is optimized for (embedded) software such as on
smartphone SoC's which are missing native crypto instructions like AES-NI. So they dont need to wait for other projects
to add support for it.
Yet, its still not feasible for me to add ChaCha20
to opmsg as standard OpenSSL is not yet supporting it.

If you have a short link to the OpenSSL project, ask them
to add ChaCha20+Poly1305 to master (its already in a
special fork) :)