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) :)

Thursday, September 10, 2015

opmsg trickery

opmsg has received some attention recently thanks to Phil
and his PGP de-setup. Some people checked the protocol
and there have not been any major fuckups so far.

Thanks to the people involved in the discussions.

The new version:

o Introduces version=2 messages which also hash src-id and dst-id
  in the KDF to derive the session-key which prevents
  theoretically possible evil-maid adaptive choosen ciphertext
  attacks (that should never happen in practise as failed
  decrypted messages will just be ignored and not be reported
  back to the sender several thousand times). version=2 must be
  configured in the config.
o Adds the possibility to restrict kex-id usage (upon decrypt)
  to the dedicated peer (this will detect/avoid cross-persona
  references of kex-id's). peer_isolation=1 in the config which
  is off by default.
o persona self-linking to implement deniable, yet still properly
  signed/verified, messages. See the README.

Its all inter-operable so pulling the git doesnt break
anything, except 5E's GPG brute-force cluster. :)

version=2 will be made default once enough time passed
so that most folks pulled the git meanwhile and support
for it is widely available. I'd also like to add some of the new 
ciphers like chacha20 but it seems only LibreSSL has got them so 
far. This would render messages unreadable for recipients which 
link against OpenSSL.

Friday, September 4, 2015

Contact trickery

If you send me messages via blogger, do not forget
to include your contact address (email) into the message
body if you hope for an answer. The default address is always

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

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)

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