mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: High-priority library replacements?
Date: Fri, 26 Apr 2013 11:47:29 -0400	[thread overview]
Message-ID: <20130426154728.GQ20323@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAOPXC2mtay5vyPUdLbbC3Pp+HQG3WxAH3mtRDZeby2+jfxzVrA@mail.gmail.com>

On Fri, Apr 26, 2013 at 10:11:32AM +0200, Gregor Pintar wrote:
> 2013/4/26, idunham@lavabit.com <idunham@lavabit.com>:
> > I hate to be the one who says this, but...
> > Why another crypto library?
> > There are at least 6 I can think of off the top of my head
> > (openssl crypto, gcrypt, nettle, tomcrypt, gpg, openbgp)
> > and I know that's not even half of them.
> > tomcrypt is already good (as Rich mentioned), so code quality isn't
> > a reason.
> Most of them are realy bad (support only few ciphers, ugly API,
> inflexible, license).
> tomcrypt is good, but it has some global states (ltc_cipher_descriptor, ...)

Yes, this is stupid, but I don't think there's any reason to use it.
Can't you just use the extern descriptor for the cipher you want
directly? In any case, I agree that when using tomcrypt the register
and unregister functions should be nop'd out and the cipher_descriptor
array replaced with a const version thereof. There may be more changes
needed to fix it too, but that sounds like most of it.

> > While writing your own "xyz" may be a good learning experience and fun
> > and so on, a crypto library faces some restrictions:
> > -You will need to fix bugs promptly until you hand over maintainership.
> > (Otherwise, you become responsible when there's a vulnerability that
> > stays unfixed.)
> Not really a problem for me.
> BTW, latest official stable tomcrypt release was released in 2007.

Yes, that's because it's already very mature.. :) BTW, a big plus of
that is that it would be safe to fork tomcrypt and fix any issues in
it that aren't going to get fixed upstream, like global state, since
maintaining a fork of a mature but clean codebase is almost no work.

> > What Rich asked about was an SSL lib based on an existing crypto lib,
> > namely tomcrypt. And that is likely to be a quicker path to results.
> tomcrypt is definitely quicker path.

Note that there's no reason the crypto implementation couldn't later
be replaced if there's an option better than tomcrypt.

Rich


  reply	other threads:[~2013-04-26 15:47 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-25  4:15 Rich Felker
2013-04-25  5:05 ` Daniel Cegiełka
2013-04-25  5:21   ` Rich Felker
2013-04-25  5:55 ` Kurt H Maier
2013-04-25  7:34   ` Jens Staal
2013-04-25 12:18     ` Rich Felker
2013-04-25 13:54     ` Kurt H Maier
2013-04-25  6:43 ` Gregor Pintar
2013-04-26  0:55   ` idunham
2013-04-26  1:11     ` crypto libraries idunham
2013-04-26  7:51       ` Daniel Cegiełka
2013-04-26  1:51     ` High-priority library replacements? Rich Felker
2013-04-26  8:11     ` Gregor Pintar
2013-04-26 15:47       ` Rich Felker [this message]
2013-04-26 17:24         ` Gregor Pintar
2013-04-28 21:43         ` Rob Landley
2013-04-29 10:16       ` Szabolcs Nagy
2013-04-29 12:09         ` Rich Felker
2013-04-29 17:35         ` Gregor Pintar
2013-04-29 21:55           ` Szabolcs Nagy
2013-04-30  2:10             ` Rich Felker
2013-04-30  6:32               ` Gregor Pintar
2013-04-30  8:35                 ` Szabolcs Nagy
2013-04-30  9:58                   ` Gregor Pintar
2013-04-30 11:30                     ` Szabolcs Nagy
2013-04-30 14:11                       ` Gregor Pintar
2013-05-01  7:26                     ` Gregor Pintar
2013-05-08 21:37                       ` Daniel Cegiełka
2013-05-08 23:00                         ` idunham
2013-05-09  7:36                           ` Daniel Cegiełka
2013-05-09  9:03                             ` Daniel Cegiełka
2013-05-09 11:10                             ` LM
2013-05-09 14:08                             ` Rich Felker
2013-05-09 14:40                               ` Daniel Cegiełka
2013-05-09 14:45                                 ` Rich Felker
2013-05-12 22:42                                   ` Brad Conroy
2013-05-15 20:17                                     ` Rich Felker
2013-05-16 16:12                                       ` Justin Cormack
2013-05-17  1:56                                         ` Rich Felker
2013-05-17  7:28                                           ` Justin Cormack
2013-05-09 16:40                                 ` LM
2013-04-30 18:47   ` Nicolas Braud-Santoni
2013-04-30 19:18     ` Gregor Pintar
2013-05-26 20:09   ` Daniel Cegiełka
2013-05-27 15:53     ` Gregor Pintar
2013-05-28  9:27       ` Daniel Cegiełka
2013-05-28 17:30         ` Gregor Pintar
2013-05-28 13:11     ` LM
2013-05-28 21:38       ` Rob Landley
2013-05-31 11:13         ` LM
2013-05-31 11:36           ` LM
2013-04-25  7:21 ` Hal Clark
2013-04-25 10:58   ` Igmar Palsenberg
2013-04-25 12:28   ` Rich Felker
2013-04-25 11:44 ` LM
2013-04-25 12:51   ` Rich Felker
2013-04-25 15:30     ` Jens Staal
2013-04-25 16:51     ` Zvi Gilboa
2013-04-25 16:57       ` Justin Cormack
2013-04-25 17:53         ` Zvi Gilboa
2013-04-27  5:45           ` Rob Landley
2013-04-27  8:13             ` Luca Barbato
2013-04-27 13:05             ` Zvi Gilboa
2013-04-26  6:11       ` Igmar Palsenberg
2013-04-28 21:34         ` Licensing Rob Landley
2013-04-29 20:47           ` Licensing Rich Felker
2013-04-29 21:10             ` Licensing Jens Gustedt
2013-04-29 22:47               ` Licensing Kurt H Maier
2013-04-29 22:50             ` Licensing Rob Landley
2013-04-30 12:32           ` Licensing LM
2013-04-26  4:19 ` High-priority library replacements? Isaac Dunham
2013-04-26 11:41   ` LM
2013-04-26 12:57     ` Muhammad Sumyandityo Noor
2013-04-26 15:53       ` Rich Felker
2013-04-28  6:53         ` Muhammad Sumyandityo Noor
2013-04-28 17:46           ` Rich Felker
2013-04-26 16:52       ` LM
2013-04-26  4:32 ` nwmcsween
2013-04-29  5:51 Brad Conroy
2013-04-29 16:38 ` John Spencer
2013-04-29 20:14   ` Rob Landley
2013-04-29 20:53     ` Rich Felker
2013-04-30  1:53       ` idunham
2013-04-30  2:21         ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130426154728.GQ20323@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).