From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Hartwig Newsgroups: gmane.lisp.guile.devel Subject: Re: About Guile crypto support Date: Mon, 4 Feb 2013 09:14:56 +0800 Message-ID: References: <1359896146.2754.19.camel@Renee-desktop.suse> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1359942072 31575 80.91.229.3 (4 Feb 2013 01:41:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Feb 2013 01:41:12 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Feb 04 02:41:33 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U2B3r-00044l-7Z for guile-devel@m.gmane.org; Mon, 04 Feb 2013 02:41:31 +0100 Original-Received: from localhost ([::1]:45930 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2B3Y-0006XS-RF for guile-devel@m.gmane.org; Sun, 03 Feb 2013 20:41:12 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:52949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2B3V-0006XL-Kj for guile-devel@gnu.org; Sun, 03 Feb 2013 20:41:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U2B3U-0007co-DC for guile-devel@gnu.org; Sun, 03 Feb 2013 20:41:09 -0500 Original-Received: from mail-ia0-x235.google.com ([2607:f8b0:4001:c02::235]:64040) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2B3U-0007ca-7p for guile-devel@gnu.org; Sun, 03 Feb 2013 20:41:08 -0500 Original-Received: by mail-ia0-f181.google.com with SMTP id k25so7366966iah.40 for ; Sun, 03 Feb 2013 17:41:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=4BUQoP0EA6lIhH3AHqPod8flWWPp5+IBThi17KgxcEk=; b=cQ/0PCz8TUJPxzxzNi5+PQnTln4IjPlBAqHSUAeE+Lw2zOzPx2aTtP//fYaZlxmBEX gO5xfwOkeghLbbB/aWLB4jfJbajNyVKq+oEOh/jWwoT9YSpG+lSQLpw2W9I+O06FTOam LVHABkgJamtIi2PovmeN6fWMdCeg2L2jeWKOnH5iOZrUbE7ztwG/ngh9CDMtu7MOD8AZ 12AalHPh992s387DUfbiqARaLMVzwA/eJau5qWy2UXQ+HR8My5/6Kf+rnKCvAKRkY6Ns a2qUwXea3CCaDChMxqLtwGgLEZwqI5ddNVeeX9pvF6p2Uv9jKjAnA0cr2yBG3Y4Rqd16 a45g== X-Received: by 10.50.187.225 with SMTP id fv1mr3802967igc.96.1359940496300; Sun, 03 Feb 2013 17:14:56 -0800 (PST) Original-Received: by 10.64.76.51 with HTTP; Sun, 3 Feb 2013 17:14:56 -0800 (PST) In-Reply-To: <1359896146.2754.19.camel@Renee-desktop.suse> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c02::235 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:15676 Archived-At: Hello On 3 February 2013 20:55, Nala Ginrut wrote: > As mentioned in another thread about digest algorithm support in Guile, > my plan is use part of implementation of libgcrypt and make a wrapper, > then put into libguile. > But now I found weinholt's Scheme industria lib, which contains all > mainstream crypto(not only digest) algorithm. > http://weinholt.se/industria/manual/crypto.html#crypto As mentioned on that page, there are some issues that apply to any pure Scheme implementation: > Beware that if you're using some of these libraries for sensitive > data, let's say passwords, then there is probably no way to make > sure a password is ever gone from memory. There is no guarantee that > the passwords will not be swapped out to disk or transmitted by > radio. Libgcrypt provides a means to specify that some data should be stored in secured memory, which will never be swapped to disk. Doing something similar in Guile may be problematic, at least with a Scheme-only implementation. > So what's your opinion, guys? > Would you prefer C implementation or Scheme way? As gcrypt is mature, reimplementing it in either C or Scheme just for Guile does not seem useful =E2=80=94 on it's own. An FFI wrapper or extens= ion benefits from upstream security and maintenance efforts. If you have a particular interest in learning about crypto. algorithms, by all means port or write your own implementation using whichever language. If you want it to have a Scheme interface, then Scheme seems a logical choice to use. If your goal is only to provide crypto. support to Guile programs, then time is better spent providing a wrapper to the existing library. Concerns about adding an external dependency do not hold much weight next to the advantages of directly using the library; =E2=80=9Cdon't repeat yourself=E2=80=9D, and all that. Perhaps you are aware that there an extension for gcrypt under development, with modules for the hash and randomize functions: . Regards