I've been developing ResoMail for quite some time and I need your help. I'm looking for people who would like to test it and for volunteers to help me with development (it's an open source app). I have a lot of ideas of new features, but I will appreciate your feedback and help. So here what is ResoMail: ResoMail is an alternative mail system based on cryptography, providing a private and secure mail for confidential and sensitive correspondence. Encryption is done under the hood, transparently. So even grandmothers will be able to use it without accidentally sending anything unencrypted. This is an open source project. Anyone who's inclined to do so may view the source code and can even contribute to the project. Actually, it's difficult for any cryptography application to be trusted without it being open source. It uses an alternative DNS implementation with secure domains. Each domain has its own certificate to sign subdomains and email addresses. The ResoMail server software has secure host features which allow private keys to be kept off of the host server. So even if the server is compromised, the keys will remain secure. Mail account creation for end user is simply like entering a login and password. Key pair generation, sending public key for signature by domain owner and receiving it back is done automatically "under the hood" Easy, one-click new server configuration. To prevent spam and "fishing" scams, the "From" address can not be forged. This is an important feature that is not available with other e-mail systems.
Out of curiosity, why was Twofish chosen? The AES has seen more cryptanalytical attention, which gives us more confidence in its underlying design principles. Also, how do you authenticate? And, how is SHA-512 used?
Great work and all i can say is, about time someone implemented this. I had to scare my mother with emails from fbi.gov etc to make her aware not to trust From addresses. Just that feature alone is valuable. SHA512 is used as a hash, RSA is 2048 bits, and the Twofish key size is 256 bits according to the docs.
Right. I know what these primitives are, but I'm curious as to how they are used. On what is SHA-512 computed? In what way is RSA used to encrypt and sign? In what mode of operation is Twofish used? That sort of thing will help me determine what type of security goals are, or are not, currently possible.
I've read that there are no major security flows been found in Twofish, and the winner for AES was chosen for simplicity and speed. I've chosen Twofish also because I think there is bigger chance Bruce Schneier will look into ResoMail if it will use TwoFish Encrypt a random byte sequence with public key and decrypt it with private key on the other side, for both parties, the server public key must be signed by domain to work, to be sure that it's the right server with domain your looking for. For message signature together with RSA.
This sounds very interesting indeed ! Exactly how would ordinary users set this up on their PC's ? Thanx
The AES is actually a conservatively secure design, and with regards to some aspects of its design, it edges out both Twofish and Serpent; for example, Rijndael achieves full diffusion after two rounds, while it takes Serpent three, and Twofish four. There's a lot more to it than you might think -- especially if you've read about security margins (i.e., the more rounds, the more secure). It's not that simple, and I'll be glad to explain why. Whether or not Bruce is more likely to notice it because it uses Twofish is something I can't answer. However, I think that for most applications, it makes more sense to use the AES. I quite like many of the design principles behind Twofish and Serpent, so it's nothing personal. Realistically, if your implementation breaks, it won't be because of which block cipher you use. That's because we're not as good as building the rest of the system as we are building cryptography. In the past, I wrote:
Initially I wanted to create a "paranoid" composite cryptographic engine for ResoMail, which will link together several algorithm, like TrueCrypt does, but also for public key cryptography algorithms and digests, so for example if SHA512 is broken then there will be a part of hash calculated with Whirlpool and Tiger which will not be broken. What stopped me from developing it was the opinion that it's over-paranoid, will increase key and signature sizes and will make ResoMail much more complicated. And I thought ResoMail is important not in selecting by default an equivalent of 8096bit RSA keys but in building infrastructure for secure and simple communication and if most users will demand stronger encryption we'll add it. Same with Twofish, if major flows will be found in Twofish then we'll change the algorithm or implement the composite engine.
Thank you! Now they can go to http://resomail.com download the client, unpack or install it, depending on whether they have installer or portable version and then can go to http://reg.resomail.com and register a new account and start using it to communicate with another person who has ResoMail installed. An advanced user might request a ResoMail server and a ResoMail domain (now we're giving out for free sub-domains of *.free domain) Install and configure the server and then generate as many mail accounts as he needs.
This seems like a great idea, an open source encryption email software, a similar project I know of, is the Enigmail plugin for Thunderbird. The only weakness I see with Resomail is that you need to trust your encryption keys to a third party, with Enigmail your encryption keys are stored in your own computer and nobody other than yourself can be subpoena to hand over the encryption keys. This is what happened a few years back to Hushmail who was forced (and gagged by a court order) to swap some private user encryption keys by FBI encryption keys, so they could read the email. It would be interesting to know what Resomail can do against it. Regarding the implementation of Twofish, my understanding is that in encryption it is always better to use standards, most cryptographers are now looking into AES weaknesses because it is so widely used officially, fewer cryptographers will be interested in testing how good Twofish is reducing the chances to be forewarned of vulnerabilities in that algorithm. I actually once emailed Mr Bruce Schneier asking him a question about the Serpent algorithm, which he rated high in one of his first books, and he was kind enough to send me a short reply, I recall him saying that in encryption it is always best to use standards.
Would it be possible to rephrase this without the sexist and ageist stereotyping of grandmothers as somehow being less intelligent than their grandchildren?
Pinga Here you go. So even grandfathers will be able to use it without accidentally sending anything unencrypted. Only kidding lol. I'm sure box750 meant know harm, but he's not 100% wrong !
I'm sorry, but why do you think that ResoMail send your private keys? It send only public key to certificate authority (domain owner) to be signed. If there is something on ResoMail site that implies it please tell me so I'll fix it. Actually as far as I remember DES was a standard for too long, even when it was considered weak for modern computers.
There are two types of paranoia in security. One is useful, and a part of any conservative design, and the other is harmful, unfounded, and fruitless. The kind of paranoia that leads to implementing every cryptographic primitive under the sun, with key lengths and block lengths through the roof, is the latter. The former kind, however, is simply the notion that cryptography is about limiting trust. Think of it as "guilty until proven innocent." In other words, assume that all parties involved are potential threats; needless to say, we want as few parties involved as possible. The fewer, the better, and the fewer, the simpler; this reinforces the fact that we should avoid complexity at all costs, because that's what will get us in the end. You made the right call, but it's not that what you decided against implementing was over-paranoid; it's that this kind of paranoid is just misguided from the start. And I don't know of any security-competent person who thinks this way. The bottom line: If you're paranoid about the cryptography, then you're paranoid about the wrong thing. Truth be told, this is probably the last thing you should be paranoid about. Security and simplicity are exactly the traits you want, and they complement each other well. Be careful about tending to user demands, unless your user happens to be bound by some policy where the demand might make sense. Otherwise, you'll fall victim to the bad kind of paranoia I mentioned above. Well, obviously your design should be this modular to allow for such a swap in the event of a practical attack, but I would still argue that the AES is the more sensible choice, at it's the most targeted block cipher in use; this is a direct result of it being a standard. Having said that, you not only have a block cipher that will satisfy more policies across the board, but you have a block cipher that is receiving the most cryptanalytical attention, thus boosting the confidence we have in its design.
while the guru giving their expert views, please bear in mind that there isnt any "perfect" software....... how should it be done....... it is the developers' call... not about what u think it should be done...
Certainly; it is the developers call. On the other hand, not knowing, and not assuming, the designer's experience in implementing cryptography, I can only offer my experience-ridden advice. If we would assume their experience is minimal, this advice might be quite beneficial; at the very least, it's good conversation. If this is any reassurance, my advice is based on concepts that are accepted within the community (and some that out-date me), so it's more objective than it might seem. Oh, and, obviously, perfection -- especially in the case of security software -- isn't a design goal, nor should it be. Ironically, we've found that some perfect methods only make things harder to get right at the real-world implementation level, so they can often do more harm than good. In the grand scheme of things, getting better at security is going to mean becoming as re'd as implementing as we are at innovating. We're building really cool stuff that we can't consistently use correctly.
I've opened a topic about open sourcing cryptography software, can you please help me with advice, the topic is here: https://www.wilderssecurity.com/showthread.php?t=248639
The bold part should be "good at." How that typo happened is beyond me. Then again, this Eee PC's keyboard, albeit impressive for its size, challenges me from time to time. I need a good keyboard for writers. Any suggestions? Logitech seems to have some good stuff. I have their VX Nano cordless mouse (short, 7mm USB receiver and hyper-fast alloy scroll wheel), and it's awesome and a half. Pardon my getting off topic here.
Question: How is ResoMail different from using an email client (e.g., Outlook) with a digital ID (e.g., VeriSign Class 1)? Once you’ve exchanged IDs with the recipient (a very easy process), then encryption (and/or digitally signing) is transparent to both the sender/receiver of the email. Thank you.
