Monday, July 6, 2015

EC persona trickery

EC persona support has been added to opmsg.

The benefit is that generation of EC personas may be done
within milli seconds. So the threshold of throwing away
personas or to generate new ones for each contact has
almost lowered to zero. It all works transparently to
the user who just needs to use --newecp instead of --newp
when creating a new persona. Instead of DH Kex, opmsg
transparently uses ECDH Kex in that case. As all group
parameters are within the pubkey blob, this does not require
for DH parameters such as in the RSA case.

For the ECC algos, the Brainpool curves are used which
are standartized by RFC 5639 which explain how the group
parameters were selected, unlike for the potentially
backdoored NIST curves.


Thursday, June 25, 2015

pita bread trickery

As can be read here, its known since quite some time that the
CPU is emitting frequencies upon operation which contains
enough "signature" so that crypto keys may be
recovered. This happens namely during RSA decryption
and signing operations. As this is a public paper using
public available SDRs and thinking 20years ahead, theres
good chance that there are setups today with antennas and sufficient DSP computing power that may recover keys from a far larger distance than just the mentioned 50cm.

What does that mean for opmsg?

In the new version (1.3), I enabled RSA-blinding during decryption and signing. During "normal operation" due to the DH 
keys in use, there should be no attack surface. In the worst case
the attacker just recovers the private half of the DH key of
his own specially crafted message.
Further, opmsg verifies integrity of the sender before any 
decryption so you cant decrypt specially crafted messages (as 
required in the paper) from strangers who hope to capture
signals once the message is processed.
Its already recommended (and easy to setup) to use a dedicated 
persona for each peer. If you follow that guideline, even
w/o RSA blinding the attacker can just decrypt his own messages.

What else is new?

 o The use of RSA-fallback mode can now be seen in output
 o it is possible to --burn keys (only use once)

Thursday, May 21, 2015

weakdh trickery

Now, that the TURMOIL slides make sense, I adjusted my own
projects. The good news is that I always used to generate
unique DH params (I wonder so many ppl apparently didnt -
there is no real benefit to use hard coded values, except to Eve!?)
in my projects during or before build. So it should be
quite hard for a Nation State Adversary to break that.

For lophttpd and crashd, I removed 512 and 1024 bit DH params
support and use 2048bit instead. opmsg always supported
2048bit (and higher), but the default was 1024. So I changed
the default to 2048 bit. Existing personas can be "upgraded" by
using the --newdhp switch. I was thinking this switch
may just be used in rare cases, but now it turns out it
was the right decision to design opmsg protocol with easy
DH params re-creation in mind. SUCCESS! DH keys that are
already "in flight" cant be upgraded, but may be used
as before (taking the 'weaker' 1024bit into account) even
after upgrading to 2048bit DH params.

Unfortunally, 2048bit keys come at the cost of a longer key
generation process. This may take a couple of minutes.
If thats too much for you, you are free to change your default
DH params len to 1892 or whatever your level of secrecy
demands.

Thursday, May 7, 2015

opmsg trickery

Given the recent crypto discussion, mass surveillance and
cyber jokes in general, I uploaded a new project to my github.
It was about time.

I wonder whether our gov is equally toast/bad in other fields,
or if I just get pointed to it because I have some background
in this field and am blind to all the other failures where
I am missing the knowledge. (SIGILL//NOPORN)

Update:
The first review round is over and it seems like opmsg
concept found some friends. I got some recommendations
which were incorporated in the git. Thats new:

- fixing insufficient hashing of persona key to
  detect tampering of RSA keys during transit/import
  (RSA's e value was simply not part of the hash and it now is)
- removing OFB cipher modes in favor of CTR and GCM modes (AES)
- adding option to allow linking of personas (see README)
- adding cygwin support

It is incredibly hard to review your own code; so thanks to
myself. While I buy the OFB arguments, I am not sure if its
a benefit to add ECC support for personas. ECC is mostly based
on curves with parameters chosen by NIST. The same NIST that is
suspected of putting backdoors in crypto standards
(slides), even more in standards that use ECC to generate
randomness! Knowing this, why should I trust any parameters 
chosen by them? You can argue that suite-B, the NSA approved 
standards for protecting US gov infra, is unlikely to contain 
backdoors for themself and that this would be a tough bluff
to do so just to read Putin's email. But given the additional
implementation cost (maybe I should crowdfund it?) for
little benefit or even "badfit" this seems not worth the effort.



Thursday, April 23, 2015

C++11 bailout trickery

Is someone C++11 guru enough to make a statement whether
the following C++11 code is correct? In particular on
whats happening on line 24, as the lambda should not
harvest the memory structures (scope?).
To me, everything looks OK. If thats the case, it would ease
a lot of cleanup routines on error returns from functions.
Please leave a comment.

Sample C++ code


Wednesday, March 25, 2015

troubleshooter trickery






Demo of SELinux disable on a Fedora 21 default desktop. A full writeup can be found here.

Thursday, January 8, 2015

U2F trickery


In the last post I promised to stop threat analyzing. So here
is some dev again which I already started developing back
in 2014 and where I finally found some time to finish.
Its a small U2F stack with the APDU framing code based
on Googles U2F reference code. After reviewing a lot of other
U2F code (sigh!), I found this reference code comprehensive enough to be usable for myself and for PAM code.
It also builds on Darwin, but I didnt have time to test it
there.



Friday, December 19, 2014

QI for the win

Now that we officially know that 3G can be broken and that
it makes sense to place particular (passive) hardware on the
roof top of embassies (the cellar is already stuffed with
torture equipment and you have better gain at the roof),
my threat analysis here was correct. In particular the
last paragraph should be repeated, as you can start sending
your QI before the victim packet is even close to the
target if you just captured the SYN packet on air.
As a bonus, you dont need to deploy evil hardware in the
target network.
Nevermind, I am not going to torture you with more threat
analysis posts. There are enough of them. :)


Thursday, December 11, 2014

sshttp tproxy trickery

I updated sshttpd to allow muxing of HTTP(S)/SSH
to whole subnets. Until recently, the setup was
per single host. Now you can run it via -T on your
gateway and Layer5-switch your whole internal net.





Thursday, October 30, 2014

lophttpd fucks the POODLE

Not just because they are ugly but also because lophttpd
never was affected by POODLE, since SSLv3 was
disabled for a reason in favor of TLSv1. I think about dropping
TLSv1 too and just allowing TLSv1.1+ in future.

To my knowledge lophttpd is also the first webserver
utilizing Linux seccomp sandbox.

I also added SO_REUSEPORT support today, since Google
told us that when handling c10k, their processes
are un-evenly distributed across the cores (what the hell
are they doing there?)
lophttpd wins again, since even without SO_REUSEPORT,
such problem never existed for you:





which shows running it on 4 cores, handling c10k. Could
there be a smaller footprint?


Update:

After carefully reading the commit for the Linux kernel
that introduced SO_REUSEPORT, I came to the conclusion that
for Linux there was an entirely different reason to introduce
it than there was for 4.4BSD at the time. According to the
git commit message, uneven distribution among the cores
only happen when the "number of listener sockets bound to a
port changes (new ones are added, or old ones closed)".
So its clear that it never affected lophttpd and it "leaks"
interesting info about the architecture of the google
webserver, why it had such problems before the patch
and which kernel they are using. OSINT for the win.
(Such architecture where new listeners are created or removed
do not make much sense to me anyway, so there are some
questions left.)

So in theory, I could remove SO_REUSEPORT again but I will
leave it as is for now, in case more webserver instances
are started later. Note that it doesn't make sense to have
more lophttpds running than there are cores on
your machine. I do not support hyperthreading yet, so
-n 0 is what you want, if you have such heavy load at all.

sshttp btw also uses the same multi/single-thread architecture
without SO_REUSEPORT (yet).