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 17, 2015
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.
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
noreply@.
to include your contact address (email) into the message
body if you hope for an answer. The default address is always
noreply@.
Subscribe to:
Posts (Atom)