Thank you for the thorough response! I'll look into NTU.
Good point about p2p vs email protocol. I guess my point is that there may
be an opportunity to leverage the underlying technology behind bitmessage
to create a solution that feels like email but functions like a powerful
metadata stripping communications protocol.
To be ultimately secure, it's important to keep away from centralization
and closed source as much as possible. SSL cert forges and backdoors would
and likely will always be a concern.
Take care
*---*
TANQUE
wickr: letanque | tanque.pro | get@???
*PGPKey: *
http://pool.sks-keyservers.net:11371/pks/lookup?op=get&search=0x929D2552A998B662
*CONFIDENTIALITY STATEMENT: This email message, together with all
attachments, is intended only for the individual or entity to which it is
addressed and may contain legally privileged or confidential information.
Any dissemination, distribution or copying of this communication by persons
or entities other than the intended recipient, is strictly prohibited, and
may be unlawful. If you have received this communication in error please
contact the sender immediately and delete the transmitted material and all
copies from your system, or if received in hard copy format, return the
material to us via the United States Postal Service. Thank you. *
On Thu, Jun 12, 2014 at 3:28 PM, OnionMail <partecipa@???> wrote:
> Il 12/06/2014 20:57, Frank leTanque ha scritto:
>
> OnionMail sounds interesting; I have a couple of questions that maybe
> someone could answer:
>
> 1) SSL on top of Tor, for an end to end encryption mail service. Is that
> really necessary? Maybe I misunderstand how onion routing works and/or how
> the encryption for OnionMail works?
>
> SSL is used for these reasons:
> * Verification of the server:
> If an attacker get the root privileges on the server, it can read
> quickly the tor
> private key. An attacker can't read the server's private key.
> (If server don't use -ndk option and use the F(X) start "boot" method).
>
> * Cryptography (on Internet and Tor):
> Don't forget the NTU project:
> NTU is a fixed proxy to rebound the connection between internet and tor.
> This is another future project to protect the exit/enter identity of
> onionmail servers.
>
>
> 2) Though messages are all stored on the server in an ambiguous manner, a
> correlation attack could still be leveraged against users, correct?
> Especially since the network of people using this service is very small.
> Correlation attack based on size of message retrieved and the fact that it
> needs to be retrieved. An early video on Tor vulnerabilities:https://www.youtube.com/watch?v=DFY615-q6Ls
> There are more recent studies. Basically, my takeaway has been that
> pluggable transports through a trusted entry node is the most secure method
> available.
>
> To protect against data stream correlation we are working to NTU project.
> For example you can activate 2 or 3 tor process and rebound connections
> via NTU.
>
> Example:
> Alice ---> NTU ---> NTU ---> Bob@OnionMail ---> /dev/random ---> poisoned
> bait!
>
> The dafault configuration of onionmail limits the size of the messages to
> 2MB. (it can changed).
> Other is all working progress...
>
>
> 3) How does this compare to Bitmessage? Security enthusiasts should really
> look into bitmessage because they will find themselves very interested in
> the concept and even the early execution. Bitmessage would have better
> metadata obfuscation, correct?
>
> I don't use bitmessage. I'm using InterNOS, (similar to torchat + voice).
> It my very old project for Android platform.
> But this is another history....
>
> OnionMail is a mail server not a p2p protocol.
> It is a mail server like exim4 or postfix, but it use tor and is encrypted.
>
>
> *---*
> TANQUE
> wickr: letanque | tanque.pro | get@???
>
>
> *PGPKey: *http://pool.sks-keyservers.net:11371/pks/lookup?op=get&search=0x929D2552A998B662
>
> *CONFIDENTIALITY STATEMENT: This email message, together with all
> attachments, is intended only for the individual or entity to which it is
> addressed and may contain legally privileged or confidential information.
> Any dissemination, distribution or copying of this communication by persons
> or entities other than the intended recipient, is strictly prohibited, and
> may be unlawful. If you have received this communication in error please
> contact the sender immediately and delete the transmitted material and all
> copies from your system, or if received in hard copy format, return the
> material to us via the United States Postal Service. Thank you. *
>
>
> On Thu, Jun 12, 2014 at 6:58 AM, OnionMail <partecipa@???> <partecipa@???> wrote:
>
>
> We are writing and translate the documentation of protocol...
> (This is a work in progress...)
>
> (I am attaching in this mail the “rulez” help file).
>
> Sorry for ver long reply!
>
> OnionMail use standard SMTP and POP3 protocols.
> OnionMail is an SMTP/POP3 mail server compatible with all mail clients.
>
> Main informations to know about OnionMail:
> Inhibition of store any message in relay server.
> Only direct connection is allowed without multiple connections-
> Mail messages are saved only in the recipient's server and encrypted
> with multiple asymmetric keys.
>
> All messages are saved into an encrypted format:
> 7 KEYS AES 256 + 2 RSA 2048 keys + SALT. + 1 AES 256 key + SALT for each
> message line.
>
> There is an RSA 2048 asymmetric key for each inbox.
> The RSA key are encrypted by the use password.
> There are two user's password:
> SMTP send password. (Decrypt via HASH 7 AES256 + RSA2048 user inbox to
> write).
> POP3 read password. (Decrypt via HASH 7 AES256 + RSA2048 inbox to read).
> The public key sores the message into the inbox.
> The private key reads the messages.
>
> An attacker can't read your message with server key.
> All data is stored via HASH algorithm.
> An attacker can't read metadata with server key.
>
> All files are name into alphanumeric hash name.
> An attacker can't associate a single file to any user.
>
> The server's master key can't used to decrypt the users account and read
> the messages (without username, and all passwords).
>
> All server are forced to use SSL (in tor network).
>
> The server's master key is not on the server.
> When an OnionMail server start it do the “boot” process:
> The server negotiates a function F(X) to another server (for each server).
> All F(X) have a counter (OTP counter) controlled by the KCTL
> autodestruciton certificate.
> The administrator of an OnionMail server, can enable or disable the key
> without connect to the server.
> The server's master keys is calculated via some F(X) and server random
> data.
> The F(X) can't used to get the server's master key.
> The server don't know the F(X).
>
> Example:
> The server is stolen or seized.
> The administrator sends the KCTL certificate for autodestruction, all F(X)
> are destroyed and the server become unusable.
>
> All connection between user and server are via tor network using STARTTLS.
> The server use POP3 to force the user to read and delete the messages from
> server. The unreaded messages are deleted after 60 days.
>
> All files are deleted by wipe.
>
> The server supports natively mailing list. (the temp files is encrypted
> via AES256 KEY +1 KEY + SALT for each message line).
>
> There are some exit/enter server:
> These servers connect internet to tor and tor to internet.
> There is a protocol named VMAT to use normal mail address (without 16
> characters onion address).
>
> There are some extended functions accessible via server's bot:
> Server's help.
> User configurations.
> Personal SPAM list (to block spam messages).
> VMAT Address verification.
> USER SUBSCRIBE.
> Mailing list.
> VMAT address configuration.
> Etc...
>
> The server can use GPG messages to communicate with the users.
> For example you can create a mailing list sending to the server an
> encrypted message. The you receive an encrypted message (use MYKEY command
> first).
>
> All OnionMail server are federate and servers check each other.
> When the SSL engine check the certificates:
> Check HASH.
> Check Public key (full data).
> Check Date & time.
> In the future we will implements the check via other servers.
>
> The sender is verified via TKIM (similar to DKIM but is used in tor
> network), reading MX record (via exit node, not directly or via federation
> server list), SMTP session simulation (mail from... tcpt to... rset... ).
> The VMAT address is verified by RSA signature, TORM VMAT LOOKUP SMTP
> extension.
>
> The administrator of an OnionMail server can't read your message and can't
> know what are the user on the server.
> The Administrator can creates a voucher code to use to users subscription.
> (In this way the Administrator can know the user identity).
>
> onion.py
> This script is a wizard to register a new OnionMail's account.
> It configure quickly and simply:
> Choose the hidden service.
> Create a new OnionMail user.
> Activate a new VMAT address (to use without 16 characters).
> Create a new GPG key pair up to 16384 bits.
> Configure Claws-Mail (account, SSL, inbox).
> It simply extract a skel file into the claws-mail directory (if not
> exists) ad add an inbox. Then configure account (accountrc file), and SSL
> certificates of OnionMail server (certs directory).
> The user is registered via RQUS extension of POP3. (OnionMail's extension
> to use subscription method via tablet, smartphone and PC).
> The script shows a captcha code in ASCIIart.
>
> There are some extensions of SMTP protocol used only by OnionMail.
> TORM and TKIM
> TKIM is an extension that implements a server authentication like DKIM.
> TORM is the main onionmail's extension. Here I list only some of the
> descriptions:
> TORM PUSH Negotiate a F(X)
> TORM DERK Calculate a F(X)
> TORM VMAT LOOKUP Verify VMAT address.
> TORM IAM I'AM (user by OnionMail manifest and federation list).
> TORM WHO Used to verify another SSL certificate.
> TORM VMAT TO Used to send message to VMAT user alias.
> TORM K Get the RSA public key of this server.
> TORM MX Query DNS MX record (only exit server).
>
>
>
>
>
>
> Il 12/06/2014 12:40, William Waites ha scritto:
>
> Hi Anopticon,
>
> I've looked a little bit at OnionMail -- I'm also interested in the
> general problem. But I have difficulty understanding exactly how it
> works. From an end-user perspective it is reasonably clear but the
> operation of the server software doesn't seem to be very well
> explained. For my part (I have nothing to do with the Tails project
> other than as a user) I wouldn't be comfortable using it or
> recommending it without properly understanding what it does. Do you
> have anything that is more like protocol documentation that describes
> exactly what the servers do and how they communicate amongst each other?
> My apologies if it is there and I simply haven't been able to find it.
>
> Best,
> -w
>
>
>
> ______________________________
> _________________
> Tails-dev mailing listTails-dev@???https://mailman.boum.org/listinfo/tails-dev
>
> To unsubscribe from this list, send an empty email to Tails-dev-unsubscribe@???.
>
>
>
> _______________________________________________
> Tails-dev mailing listTails-dev@???https://mailman.boum.org/listinfo/tails-dev
> To unsubscribe from this list, send an empty email toTails-dev-unsubscribe@???.
>
>
>
>
> _______________________________________________
> Tails-dev mailing listTails-dev@???https://mailman.boum.org/listinfo/tails-dev
> To unsubscribe from this list, send an empty email to Tails-dev-unsubscribe@???.
>
>
>
> _______________________________________________
> Tails-dev mailing list
> Tails-dev@???
> https://mailman.boum.org/listinfo/tails-dev
> To unsubscribe from this list, send an empty email to
> Tails-dev-unsubscribe@???.
>
