From aterik at outlook.com  Sat Sep  2 18:52:12 2017
From: aterik at outlook.com (TErik Ashfolk)
Date: Sat, 2 Sep 2017 16:52:12 +0000
Subject: libgcrypt 1.8.1 Build Fails, macOS 10.12.6
Message-ID: <CO1PR20MB0856075B87DED9A4154D1163DC930@CO1PR20MB0856.namprd20.prod.outlook.com>

Hi.

libgcrypt 1.8.1 build/compile fails in macOS 10.12.6 Sierra MBA.
libgcrypt 1.8.0 was built fine in same machine.

(sorry, i posted this message also in gnupg-devel, but gcrypt-devel is more appropriate for libgcrypt dev discussion, and i added more info in this message. Gnupg-devel can discuss what is appropriate there or ignore/delete that mesg/post. Thanks).

The "./configure" stage succeeds.
But in "make", warning appears for global.c & gcrypt-testapi.h: case value not in enumerated type 'enum gcry_ctl_cmds'... And ERROR appears for /usr/local/include/pthread.h:286:42: typedef redefinition with different types ('struct?pthread_attr_st *' vs '_darwin_pthread_attr_t' ...

Neither "./configire --disable-threads" or "./configure --enable-threads=no" worked/recognized ! :(?

Pth (gnu pthread) native/local builds ok. nPth does not.
And it seems, after i re-build Pth, then other src (which needs it) succeeds in build, otherwise not, (So maybe something often replacing Pth libs?!)

Loaded Pth, nPth using MacPorts, but seems to have no affect. (i avoid using HomeBrew for their data-sharing anti privacy policies). This machine has homebrew, but nothing installed thru it, (i have uninstalled/removed all brew-formulas, as i use their equivalent from MacPorts).

If i load the build related Env Vars (LD_LIBRARY_PATH, DYLD_LIBRARY_PATH, LDFLAGS, PKG_CONFIG_PATH, CPPFLAGS, CFLAGS) which have dir locations of MacPorts & other libs, build-tools (Xcode, Qt, Python, JavaJDK, Android-SDK, etc), etc, then build does not succeed often, so i kept build related Env Vars empty, but compile/build tools seems to be still able to locate their necessary libs/headers without specifying build Env Vars.  btw, only the PATH & a local OPENSSL's env vars are declared, for each bash session.

and, btw, MacPorts' lib/include directories/dirs are different than native local build's lib include dirs.  in env-vars, macports related dirs appears, after local dirs, (and i did not need to use build related env vars for building older gnupg & deps).

afair, i attempt to build in these sequence: libgpg-error, libassuan, nPth/Pth, libksba, libgcrypt, ntbtls, gpgme, gnupg.  (Please SHOW a tree-structure in gnupg.org, displaying, which deps on what, so that users can start build from last/lowest right-most dependency branch/src/lib item  to their left/top item,  & ultimately to the top/root item "gnupg").

gnupg-2.1.23 build succeeded ok, on same 10.12.6 Sierra, mba machine.

let me know if/which info needed.

thanks in advance.
Erik.

From andre at amorim.me  Sun Sep  3 09:34:26 2017
From: andre at amorim.me (Andre Amorim)
Date: Sun, 3 Sep 2017 08:34:26 +0100
Subject: [git] GCRYPT - branch, master,
 updated. libgcrypt-1.8.1-14-ge4dc458
In-Reply-To: <87shgaix5f.fsf@wheatstone.g10code.de>
References: <E1dmaib-0006TZ-6L@lists.gnupg.org>
 <87shgaix5f.fsf@wheatstone.g10code.de>
Message-ID: <CAB2_bFrHYhhoO_YTE-aptANsHQP9yOMPsjvaHK9Zpjuk2XC1bw@mail.gmail.com>

Indeed,

Sometimes those compilers reminds me Turning/Von Neumann primitives
and  machinery architecture, and whatnot
MIT AI https://www.csail.mit.edu/user/888

,
Andre
--


On 29 August 2017 at 09:41, Werner Koch <wk at gnupg.org> wrote:
> On Tue, 29 Aug 2017 09:13, cvs at cvs.gnupg.org said:
>> -      l2 = gcry_sexp_find_token (l1, "pqg"+idx, 1);
>> +      l2 = gcry_sexp_find_token (l1, &"pqg"[idx], 1);
>
> Oh dear, some compiler warnings are annoying and make the code harder to
> read.  At least for those of us who learned C from K&R.
>
>
> SCNR,
>
>    Werner
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
>


From w.k at berkeley.edu  Thu Sep 21 08:23:53 2017
From: w.k at berkeley.edu (Weikeng Chen)
Date: Wed, 20 Sep 2017 23:23:53 -0700
Subject: question on ElGamal implementation
Message-ID: <CAHr+ZK8ZU16uA6hvoTLGqB6UtFQj24Pgf+7wZ4eZi3=zm9AcyQ@mail.gmail.com>

Dear All,

I am not sure about whether libGCrypt uses the correct multiplicative
group for ElGamal to ensure the underlying cryptographic guarantee --
DDH assumption -- holds.

I cannot find details in the source code that libGCrypt uses such a
subgroup -- this seems not the best practice. I would like to raise
this as an issue to discuss -- whether it is really using a secure
subgroup for ElGamal.

The group for ElGamal. In non-curve case, we use a multiplicative
group with modulus $p$, where $p$ is a safe prime.

In cipher/primegen.c, the function _gcry_generate_elg_prime calls
prime_generate_internal to generate a safe prime group, and also the
generator.

It seems to return the generator for the multiplicative group with
modulus $p$, not a special subgroup -- while the DDH assumption only
holds in this subgroup.

In the Wikipedia
(https://en.wikipedia.org/wiki/Decisional_Diffie%E2%80%93Hellman_assumption),
it said that DDH assumption does not hold for this group.

But DDH assumption is crucial for the semantic security of the ElGamal
algorithm. If we are using a generator for group modulus $p$, it is
not strongly secure.

Professor Dan Boneh from Stanford University said this in his paper
"The decision Diffie-Hellman problem" in Section 4.1
(http://crypto.stanford.edu/~dabo/abstracts/DDH.html):

       When $g$ is a generator of $Z_p^*$ the system is not semantically secure.

while semantical security is the foundation of security encryption schemes.


The general treatment. Instead of letting $g$ be the generator of
$Z_p^*$, we let $g$ becomes the generator of a subgroup of $Z_p^*$.
This subgroup has the prime order.

In prime_generate_internal, the prime $p$ is given as $p=2(q f_1 f_2
... f_n) + 1$, where $q$ as the prime with a sufficient size.

If we have a generator $g_0$ in $Z_p^*$, we can have
$g=(g_0)^{(p-1)/q_f}$ which is the generator of a prime group. In this
group, DDH assumption is believed to hold.


Cannot find relevant code in libGCrypt. In cipher/elgamal.c, we have
the key generation function generate, which uses the generator $g$
directly from _gcry_generate_elg_prime. This function is defined in
cipher/primegen.c. This function directly calls
prime_generate_internal, which is in the same file.

Before Ln 624, the code of prime_generate_internal, it is about
finding a safe prime and returns its factors (this is helpful because
finding the generator/primitive root becomes probabilistic
polynomial-time). Starting Ln 629, we start to test the candidate
generator. It seems that we are finding the primitive root of the
group modulus $p$, not the subgroup.


My question. Many open-source implementations of ElGamal do not jump
to this subgroup. But DDH assumption holds only in these subgroups.

1. [Correctness of my code reading] Is it due to my misunderstanding
of the code and I made it wrong -- that libGCrypt is surely finding
the good generator for that subgroup?

2. [Should we improve?] Why not prefer a better generator?


Thanks a lot for reading!

Sincerely,
Weikeng

-- 

Weikeng Chen @ 795 Soda Hall


From w.k at berkeley.edu  Thu Sep 21 08:04:01 2017
From: w.k at berkeley.edu (Weikeng Chen)
Date: Wed, 20 Sep 2017 23:04:01 -0700
Subject: question on ElGamal implementation
Message-ID: <CAHr+ZK9cxWDdroEDGddcEEzz40JwyVJrjg4_pznmXPMXiZvfrg@mail.gmail.com>

Dear All,

I am not sure about whether libGCrypt uses the correct multiplicative group
for ElGamal to ensure the underlying cryptographic guarantee -- DDH
assumption -- holds.

I cannot find details in the source code that libGCrypt uses such a
subgroup -- this seems not the best practice. I would like to raise this as
an issue to discuss -- whether it is really using a secure subgroup for
ElGamal.

*The group for ElGamal. *In non-curve case, we use a multiplicative group
with modulus $p$, where $p$ is a safe prime.

In cipher/primegen.c, the function _gcry_generate_elg_prime calls
prime_generate_internal to generate a safe prime group, and also the
generator.

It seems to return the generator for the multiplicative group with modulus
$p$, not a special subgroup -- while the DDH assumption only holds in this
subgroup.

In the Wikipedia (https://en.wikipedia.org/wiki
/Decisional_Diffie%E2%80%93Hellman_assumption), it said that DDH assumption
does not hold for this group.

But DDH assumption is crucial for the semantic security of the ElGamal
algorithm. If we are using a generator for group modulus $p$, it is not
strongly secure.

Professor Dan Boneh from Stanford University said this in his paper "The
decision Diffie-Hellman problem" in Section 4.1 (
http://crypto.stanford.edu/~dabo/abstracts/DDH.html):


*When $g$ is a generator of $Z_p^*$ the system is not semantically secure. *

while semantical security is the foundation of security encryption schemes.


*The general treatment. *Instead of letting $g$ be the generator of $Z_p^*$,
we let $g$ becomes the generator of a subgroup of $Z_p^*$. This subgroup
has the prime order.

In prime_generate_internal, the prime $p$ is given as $p=2(q f_1 f_2 ...
f_n) + 1$, where $q$ as the prime with a sufficient size.

If we have a generator $g_0$ in $Z_p^*$, we can have
$g=(g_0)^{(p-1)/q_f}$ which
is the generator of a prime group. In this group, DDH assumption is
believed to hold.


*Cannot find relevant code in libGCrypt.* In cipher/elgamal.c, we have the
key generation function generate, which uses the generator $g$ directly
from _gcry_generate_elg_prime. This function is defined in cipher/primegen.c.
This function directly calls prime_generate_internal, which is in the same
file.

Before Ln 624, the code of prime_generate_internal, it is about finding a
safe prime and returns its factors (this is helpful because finding the
generator/primitive root becomes probabilistic polynomial-time). Starting
Ln 629, we start to test the candidate generator. It seems that we are
finding the primitive root of the group modulus $p$, not the subgroup.


*My question. *Many open-source implementations of ElGamal do not jump to
this subgroup. But DDH assumption holds only in these subgroups.

*1. [Correctness of my code reading]* Is it due to my misunderstanding of
the code and I made it wrong -- that libGCrypt is surely finding the good
generator for that subgroup?

*2. [Should we improve?]* Why not prefer a better generator?


Thanks a lot for reading!

Sincerely,
Weikeng

-- 

Weikeng Chen @ 795 Soda Hall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170920/a2542cc4/attachment.html>

From gniibe at fsij.org  Fri Sep 22 03:36:59 2017
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 22 Sep 2017 10:36:59 +0900
Subject: question on ElGamal implementation
In-Reply-To: <CAHr+ZK8ZU16uA6hvoTLGqB6UtFQj24Pgf+7wZ4eZi3=zm9AcyQ@mail.gmail.com>
References: <CAHr+ZK8ZU16uA6hvoTLGqB6UtFQj24Pgf+7wZ4eZi3=zm9AcyQ@mail.gmail.com>
Message-ID: <87bmm3zf7o.fsf@iwagami.gniibe.org>

Weikeng Chen <w.k at berkeley.edu> wrote:
> I cannot find details in the source code that libGCrypt uses such a
> subgroup -- this seems not the best practice. I would like to raise
> this as an issue to discuss -- whether it is really using a secure
> subgroup for ElGamal.
[...]
> 1. [Correctness of my code reading] Is it due to my misunderstanding
> of the code and I made it wrong -- that libGCrypt is surely finding
> the good generator for that subgroup?

I think that your reading is correct.  In particular:

    Starting Ln 629, ... we are finding the primitive root of the group
    modulus $p$, not the subgroup.

This is correct.  (And... you can also test with running code, if
needed.)

> 2. [Should we improve?] Why not prefer a better generator?

I think that it's good thing that the generator 'g' computed by
_gcry_generate_elg_prime will be the one of the subgroup (instead of the
one of multiplicative group of integers modulo p).
(Provided it is not patented.)

On the other hand, I don't think it is required, because "plaintext" to
be encrypted is usually random; It is used in a hybrid cryptosystem.
-- 


From w.k at berkeley.edu  Fri Sep 22 10:09:26 2017
From: w.k at berkeley.edu (Weikeng Chen)
Date: Fri, 22 Sep 2017 01:09:26 -0700
Subject: Fwd: question on ElGamal implementation
In-Reply-To: <CAHr+ZK8DzGmqDV6v6zMiij0wqeGpJp0Q24SCyq3dmbtgooKWow@mail.gmail.com>
References: <CAHr+ZK8ZU16uA6hvoTLGqB6UtFQj24Pgf+7wZ4eZi3=zm9AcyQ@mail.gmail.com>
 <87bmm3zf7o.fsf@iwagami.gniibe.org>
 <CAHr+ZK8DzGmqDV6v6zMiij0wqeGpJp0Q24SCyq3dmbtgooKWow@mail.gmail.com>
Message-ID: <CAHr+ZK9Jca7Sx_ectJfnxdCsJNnSKFfQ8OYkmBjbNcR-hYebyw@mail.gmail.com>

---------- Forwarded message ----------
From: Weikeng Chen <w.k at berkeley.edu>
Date: Thu, Sep 21, 2017 at 6:50 PM
Subject: Re: question on ElGamal implementation
To: NIIBE Yutaka <gniibe at fsij.org>


You are right. If it is for hybrid encryption, the actual message is
confidential, the message in ElGamal encryption is just a key, then
semantic security is not that crucial -- the security can be proved by
the semantic security of the symmetric part.

It seems that only when people use ElGamal for homomorphic encryption
(computing on encrypted data), where actual data stay in the message
space, then a strong security is demanded.

-- 

Weikeng Chen @ 795 Soda Hall


From r030t1 at gmail.com  Thu Sep 28 07:42:00 2017
From: r030t1 at gmail.com (R0b0t1)
Date: Thu, 28 Sep 2017 00:42:00 -0500
Subject: Extremely Slow Ed25519 Key Generation (Entropy Source?)
In-Reply-To: <CAAD4mYhsNWSL1OEYfW9_75LehcVm696F35_JezS0_av4mHRdsg@mail.gmail.com>
References: <CAAD4mYhsNWSL1OEYfW9_75LehcVm696F35_JezS0_av4mHRdsg@mail.gmail.com>
Message-ID: <CAAD4mYioCYh6QeorxwLwjJL-rw+2FXHzFOh4v1SKZFC+AsHfnw@mail.gmail.com>

On Thu, Sep 28, 2017 at 12:36 AM, R0b0t1 <r030t1 at gmail.com> wrote:
> Hello,
>
> As a test, generating 1000 Ed25519 keys took 53 minutes on an AMLogic
> S905. Generating 1000 keys with libcrypto is almost instantaneous.
>
> Is this due to something I have missed, such as entropy source
> selection? I tried reading the documentation but found nothing
> relevant.
>

It does seem that key generation slows appreciably after exhausting
the entropy pool. Is there a way to set the entropy source for
internal libgcrypt operations?

Respectfully,
     R0b0t1


From r030t1 at gmail.com  Thu Sep 28 07:36:19 2017
From: r030t1 at gmail.com (R0b0t1)
Date: Thu, 28 Sep 2017 00:36:19 -0500
Subject: Extremely Slow Ed25519 Key Generation (Entropy Source?)
Message-ID: <CAAD4mYhsNWSL1OEYfW9_75LehcVm696F35_JezS0_av4mHRdsg@mail.gmail.com>

Hello,

As a test, generating 1000 Ed25519 keys took 53 minutes on an AMLogic
S905. Generating 1000 keys with libcrypto is almost instantaneous.

Is this due to something I have missed, such as entropy source
selection? I tried reading the documentation but found nothing
relevant.

Respectfully,
     R0b0t1


From wk at gnupg.org  Thu Sep 28 14:26:26 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 28 Sep 2017 14:26:26 +0200
Subject: Extremely Slow Ed25519 Key Generation (Entropy Source?)
In-Reply-To: <CAAD4mYioCYh6QeorxwLwjJL-rw+2FXHzFOh4v1SKZFC+AsHfnw@mail.gmail.com>
 (R0b0t1's message of "Thu, 28 Sep 2017 00:42:00 -0500")
References: <CAAD4mYhsNWSL1OEYfW9_75LehcVm696F35_JezS0_av4mHRdsg@mail.gmail.com>
 <CAAD4mYioCYh6QeorxwLwjJL-rw+2FXHzFOh4v1SKZFC+AsHfnw@mail.gmail.com>
Message-ID: <87y3oz1025.fsf@wheatstone.g10code.de>

On Thu, 28 Sep 2017 07:42, r030t1 at gmail.com said:

> It does seem that key generation slows appreciably after exhausting
> the entropy pool. Is there a way to set the entropy source for
> internal libgcrypt operations?

Put this into /etc/gcrypt/random.conf

--8<---------------cut here---------------start------------->8---
# Options for the random generator

# If you don't want the Jitter based thing you may disable it,
#disable-jent

# Only use /dev/urandom
only-urandom
--8<---------------cut here---------------end--------------->8---

That is in general okay because on modern kernels we anyway use the
getrandom call and thus we are eben safe at boot time.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170928/a85d148e/attachment-0001.sig>

From r030t1 at gmail.com  Thu Sep 28 16:07:04 2017
From: r030t1 at gmail.com (R0b0t1)
Date: Thu, 28 Sep 2017 09:07:04 -0500
Subject: Extremely Slow Ed25519 Key Generation (Entropy Source?)
In-Reply-To: <87y3oz1025.fsf@wheatstone.g10code.de>
References: <CAAD4mYhsNWSL1OEYfW9_75LehcVm696F35_JezS0_av4mHRdsg@mail.gmail.com>
 <CAAD4mYioCYh6QeorxwLwjJL-rw+2FXHzFOh4v1SKZFC+AsHfnw@mail.gmail.com>
 <87y3oz1025.fsf@wheatstone.g10code.de>
Message-ID: <CAAD4mYhzLNyYBUDeopQONpJ17=Wjwq+NQ5w0NdgX7eRiLH0e+Q@mail.gmail.com>

On Thu, Sep 28, 2017 at 7:26 AM, Werner Koch <wk at gnupg.org> wrote:
> On Thu, 28 Sep 2017 07:42, r030t1 at gmail.com said:
>
>> It does seem that key generation slows appreciably after exhausting
>> the entropy pool. Is there a way to set the entropy source for
>> internal libgcrypt operations?
>
> Put this into /etc/gcrypt/random.conf
>

Is there no way to change this setting in a non-global manner?

Cheers,
     R0b0t1


From chris at chatsecure.org  Fri Sep 29 21:00:18 2017
From: chris at chatsecure.org (Chris Ballinger)
Date: Fri, 29 Sep 2017 12:00:18 -0700
Subject: libgcrypt fails to compile with Xcode 9 against iOS 11 SDK
Message-ID: <CAG7SQq6isPfbSX=VA50tDS-x20rWv7Bz6wF8s4-7H-PNLMH8sQ@mail.gmail.com>

This affects 1.7.x (and probably lower) through 1.8.1. The issue is that
calling 'system()' is not allowed on iOS and is a now compile error with
the latest Xcode 9 / iOS 11 toolchain.

For now I will just comment out the system() calls, but I'll submit a
better ifdef patch when I get around to it.


random.c:556:11: error: 'system' is unavailable: not available on iOS

      if (system (cmdline))

          ^

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator11.0.sdk/usr/include/stdlib.h:195:6:
note:

      'system' has been explicitly marked unavailable here

int      system(const char *) __DARWIN_ALIAS_C(system);

         ^
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170929/a04fab3e/attachment.html>

From chris at chatsecure.org  Fri Sep 29 22:44:42 2017
From: chris at chatsecure.org (Chris Ballinger)
Date: Fri, 29 Sep 2017 13:44:42 -0700
Subject: libgcrypt fails to compile with Xcode 9 against iOS 11 SDK
In-Reply-To: <CAG7SQq6isPfbSX=VA50tDS-x20rWv7Bz6wF8s4-7H-PNLMH8sQ@mail.gmail.com>
References: <CAG7SQq6isPfbSX=VA50tDS-x20rWv7Bz6wF8s4-7H-PNLMH8sQ@mail.gmail.com>
Message-ID: <CAG7SQq6As72-kkA=0DAM23t7efXsxHgyHtschoUw=P+UZv5Kow@mail.gmail.com>

An additional problem I found in v1.8.1 with Xcode 9. The
mpih-add1-asm.S asm fails to compile for arm64. Reverting to 1.7.9 also
does not fix the issue.

mpih-add1-asm.S:37:1: error: unknown directive
.type _gcry_mpih_add_n,%function
^
mpih-add1-asm.S:71:1: error: unknown directive
.size _gcry_mpih_add_n,.-_gcry_mpih_add_n;
^


On Fri, Sep 29, 2017 at 12:00 PM, Chris Ballinger <chris at chatsecure.org>
wrote:

> This affects 1.7.x (and probably lower) through 1.8.1. The issue is that
> calling 'system()' is not allowed on iOS and is a now compile error with
> the latest Xcode 9 / iOS 11 toolchain.
>
> For now I will just comment out the system() calls, but I'll submit a
> better ifdef patch when I get around to it.
>
>
> random.c:556:11: error: 'system' is unavailable: not available on iOS
>
>       if (system (cmdline))
>
>           ^
>
> /Applications/Xcode.app/Contents/Developer/Platforms/
> iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator11.0.sdk/usr/include/stdlib.h:195:6:
> note:
>
>       'system' has been explicitly marked unavailable here
>
> int      system(const char *) __DARWIN_ALIAS_C(system);
>
>          ^
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170929/434c8a32/attachment.html>

From chrisballinger at gmail.com  Sat Sep 30 21:57:22 2017
From: chrisballinger at gmail.com (Chris Ballinger)
Date: Sat, 30 Sep 2017 12:57:22 -0700
Subject: Fwd: libgcrypt fails to compile with Xcode 9 against iOS 11 SDK
In-Reply-To: <CAG7SQq6As72-kkA=0DAM23t7efXsxHgyHtschoUw=P+UZv5Kow@mail.gmail.com>
References: <CAG7SQq6isPfbSX=VA50tDS-x20rWv7Bz6wF8s4-7H-PNLMH8sQ@mail.gmail.com>
 <CAG7SQq6As72-kkA=0DAM23t7efXsxHgyHtschoUw=P+UZv5Kow@mail.gmail.com>
Message-ID: <CAG7SQq7GzgH5UuAX9D3kVgqQmHFc3OtpCpbD_8=tnto1Xcaz7A@mail.gmail.com>

Resending due to DMARC failure...

---------- Forwarded message ----------
From: Chris Ballinger <chris at chatsecure.org>
Date: Fri, Sep 29, 2017 at 1:44 PM
Subject: Re: libgcrypt fails to compile with Xcode 9 against iOS 11 SDK
To: gcrypt-devel <gcrypt-devel at gnupg.org>


An additional problem I found in v1.8.1 with Xcode 9. The
mpih-add1-asm.S asm fails to compile for arm64. Reverting to 1.7.9 also
does not fix the issue.

mpih-add1-asm.S:37:1: error: unknown directive
.type _gcry_mpih_add_n,%function
^
mpih-add1-asm.S:71:1: error: unknown directive
.size _gcry_mpih_add_n,.-_gcry_mpih_add_n;
^


On Fri, Sep 29, 2017 at 12:00 PM, Chris Ballinger <chris at chatsecure.org>
wrote:

> This affects 1.7.x (and probably lower) through 1.8.1. The issue is that
> calling 'system()' is not allowed on iOS and is a now compile error with
> the latest Xcode 9 / iOS 11 toolchain.
>
> For now I will just comment out the system() calls, but I'll submit a
> better ifdef patch when I get around to it.
>
>
> random.c:556:11: error: 'system' is unavailable: not available on iOS
>
>       if (system (cmdline))
>
>           ^
>
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneS
> imulator.platform/Developer/SDKs/iPhoneSimulator11.0.sdk/usr/include/stdlib.h:195:6:
> note:
>
>       'system' has been explicitly marked unavailable here
>
> int      system(const char *) __DARWIN_ALIAS_C(system);
>
>          ^
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170930/aef4751a/attachment.html>

From dkg at fifthhorseman.net  Sat Sep 30 21:55:16 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sat, 30 Sep 2017 15:55:16 -0400
Subject: Extremely Slow Ed25519 Key Generation (Entropy Source?)
In-Reply-To: <87y3oz1025.fsf@wheatstone.g10code.de>
References: <CAAD4mYhsNWSL1OEYfW9_75LehcVm696F35_JezS0_av4mHRdsg@mail.gmail.com>
 <CAAD4mYioCYh6QeorxwLwjJL-rw+2FXHzFOh4v1SKZFC+AsHfnw@mail.gmail.com>
 <87y3oz1025.fsf@wheatstone.g10code.de>
Message-ID: <8760c0otaz.fsf@fifthhorseman.net>

On Thu 2017-09-28 14:26:26 +0200, Werner Koch wrote:
> Put this into /etc/gcrypt/random.conf
 [?]
> # Only use /dev/urandom
> only-urandom
> --8<---------------cut here---------------end--------------->8---
>
> That is in general okay because on modern kernels we anyway use the
> getrandom call and thus we are eben safe at boot time.

If we're using getrandom() with the appropriate semantics, shouldn't
this be the default?  As random(4) says:

       The  /dev/random  interface  is  considered  a  legacy  interface,  and
       /dev/urandom is preferred and sufficient in all  use  cases,  with  the
       exception  of  applications  which require randomness during early boot
       time; for  these  applications,  getrandom(2)  must  be  used  instead,
       because it will block until the entropy pool is initialized.

What is the right default here?

    --dkg