[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."
Re: [PATCH] Cryptography, Felix Zielcke, 2009/11/16
Re: [PATCH] Cryptography, Robert Millan, 2009/11/17