Re: [Caml-list] OcamlSpread 0.0.1 released

["Arnaud SAHUGUET" <sahuguet@lucent.com>]

When choosing a crypto package, there are a few points to consider:

- the people who implement the package
(Good) crypto algorithms are usually secure on paper. But when translated in
code, this is not always the case.

- the range of algorithms supported
Actually this is not so critical because most protocol start with a
negociation phase.

- the maintenance of the package
Flaws are being discovered everyday. It is better to use a crypto package
which is widely used, tested and maintained.

- the license

openSSL seems to be a really good contender. Sun announced yesterday that it
is donated its Elliptic Curve crypto implementation (ECC)  to the project.
That's really for embedded devices because ECC offers the same level of
security with much smaller key size.

I think the last and worst thing to do is to re-implement some crypto from
scratch.

regards,

Arnaud

----- Original Message -----
From: "Xavier Leroy" <xavier.leroy@inria.fr>
To: "Yurii A. Rashkovskii" <yrashk@openeas.org>
Cc: "Ohad Rodeh" <ORODEH@il.ibm.com>; <caml-list@inria.fr>
Sent: Friday, September 20, 2002 9:15 AM
Subject: Re: [Caml-list] OcamlSpread 0.0.1 released


> > The question is not a speed, but strength of the algorithms. I think
> > that Ensemble *should* have storng algorithms for security or
> > pluggable interface to switch in OpenSSL, cryptokit or whatsoever.
>
> As Ohad said, OpenSSL offers more ciphers than my Cryptokit, and some
> of them probably run faster in OpenSSL, but still the ciphers and
> hashes supported by Cryptokit are entirely standard (AES, Triple DES,
> RC4, RSA, etc) and have no known cryptographic weaknesses -- provided
> adequate key sizes are selected, of course.
>
> Security holes are much more likely to arise as a consequence of
> incorrect use of these algorithms, e.g. at the cryptographic protocol
> level, than as a consequence of a weakness of the algorithms
> themselves.
>
> - Xavier Leroy
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives:
http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners