[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Cryptography

From: Robert Millan
Subject: Re: [PATCH] Cryptography
Date: Mon, 16 Nov 2009 20:59:06 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Mon, Nov 16, 2009 at 08:38:54PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> Robert Millan wrote:
> > On Mon, Nov 16, 2009 at 03:56:26PM +0100, Vladimir 'phcoder' Serbinenko 
> > wrote:
> >   
> >> 2) Adaptation to the lack of gnulib abstraction layer on top of gcrypt
> >>     
> >
> > It seems that the usual way of importing gc-pbkdf2-sha1.c is by linking it
> > with gc-gnulib.c or gc-libgcrypt.c.  Is this option problematic?
> >
> >   
> libgcrypt is done like this:
> libgcrypt API ----> Common cryptographic algorithms layer (for some
> algorithms it's quite a passthrough) --->  ciphers
> Although we use ciphers from libgcrypt, our middle layer is much simpler
> and lacks per-cipher integer IDs. Because of it using gc-libgcrypt.c
> would require an additional level of wrapping and it's much easier to
> just modify few lines in PBKDF2

Ok.  Then in principle we wouldn't contemplate resyncing this file, right?

What version of libgcrypt should be imported?

Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]