On 11/12/2009 15:02, Konstantin Andreev wrote:
Hello, Nelson.
On Fri, 11 Dec 2009, Nelson B Bolyard wrote:
On 2009-12-10 02:12 PST, Gregory BELLIER wrote:
I noticed the 3DES cipher is used to encrypt emails with S/MIME and I
would like to use another one.
According to the version of S/MIME standards that are implemented in
Mozilla mail clients, you can only encrypt using one of:
a) the ciphers that the correspondent has previously informed you that
it supports (which it would have done by sending you a signed email
message), or
b) using the one cipher that all S/MIME implementations of that era
were REQUIRED to implement to ensure interoperability.
If you have NOT received any signed emails from the correspondent to
whom you wish to send encrypted email, then you have no choice but to
use the one required cipher. If you HAVE received a signed email from
that correspondent, then your Mozilla email client will automatically
pick the strongest cipher that is mutually supported.
You CANNOT send a message encrypted in a cipher that your email
program does not KNOW that your correspondent supports.
No, not so simple.
Sadly, not. But Simple is the only way forward that will deliver
security :)
Let's see how many ways I can disagree ;)
In common sense, choosing cipher is a human decision, not a sending
agent one. There could be strong reasons for this:
Protest! No, it's a protocol design decision, and if that is bungled,
as it was in S/MIME, it ends up being a developer decision. There is no
benefit in offering users the choice of crypto algorithms, and plenty of
scope to reduce your security.
There is nothing common sense about it, it's really a mistaken marketing
tool by cryptographers and crypto-fanatics, perhaps in a forlorn hope of
spicing the market for their product.
-- I am prohibited to send particular information encrypted with a weak
cipher. It's up to recipient how to decrypt it.
In general, this is an old 1990s thing. The systems that worked well
were the ones that ignored this completely. These days, nobody much
gives that reason even lip service, even if the laws exist.
-- There could be local policies and law enforcements mandating the use
of particular ciphers.
-- I could know out-of-band the recipient is able to use particular
cipher, not announced in sMIMECapabilities due software deficiencies.
Which are made-up complications deriving from the original mistake. Fix
the original mistake, and these go away.
The scenario you describe is just *recommended* scenario for sending
agent, not for a human [RFC3851, sect. 2.7.1."Deciding Which Encryption
Method To Use", - http://tools.ietf.org/html/rfc3851#section-2.7.1].
This scenario describe what the best sending agent can do without human
intervention.
It's completely legal to encrypt the message with any cipher I want.
RFC3851 admits this. Here is a 1st paragraph of sect.2.7.1:
-- <Choosing cipher> involves using information garnered from the
capabilities lists included in messages received from the recipient, as
well as out-of-band information such as private agreements, user
preferences, legal restrictions, and so on.
Yeah. Very sad that they allowed themselves to standardise and lead an
entire generation of unworkable product, making the whole net more or
less insecure.
It could be a great enhancement if Thunderbird could allow to
user-override the automated cipher selection.
It would be hopelessly useless user interface code that would allow a
tiny bunch of people to do something they don't really need to do, and
allow a larger bunch of people to get confused by something they
shouldn't have touched.
Thunderbird is for ordinary people. It should just work. There should
be no modes whatever, it should just spring into encrypted
communications with no fiddling at all.
(The fact that Thunderbird cannot repair all the ills should not be seen
as a reason to stop it migrating in that direction...)
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
