-indenting and doxygen

convering revocation_api.c to new MQ API

-tolerate init CB being NULL from the beginning

convering nse_api.c to new MQ API

-fix off-by-1

log

adapt set test case to new scheduler semantics

log error when timed out

-fix format warning

- fix warnings

use c99

-force c99

- fix warnings

-fix FTBFS

avoid deprecated API, use new connecT API

avoid assertion on NULL mq

proper shutdown

-incorrect comment

-use new connecT API

-assert on task

-fix gnunet-revocation

-fix the fix

avoid changing API for now

use new connecT API

refactoring core API to use new MQ lib

-fix typo

redefine GNUNET_MQ_queue_for_connection_client to capture client handle

-fix

-indentation and comments

update secretsharing to new MQ API

fix consensus to match new MQ API -- and correct CONCLUDE_DONE to be fixed-size

fix RPS to match new MQ API -- and to check message format

-fixing part of Martin's FTBFS

adapt peerstore API to new MQ API

convert conversation_api_call.c

-fix

- fix more rest and jsonapi

partial refactoring, will cause FTBFS, to be completed ASAP

- fix rest plugin

- revert to r37134. Broken build

plugin datastore mysql

Fix perf_crypto_rsa.c after various changes

Not perfect, but some functionality is nolonger exposed.

-rps: merge duplicate functions

-rps: open channel when inserting peer in view

fix indentation, bad stack allocation of buf

lcov test function

fix memroy leak

finish to fix memory leak

finish to fix memory leak

fix memory leak

improved usability for gnunet-logread -f

Rework the error handling for gcd(r,n) != 1 so the Taler wallet can see errors.

Abstract out previous GCD(m,n)=1 commit into a single function

This should make it easier to report properly in the wallet.

Verify that GCD(m,n) != 1 when n is an RSA modulus

Much thanks to CodesInChaos <codesinchaos@gmail.com> from the
cryptography@metzdowd.com list for observing this flaw!

On Tue, 2016-06-07 at 13:39 +0200, CodesInChaos wrote:
> How do you handle the case where GCD(m, n) != 1 where m is the message
> (i.e. the full domain hash) and n the modulus? Do you reject that
> message and generate a new one?

If I understand the attack you have in mind, it goes roughly :

First, an evil exchange creates a 2048 bit RSA key pq, but issues n = p
q r_1 r_2 ... r_k as say a 4096 bit RSA key where r_i is a smallish but
preferably not so obvious primes, like not 2, 3, or 5.

Next, our evil exchange detects and records when the various r_i appear
during blinding and spending.  As m is 4096 bits, then some always do
since we took the r_i smallish.

Each appearing r_i factor leaks I think several bits about the
customer's identity.  If enough coins are involved in a transaction,
especially say through repeated transactions, then the customer will
quickly be deanonymized.

I could've fixed this in crypto_kdf.c but I descided it was specific
to RSA, so I did it when calling the KDF.  It should be abstracted
into a common routine probably.

Also fixes a pair of memory leaks.

check for existing task

written function cleanup

social cli: fix shutdown

-fix & vs &&

-fix misc issues

start to fix extract vsize

start to fix extract vsize

fixes

fixes

fixes

debug msgs

continue to fix extract result

start to fix extract result

-fix #4541

refactoring my API

start to written extract_result

-oops, remove printf

-indent

invert option order for tg

Fix for #4553

fix #4546

only run tests if they are enabled

fixing insert query

fix #4545: create directory for log file if it does not exist

taught gnunet-logread to also do what gnunet-logread-ipc used to do

added filters to gnunet-logread and an automation fix for gnunet-arm

typo in src/identity/gnunet-identity.c

fixing query insert

fix select request

Testcases for KDF mod n

Currently just that the result is smaller than n, maybe should do more.

Use a uniform random number mod an RSA composites for both
the blinding factor and the full domain hash.

This resolves an attack against the blinding factor in Taler:

There was  a call to GNUNET_CRYPTO_kdf in
  bkey = rsa_blinding_key_derive (len, bks);
that gives exactly len bits where
  len = GNUNET_CRYPTO_rsa_public_key_len (pkey);

Now r = 2^(len-1)/pkey.n is the probability that a set high bit being
okay, meaning bkey < pkey.n.  It follows that (1-r)/2 of the time bkey >
pkey.n making the effective bkey be
  bkey mod pkey.n = bkey - pkey.n
so the effective bkey has its high bit set with probability r/2.

We expect r to be close to 1/2 if the exchange is honest, but the
exchange can choose r otherwise.

In blind signing, the exchange sees
  B = bkey * S mod pkey.n
On deposit, the exchange sees S so they can compute bkey' = B/S mod
pkey.n for all B they recorded to see if bkey' has it's high bit set.
Also, note the exchange can compute 1/S efficiently since they know the
factors of pkey.n.

I suppose that happens with probability r/(1+r) if its the wrong B, not
completely sure.  If otoh we've the right B, then we've the probability
r/2 of a set high bit in the effective bkey.

Interestingly, r^2-r has a maximum at the default r=1/2 anyways, giving
the wrong and right probabilities 1/3 and 1/4, respectively.

I fear this gives the exchange a meaningful fraction of a bit of
information per coin involved in the transaction.  It sounds damaging if
numerous coins were involved.  And it could run across transactions in
some scenarios.

I suspect we need a more uniform deterministic pseudo-random number
generator for blinding factors.  Just fyi, our old call to
gcry_mpi_randomize had this same problem.

I do not believe this caused a problem for the full domain hash, but
we can fix it easily enough anyways.

create table for test case fixed

- Fix #4532

begin to rewritten test case

-fix

-fix

function result helper rewritten

sketch envisioned API

-indent fixes

fix #4536

fix warning compilation libgnunetmy

- add peerstore tests

- jsonapi build fix, add peerstore flat (EXP)

fixing #4483: optimize blinding key storage/transmission

test case for mysql

fix result and query helper