Nabble - GnuPG

which MPI calculations allow the output argument to be identical to the the input arguments?

2009-11-28T21:13:45Z

Hi GCrypt folks--

The patch below adjusts a comment about MPI arithmetic to make more
sense (it doesn't mean anything to suggest that an unsigned long might
be the same as an MPI object, right?)

Is there a general agreement that gcrypt MPI calculation functions allow
their target value (w) to be the same as any of their other arguments?
are there certain calculation operations where that does not hold?

This would be useful information to include in the header of the
Calculations section of gcrypt.texi.

--dkg

Index: mpi-add.c
===================================================================
--- mpi-add.c (revision 1406)
+++ mpi-add.c (working copy)
@@ -33,7 +33,7 @@

/****************
* Add the unsigned integer V to the mpi-integer U and store the
- * result in W. U and V may be the same.
+ * result in W. U and W may be the same.
*/
void
gcry_mpi_add_ui(gcry_mpi_t w, gcry_mpi_t u, unsigned long v )

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@...
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

signature.asc (909 bytes) Download Attachment

From forum: GnuPG - Libgcrypt - Dev

should HMAC digests require secure memory?

2009-11-28T20:33:43Z

Hi gcrypt folks--

it looks to me like cipher/md.c:487 effectively requires secure memory
for HMAC-enabled digest objects, whether or not GCRY_MD_FLAG_SECURE was set.

This is a surprising behavior, since (at least in versions before
1.4.3), it can lead to an "Ohhhh jeeee: operation is not possible
without initialized secure memory" error message, followed by the
process being aborted.

Since version 1.4.3 (according to NEWS) this appears to be worked around
by auto-allocating 32K secure memory if the library isn't otherwise
initialized.

I note that in the older gcrypt versions vulnerable to this failure, an
explicit call to gcry_control(GCRYCTL_DISABLE_SECMEM) before creating
the HMAC-enabled will avoid the failure.

I wonder if modern libraries are still subject to this failure if
they're run by users unable to allocate secure memory (and thus the
default allocation of 32K of secmem would fail). i don't have such a
system handy to try.

Why are ctx->maxpads allocated securely, even if GCRY_MD_FLAG_SECURE is
not set?

It seems to me like this should be normalized in one of the following ways:

0) documentation for gcry_md_open should note that secure memory is
used when GCRY_MD_FLAG_HMAC is used, regardless of GCRY_MD_FLAG_SECURE.

1) allocation of ctx->maxpads in md_open() should allocate secure or
normal memory based on the "secure" argument to that function.

Are there other ways this behavior could be made less surprising?

Regards,

--dkg

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@...
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

signature.asc (909 bytes) Download Attachment

From forum: GnuPG - Libgcrypt - Dev

Re: GnuPG private key resilience against off-line brute-force attacks (was: Re: Backup of private key)

2009-11-28T17:33:58Z

* "Ciprian Dorin, Craciun" <ciprian.craciun@...> wrote:

> Thank you for the quick reply. (This is the kind of answer I was
> hopping to get. :) ) It seems that `s2k-count` escaped me. :)
>
> Maybe there should be an entry in the FAQ about this topic.

Well, other projects make good use of that option, f.e. loop-AES,
have a look at section 5 of

http://loop-aes.sourceforge.net/loop-AES.README

--
left blank, right bald

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

attachment0 (205 bytes) Download Attachment

Nabble - GnuPG

which MPI calculations allow the output argument to be identical to the the input arguments?

should HMAC digests require secure memory?

Re: GnuPG private key resilience against off-line brute-force attacks (was: Re: Backup of private key)

gnutls-2.8.5 failure on OpenSolaris

Re: gnutls-2.2.1 fails to build on HP-UX

gnutls failure on Solaris 10 update 7 gcc 4.4.1

Re: GnuPG private key resilience against off-line brute-force attacks (was: Re: Backup of private key)

Re: GnuPG private key resilience against off-line brute-force attacks (was: Re: Backup of private key)

Re: GnuPG private key resilience against off-line brute-force attacks (was: Re: Backup of private key)

Re: GnuPG private key resilience against off-line brute-force attacks (was: Re: Backup of private key)

Re: GnuPG private key resilience against off-line brute-force attacks (was: Re: Backup of private key)

Re: GnuPG private key resilience against off-line brute-force attacks (was: Re: Backup of private key)

Re: GnuPG private key resilience against off-line brute-force attacks (was: Re: Backup of private key)

Re: GnuPG private key resilience against off-line brute-force attacks (was: Re: Backup of private key)

Re: GnuPG private key resilience against off-line brute-force attacks (was: Re: Backup of private key)

Re: GnuPG private key resilience against off-line brute-force attacks (was: Re: Backup of private key)

Re: GnuPG private key resilience against off-line brute-force attacks (was: Re: Backup of private key)

Re: GnuPG private key resilience against off-line brute-force attacks (was: Re: Backup of private key)

Re: Backup of private key

Re: GnuPG private key resilience against off-line brute-force attacks (was: Re: Backup of private key)

Re: GnuPG private key resilience against off-line brute-force attacks (was: Re: Backup of private key)

GnuPG private key resilience against off-line brute-force attacks (was: Re: Backup of private key)

Re: Backup of private key

Re: Backup of private key

Re: Help required for CSR validation

Re: claws mail will not verify signatures

Re: Help required for CSR validation

Re: SCM dicussion (Re: Where is >libassuan-1.1.0)

Re: Piotr Bratkowski

Re: gpg trust from command line

Re: gpg trust from command line

gpg trust from command line

SCM dicussion (Re: Where is >libassuan-1.1.0)

Re: gnutls-2.2.1 fails to build on HP-UX

Re: Fwd: Backup of private key