pdf-devel
[Top][All Lists]
Advanced

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

Re: [pdf-devel] Crypt module discussion


From: David Vazquez
Subject: Re: [pdf-devel] Crypt module discussion
Date: Thu, 31 Jul 2008 02:20:24 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Hello jemarch,

>       /* Initialize module */
>       pdf_status_t pdf_crypt_init (void);
>
> Please remember in this point that, since the library should be
> thread-safe, you cannot maintain any global state.
>

However libgcrypt requires initialization. It must be called once at
startup. I will read the multithreading section from libgcrypt
reference.


>       /* Create a new cipher */
>       pdf_crypt_t pdf_crypt_new (int method);
>
> Our current convention is to always return a pdf_status_t value in
> pdf_*_new functions, such as:
>
>  pdf_status_t pdf_crypt_new (int method, pdf_crypt_t *crypt);
>

Ok, sorry. I took a look to pdf-text module reference and it doesn't
follow this convention:

   pdf_text_t pdf_text_new (void)

I suppose we should fix it.


>       /* Set initialization vector (Only for AESV2) */
>       pdf_status_t pdf_crypt_setiv  (pdf_crypt_t cipher, const void * key, 
> size_t size);
>
> I agree with Ralph in that we can assume that the initialization
> vector will be contained in the beginning of the buffer when calling
> 'pdf_crypt_encrypt' or 'pdf_crypt_decrypt'.
>

Ok, though I don't like it :), but it is true that it simplifies the
caller. So both V2 as AESV2 are equally dealt. Then the output buffer
should contain IV in the beginning too in order to we can decrypt it.


>       /* Encrypt and decrypt buffers. This functions allow in-place 
> encryption too */
>       pdf_status_t pdf_crypt_encrypt (pdf_crypt_t cipher, void *outf,
>       size_t outsize, const void *in, size_t insize);
>
>       pdf_status_t pdf_crypt_decrypt (pdf_crypt_t cipher, void *out,
>       size_t outsize, const void *in, size_t insize);
>
> For these functions maybe would be good to return the number of bytes
> actually generated by the operation. Something like:
>
>  pdf_size_t pdf_crypt_encrypt (pdf_crypt_t cipher, 
>                                pdf_char_t *in,
>                                pdf_size_t in_size,
>                                pdf_char_t *out,
>                                pdf_size_t bytes);
>
> where BYTES is the number of bytes we want to generate. I dont know if
> that is feasible with the block-oriented cypher.
>

I do not think it. Take a look to the return value of the following
libgcrypt function:

gcry_error_t gcry_cipher_encrypt (gcry_cipher_hd_t H,
                                  unsigned char *out,
                                  size_t OUTSIZE,
                                  const unsigned char *IN,
                                  size_t INLEN)

By the way, I think OUTSIZE argument is redundant. We can determine it
for both methods. Is there any form We take advantage of this?

Greetings




reply via email to

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