Re: [liberationtech] Asyncronous secure messaging (Email): Why reinvent the wheel?
On Sat, Nov 09, 2013 09:37:27 AM +0100, Fabio Pietrosanti (naif) wrote: All initiatiatives are trying to setup some new technological infrastructure, some new communication or encryption protocol. We MUST USE THE INTERNET STANDARDS, with modifications here and there, improving them, in order to reach our goal in securing asyncronous communications methods commonly referred as Email. While i appreciate all of those cryptographer trying to do something new, i must say that THIS IS THE WRONG WAY! +100 :-) THANKS Fabio! Agree word by word with the whole message! -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Asyncronous secure messaging (Email): Why reinvent the wheel?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Why should I continue to trust the very standards and systems that were subverted, corrupted, or just plain sold me out for a profit? Standards and organizations that enshrined codified confusing, weakened, and watered down systems and made privacy damn near impossible. The endless bickering and back room dealings to keep government contracts, security agency moles and corporate shills fat and wealthy and all data trackable - THAT IS STILL GOING ON. Just follow any IETF discussion group. Screw that. It deserves to die an agonizing and expensive death. Kill the beast. I love email, and use it daily, yet I would personally plunge the sword in and gut it myself to make room for something completely new, away from prying eyes and content/traffic analysis. I choose to support and reward the innovators and free thinkers that refuse to color inside the lines. The p2p, decentralized, distributed, meshnet, anon remailer, onion routing, Tor hidden service, Whonix, high latency, low traffic correlation, Bitmessage, steganographic hidden covert channel developers. Everything else is just kicking the can down the road, and furthermore is enabling the fascist panopticon surveillance state. DN Bitmessage: BM-2DA3ob7GXkVF1yFEnCwSGXtWT3Hqqu1haJ - -- On 11/9/2013 9:25 AM, Edwin Chu wrote: Why is it better to limit our innovation to the existing standards when creating the nonexistent secure messaging system? Sometimes we could improve security of a system by adding layers to it, like HTTPS and ZRTP; sometimes hacking on a legacy protocol isn't good enough and we create new things. After all, even we just add a new layer to existing standards, we are creating new standards. While resemblance to existing protocol may boost software adoption, I don't see it is wrong to design a new protocol (having it based on existing one or not) and then make it a de facto/official standard. Edwin On Sat, Nov 9, 2013 at 12:56 AM, M. Fioretti mfiore...@nexaima.net wrote: On Sat, Nov 09, 2013 09:37:27 AM +0100, Fabio Pietrosanti (naif) wrote: All initiatiatives are trying to setup some new technological infrastructure, some new communication or encryption protocol. We MUST USE THE INTERNET STANDARDS, with modifications here and there, improving them, in order to reach our goal in securing asyncronous communications methods commonly referred as Email. While i appreciate all of those cryptographer trying to do something new, i must say that THIS IS THE WRONG WAY! +100 :-) THANKS Fabio! Agree word by word with the whole message! -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJSfqvRAAoJEDMbeBxcUNAej4AH/Rxrvz9Kmb/5Lvp5g7F/jFN9 7bjcVPHC1njtJLT+2efcQfO33mmkFYawyEY3lGmSlajnxekOEy96ja1SKHWrJs2e JQahSA80SjRQuH/EcPf9JOX+TgeTZX/lVKoSHSfme9iUs0PZlgsVU7V6Ns5pGSbq ZhVYBN05onl4Ca2VL8fXO3lm3BlfDh44q0LpnjXV5Qhp08Lm+sTKKAgQJTT/Nogs U5k5Czzr9S36RsS7wEY4kuXDpJVifqLvIQ8prvD76dhigTVRG3XfidHXoMx5gbzh k54Q17R6jx4e++bkhTPttWVQGFIsRt0KSD5HXYFszPnMNw9Q6qLJLFHDxrUVVnk= =JRBz -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Asyncronous secure messaging (Email): Why reinvent the wheel?
On Sat, Nov 9, 2013 at 12:37 AM, Fabio Pietrosanti (naif) li...@infosecurity.ch wrote: We have a big pile of existing very good and very strong IETF RFC standards for email. We need to improve the way those are used. We have OpenPGP. We have MIME. We have S/MIME. We have TLS. We have ZRTP. We have SMTP/TLS. Well, we have a big pile of standards, and yet Johnny Can't Encrypt™: http://www.gaudior.net/alma/johnny.pdf Please, think to use that pile of standards and think to approach email security by improving those one. It would be irresponsible not to. There is a fine line to be walked between improving the user experience and building upon existing work. So far most attempts I've seen at improving the situation have sacrificed security for convenience. I don't think this needs to be the case. Perhaps some day I'll release some software which provides both. Working on it ;) -- Tony Arcieri -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Asyncronous secure messaging (Email): Why reinvent the wheel?
Il 11/9/13 11:29 PM, Tony Arcieri ha scritto: Please, think to use that pile of standards and think to approach email security by improving those one. It would be irresponsible not to. There is a fine line to be walked between improving the user experience and building upon existing work. So far most attempts I've seen at improving the situation have sacrificed security for convenience. I don't think this needs to be the case. Perhaps some day I'll release some software which provides both. Working on it ;) The design of a security system, would in that case also specify the user interactions and interface behaviour for all actions of authentication and key management. In ZRTP there's also some definition on how the security procedures within the respect to the user should be properly handled. So a standard should start working on proper key management based on existing ones, with semi-automated procedures including all the user-interface interactions required. If there is the need to extend some kind of signaling procedures, by safeguarding SMTP protocol infrastructure and interoperability, those should be done by using extension to existing data formats (like MIME and MIME Objects). If there is the need to protect metadata, some cryptographical solution has to be defined, possibly by re-using existing RFC protocol stack for key exchange, and data format for storage of those data should be defined with some existing used extensions (it may use SMTP Headers metadata data, to embedd encrypted metadata). I don't have a solution in my hands as it would require some hard protocol and crypto brainstorming job and proper community review-process. However i really think that this should be the way to do it, and if Dark Mail is trying to do something like that, they should drop out an IETF's standards based internet-draft and subject it to public review and discussion ASAP. -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
