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

libgnunetmy begin result helper

social: put the sock in the right cupboard

social needs to start as user service, not system

-rps: logging

-rps: only insert online peers in the view

-rps: check knowledge of peer

-rps: removing unused counter

define  GNUNET_JSON_from_data_auto

libgnunetmy query helper

GNUNET extract result libgnunetmy

extending MY api to cover result extraction

result for libgnunetmy

rename.sh GNUNET_CRYPTO_rsa_BlindingKey to GNUNET_CRYPTO_RsaBlindingKey following naming conventions

forgot file

starting libgnunetmy

-rps fix: check valid -> check online

-rps: rename and doxygen

only run integration tests if libgnurl/libcurl was available

add missing options to rps.conf.in

rps.conf is generated from rps.conf.in

what is the proper way to ensure identity service is running?

rps: use stored peers at startup

-rps: fixed storing valid peers

-rps: try to avoid leaking memory

-rps: logging

rps: add missing rps.conf

rps: store valid peer ids in file

-rps: logging

social: minor fixes

rps: keep track of valid peers in peermap

-rps: restructure service internals