pdf-devel
[Top][All Lists]
Advanced

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

Re: [pdf-devel] Encryption module page draft


From: jemarch
Subject: Re: [pdf-devel] Encryption module page draft
Date: Sat, 16 Aug 2008 15:09:15 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

   > address@hidden Initializating the module
   > address@hidden Initializating the module
   > +
   > +The encryption module must be initialized when Libgnupdf library was
   > +loaded It is *NOT* safe-thread.
   >
   > What kind of global data will be maintained by the module? All the
   > information related with the ciphers will be stored in the per-cipher
   > data structure, isnt it?
   >

   Indeed. The module will not any data directly, it should be a wrapper
   for `gcry_check_version' libgcrypt's function, which must be called
   before anyother libgcrypt's function.

Ah ok. I forgot that gcrypt needs to hold a global state.


   > address@hidden Encryption and decryption
   > address@hidden Encryption and decryption
   > +
   > address@hidden pdf_status_t pdf_crypt_setkey (pdf_crypt_t @var{cipher}, 
pdf_char_t  @var{*key}, pdf_size_t  @var{length})
   > +
   > +Set the key which will be used to encrypt and decrypt data. This
   > +function should be called each time @code{pdf_crypt_encrypt} or
   > address@hidden are called.
   >
   > Is that restriction really needed?
   >

   Not really, although you must reset the key for each object. It is
   original behavior of libgcrypt.

   Do I remove the restriction?

Well, the restriction introduces a severe coupling between
pdf_crypt_setkey and pdf_crypt_[de|en]crypt, so if it is technically
possible would be good for pdf_crypt_cipher_t to be able to remember
the key, even if the user needs to reset it.

   > BTW, how do we know the size of the de/ciphered text? As far as I
   > understand it the *_crypt_size functions provides information about
   > the minimum buffer space required to hold the de/ciphered text, but
   > not the exact number of bytes.
   >
   I fix it: it is the number of bytes in order to hold the de/ciphered
   text. I said the minimum buffer space because the user could want to
   reserve a greater space.

Ah ok.

Thanks David.




reply via email to

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