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.