Support multi-prime RSA (RFC 8017) #4241

InfoHunter · 2017-08-24T05:29:18Z

This feature is very useful if someone wants to reduce the cost of hardware accelerators and can be tolerate with a less security key. [This implementation is based on RFC 8017]

Some performance data by using openssl speed:
2-prime: 7979
3-prime: 9908
5-prime: 18617
8-prime: 24878
15-prime: 31811
(quantity of RSA 2048-bit private key operations in 10s)

Also, the generation time of 4096-bit key:
2-prime: 1.237
3-prime: 0.467
5-prime: 0.237
8-prime: 0.098
15-prime: 0.080
(in seconds)

To be simplified, the maximum number of primes is limited to 16.

After I finished this patch, I just found this previous work accidentally: https://rt.openssl.org/Ticket/Display.html?id=3477&user=guest&pass=guest. This is a 3 years old patch and was closed in the 'bug bankruptcy ' movement last year.

Note: This patch might be buggy, consider it as an experimental feature. Let's focus on discussing if the feature is worth being included into master...

Patent Caution: If I understand correctly, all related patents are expired on Jan 2017. (US5848159 and US7231040)

Introduce RSA_generate_multi_prime_key to generate multi-prime
RSA private key. As well as the following functions:
RSA_generate_multi_prime_key
RSA_get_multi_prime_num
RSA_get0_multi_prime_factors
RSA_get0_multi_prime_crt_params
RSA_set0_multi_prime_params
RSA_set_version
RSA_get_version
Support EVP operations for multi-prime RSA
Support ASN.1 operations for multi-prime RSA
Support multi-prime check in RSA_check_key_ex
Support multi-prime RSA in apps/genrsa and apps/speed
Support multi-prime RSA manipulation functions
Test cases and documentation are added

Checklist

documentation is added or updated
tests are added or updated

johndoe31415 · 2017-08-24T17:17:28Z

Interesting, I wan't aware there was such a thing as multi-prime RSA. Wanted to read up on it, but unfortunately the reference given by the RFC (Silverman, R., "A Cost-Based Security Analysis of Symmetric and Asymmetric Key Lengths", RSA Laboratories, Bulletin No. 13, 2000) does not appear to be available anymore. Do you maybe have a copy?

InfoHunter · 2017-08-25T03:02:24Z

A Google cached page is available here: Google cached SILVERMAN

And I think you would be interested in this article: https://www.imperialviolet.org/2011/04/09/multiprime.html

FdaSilvaYY · 2017-08-26T13:19:24Z

crypto/rsa/rsa_gen.c

+                                        e_value, cb);
+}
+
+int RSA_generate_multi_prime_key(RSA *rsa, int bits, int primes, BIGNUM *e_value, BN_GENCB *cb)


style : please stay inside 80 cols ;)

FdaSilvaYY · 2017-08-26T13:21:49Z

crypto/rsa/rsa_asn1.c

    }
    return 1;
 }

+/* use customized new and free operations */
+static int rsa_prime_info_cb(int operation, ASN1_VALUE **pval, const ASN1_ITEM *it,


style : 80 cols

FdaSilvaYY · 2017-08-26T13:22:20Z

crypto/rsa/rsa_ossl.c

+            }
+
+            /*
+             * This will help stop the size of r0 increasing, which does affect the


style: 80 cols, just move the last word to next line

FdaSilvaYY · 2017-08-26T13:37:43Z

crypto/rsa/rsa_gen.c

+        }
+        rsa->prime_infos = prime_infos;
+
+        /* prime_info from 2 to prime -1 */


... to |primes| - 1

FdaSilvaYY · 2017-08-26T13:40:52Z

test/rsa_mp_test.c

+
+static int key4096p7(RSA *key)
+{
+    /* C90 requires string shoudl <= 509 bytes */


typo: should

FdaSilvaYY · 2017-08-26T13:46:13Z

test/rsa_mp_test.c

+                                         BN_bin2bn(iqmp, sizeof(iqmp) - 1, NULL)), 1))
+        return 0;
+
+    pris = OPENSSL_zalloc(sizeof(BIGNUM *) * 5);


Why don't you #define NUM_TEST_KEYS 5 , so you will avoid repeating this magic number, and allocating a pseudo-dynamic array of pointer

Yep, a macro is better. But 5 is not the number of keys, it's the number of extra primes. So I will use the name NUM_EXTRA_PRIMS 5 instead.

snhenson · 2017-08-26T14:42:06Z

Note: if we take this up the ASN.1 side can be simplified considerably and possibly the accessors too.

briansmith · 2017-08-26T18:16:05Z

My understanding is that Intel has submitted multiple multi-prime RSA implementations, some of which have highly-optimized SIMD code. Cloudflare also has a highly-optimized implementation: https://github.com/vkrasnov/multiprime.

briansmith · 2017-08-26T18:18:30Z

This paper describes the previous Intel/Cloudflare contribution to OpenSSL and links to at least some of the implementations they contributed: Speed Records for Multi-prime RSA Using AVX2 Architectures.

InfoHunter · 2017-08-29T05:31:41Z

@briansmith , yes there are patches before (for 1.0.2 and 1.1.0 branches). I didn't look carefully into those patches, but I think the optimizations there are for some special cases (such as 3 or 4 primes, for some fixed length of each prime). This PR aims to provide a generic C implementation for the master branch, thus if OpenSSL 1.1.1 is released, one can get a usable patch immediately.

This is just another attempt to include this feature into master of OpenSSL.

InfoHunter · 2017-09-21T03:53:44Z

ping @openssl for other comments on this...

mattcaswell

Probably this needs a note in CHANGES.

mattcaswell · 2017-09-27T10:59:34Z

crypto/rsa/rsa_asn1.c

@@ -27,10 +27,40 @@ static int rsa_cb(int operation, ASN1_VALUE **pval, const ASN1_ITEM *it,
        RSA_free((RSA *)*pval);
        *pval = NULL;
        return 2;
+    } else if (operation == ASN1_OP_D2I_POST) {


The comment at the start of this function probably needs updating

mattcaswell · 2017-09-27T11:00:08Z

apps/genrsa.c

@@ -108,6 +110,10 @@ int genrsa_main(int argc, char **argv)
            if (!opt_cipher(opt_unknown(), &enc))
                goto end;
            break;
+        case OPT_PRIMES:
+            if (!opt_int(opt_arg(), &primes))


Do we need to validate this parameter to check it is sane?

I think there's no need to do so, since the primes variable will be checked in the following RSA_generate_multi_prime_key function

mattcaswell · 2017-09-27T11:14:34Z

crypto/rsa/rsa_gen.c

+
+        /* prime_info from 2 to |primes| -1 */
+        for (i = 2; i < primes; i++) {
+            pinfo = rsa_multip_info_new();


Check the return is not NULL?

mattcaswell · 2017-09-27T11:22:01Z

crypto/rsa/rsa_gen.c

+                goto err;
+        }
+        if (primes == RSA_DEFAULT_PRIME_NUM && i == 1) {
+            if (BN_cmp(rsa->p, rsa->q) < 0) {


I'm not sure I understand why this is necessary - and why it is not necessary in the multi-prime case.

It's used to make sure this: https://github.com/InfoHunter/openssl/blob/5b5d37804656e59c2ef8928c0f1005ed9e8c054a/crypto/rsa/rsa_ossl.c#L808-L813

And this is left for staying consistent with the original 2-primes logical, doing so for multi-prime would be a little more complex and unnecessary.

This is somewhat counter-intuitive placement of this condition. You don't quite expect it to see inside this loop. And it's not obvious that this is correct. Indeed, consider that you swapped rsa->p and rsa->q, then figured that prime needs to be extended. Which of the two will be extended? I'm not saying that it's incorrect (haven't thought of it closely enough), I'm rather pointing out the question reader would struggle with. So if this is actually correct placement for this check, then a commentary would probably be appropriate.

Recent discussion effectively answers the question why this is necessary, but it also shows that this is not specific to two-prime case. However, I still find placement of the condition in the loop counter-intuitive and somewhat inappropriate. Suggestion is it take it out of the loop. I.e. generate all the primes and perform comparison at line 236.

mattcaswell · 2017-09-27T11:30:34Z

crypto/rsa/rsa_gen.c

+                goto err;
+            goto redo;
+        }
+        /* save product of primes for furhter use, for multi-prime only */


Typo: further

mattcaswell · 2017-09-27T11:46:46Z

crypto/rsa/rsa_mp.c

+        goto err;
+    if ((pinfo->t = BN_secure_new()) == NULL)
+        goto err;
+    if ((pinfo->pp = BN_new()) == NULL)


BN_secure_new() not needed?

Errr, seems needed...

mattcaswell · 2017-09-27T11:49:06Z

crypto/rsa/rsa_ossl.c

@@ -636,6 +644,28 @@ static int rsa_ossl_mod_exp(BIGNUM *r0, const BIGNUM *I, RSA *rsa, BN_CTX *ctx)
                BN_free(q);
                goto err;
            }
+            if (primes) {


Use primes > 0. The variable primes is not a boolean.

mattcaswell · 2017-09-27T11:49:39Z

crypto/rsa/rsa_ossl.c

@@ -705,6 +735,48 @@ static int rsa_ossl_mod_exp(BIGNUM *r0, const BIGNUM *I, RSA *rsa, BN_CTX *ctx)
        BN_free(dmp1);
    }

+    /* calculate m_i in multi-prime case */
+    if (primes) {


mattcaswell · 2017-09-27T11:57:53Z

crypto/rsa/rsa_ossl.c

@@ -747,6 +819,67 @@ static int rsa_ossl_mod_exp(BIGNUM *r0, const BIGNUM *I, RSA *rsa, BN_CTX *ctx)
    if (!BN_add(r0, r1, m1))
        goto err;

+    /* add m_i to m in multi-prime case */
+    if (primes) {


mattcaswell · 2017-09-27T12:04:06Z

doc/man3/RSA_get0_key.pod

+RSA_set0_multi_prime_params() return 1 on success or 0 on failure.
+
+RSA_get_multi_prime_num() returns the number of other primes or 0 if there
+is no other primes.


if there are no other primes

snhenson · 2017-09-27T19:06:09Z

crypto/rsa/rsa_asn1.c

+        ASN1_SIMPLE(RSA_PRIME_INFO, d, CBIGNUM),
+        ASN1_SIMPLE(RSA_PRIME_INFO, t, CBIGNUM),
+} ASN1_SEQUENCE_END_cb(RSA_PRIME_INFO, RSA_PRIME_INFO)
+


None of this low level stuff in rsa_prime_info_cb should be necessary. You should just be able to make the new fields optional and extend RSA_free() to free up any multiprimes present.

I don't quite understand this. It seems we also need to handle the new side things if there is no rsa_prime_info_cb; otherwise, who allocates those multi-prime related stuffs' memories in the RSA structure?

The normal ASN.1 functions provide their own new/free methods based on the structure. The defaults may be sufficient in this case. If so that would mean the callback is not necessary. There may be something I'm missing though; I'll check.

Ah... there is a pp field which isn't part of the ASN.1 which is calculated and handled separately. While it is possible to allocate pp as part of rsa_multip_calc_product() and delete rsa_prime_info_cb I don't see any advantage over doing this in the callback.

One advantage is rsa_multip_calc_product() can do calculation only and allocation is done outside this function by the caller. This will make the code more clear to understand. But anyway, this time I put an allocation of pp in rsa_multip_calc_product() and removed the callback in ASN.1.

snhenson · 2017-09-27T19:09:01Z

crypto/rsa/rsa_lib.c

+ err:
+    sk_RSA_PRIME_INFO_free(prime_infos);
+    return 0;
+}


Any reason we can't automatically set the version number in this function?

This is because there is no easy way to 'unset' this if the RSA structure will be reused as:

key = RSA_new(); /* set a bundle of primes, params for multi-prime usages */ RSA_set_version(key, 1); /* use the multi-prime key */ /* after a while, need to use the key as a 2-prime key and reset the params and factors */ RSA_set_version(key, 0); /* use the 2-prime key */

If we set the version number to 0 automatically in RSA_set0_factors, that would require the calling order must be: RSA_set0_factors then RSA_set0_multi_prime_params

So let the user to set version number explicitly might be a simple choice...

InfoHunter · 2017-09-29T14:39:51Z

CHANGES file was also updated in new commit.

mattcaswell · 2017-10-02T09:23:39Z

Looking good. A few outstanding issues from me in comments above.

InfoHunter · 2017-10-09T07:50:13Z

New commit pushed to address comments.

mattcaswell

Approved subject to a couple of nits being fixed. Ping @snhenson for second review.

mattcaswell · 2017-10-09T09:18:23Z

crypto/rsa/rsa_lib.c

+int RSA_set_version(RSA *r, int32_t ver)
+{
+    /* { two-prime(0), multi(1) } */
+    if (ver != 0 && ver != 1)


Use RSA_ASN1_VERSION_DEFAULT and RSA_ASN1_VERSION_MULTI instead of 0 and 1

mattcaswell · 2017-10-09T09:33:12Z

crypto/rsa/rsa_ossl.c

+        }
+
+        for (i = 0; i < primes; i++) {
+


Remove the blank line here

snhenson · 2017-10-09T11:28:03Z

Put a temporary hold on this while I check the ASN.1 part.

dot-asm · 2017-11-13T12:41:14Z

Once again, somebody doing something [like that] doesn't mean that we [or anybody else] should do same or even encourage/facilitate it.

But the 'somebody' there, are the users of this software - OpenSSL.

??? If they generate insecure keys, they can't be using OpenSSL (since it doesn't support it), and if they insist on doing so, what prevents them from sticking with that other software?

dot-asm · 2017-11-13T12:57:04Z

We currently already enforce an 80 bit security limit, which BN_security_bits() maps to a 1024 bit key. I see little point in having a 768 limit and only later move to 1024.

That's for TLS, but not CMS or other libcrypto use-cases

1st rule of public-key cryptography is that you don't talk about private key. This means that there is only one parameter that defines interoperability with outer world, and it's length of public key. And this is a separate question, separate from context of this request. Namely, [as already pointed out several times here] questions are a) which public key lengths do we permit [to ensure interoperability]; b) how many private factors does public key consist of [which has no bearing on interoperability]. Or in other words, references to TLS, CMS or other libcrypto use-cases discuss rather a), while what we're trying to discuss here is b). To be more specific. Question is not whether or not to keep RSA1024, but if we keep it, how many primes would we permit given that we aim to maintain not worse security promise.

InfoHunter · 2017-11-16T11:53:06Z

Ping @openssl , what's next move?

dot-asm · 2017-11-17T09:50:32Z

As for references to legacy weak algorithms and schemes. Keyword there is legacy and interoperability, or in other words it's desired to keep them as option for backward compatibility. While here, i.e. in context of this request, backward compatibility is of no concern. Indeed, multi-prime support has no effect on ability to verify old signatures, or ability to produce new signatures with old keys. There is no compelling/legitimate reason to permit arbitrary public key slicing, i.e. such that weakens any given scheme. And once again, question is not about choice of the scheme, i.e. not whether or not to permit specific public key length, be it 64, 512 or 1024 bits, but about not weakening any specific one, be it 64 or 16384.

vdukhovni · 2017-11-17T09:58:38Z

@dot-asm As for references to legacy weak algorithms and schemes. Keyword there is legacy and interoperability, or in other words it's desired to keep them as option for backward compatibility. While here, i.e. in context of this request, backward compatibility is of no concern. Indeed, multi-prime support has no effect on ability to verify old signatures, or ability to produce new signatures with old keys. There is no compelling/legitimate reason to permit arbitrary public key slicing, i.e. such that weakens any given scheme. And once again, question is not about choice of the scheme, i.e. not whether or not to permit specific public key length, be it 64, 512 or 1024 bits, but about not weakening any specific one, be it 64 or 16384.

Which I read as: Make sure that ECM attacks against multi-prime RSA at any supported key size and prime count, ... is not cheaper than GNFS attack on the same modulus size for the two prime case. With a generous safety margin just to account for plausible uncertainty in the relative costs. So, for example not using primes shorter than n-bits where ECM runtime for n-bit factors far exceeds the GNFS runtime for all supported key sizes would address the problem. My guess is that a floor of 512-bits on the primes is sufficient for that, but this would need to be confirmed by a real cryptographer. A floor closer to 256-bits may also be sufficient, TBD...

dot-asm · 2017-11-17T10:14:00Z

My guess is that a floor of 512-bits on the primes is sufficient for that, but this would need to be confirmed by a real cryptographer. A floor closer to 256-bits may also be sufficient, TBD...

[As already mentioned multiple times] it has already been referred to couple of times here, "On the Security of Multi-prime RSA", http://cacr.uwaterloo.ca/techreports/2006/cacr2006-16.pdf. It's argued that there is no common floor value suitable for all lengths. For example it's asserted that 2048-bit public key should not consist of more that 3 factors, 4096 - of more than 4, etc.

dot-asm · 2017-11-17T11:42:53Z

crypto/rsa/rsa_gen.c

+        /*
+         * if |r1|, product of factors so far, is not as long as expected
+         * (by checking the first 4 bits are less than 0x9 or greater than
+         * 0xF). If so, re-generate the last prime.


"first bits" is ambiguous term (not to mention kind of explosive in sense that it has potential to evoke spirits of endian war), "most significant" is one that is appropriate. Also the statement is confusing in sense that 4-bit value can't be larger than 0xF.

BTW, I'm actually uneasy about this check for 9. Original rationale is to merely obscure the fact that key is multi-prime (which should not be viewed as private information in sense that adversary can figure it out anyway). But question is if by insisting on specific bit pattern in most significant 4 bits you indirectly insist on specific pattern in less significant bits. Because in such case you might leak more information than you're trying to conceal. For example you're trying to conceal the fact that it's multi-prime, but indirectly reveal that it's specifically 4-prime. Well, amount of primes should not be viewed as private information either, what I'm rather trying to say is that argument in favour of check for 9 might contradict itself.

I think "most significant" is also not really appropriate term either.
The product is scaled down by the expected number of bits - 4,
and that value can be less than 9 or even 8. It can only exceed 15 if adj = 1.

Well, initial objection was specifically about term "first bits". I mean what is "first bit", where do you start counting? "Most significant" is the only unambiguous way to describe the bit of interest here. Then yes, there is second ambiguity in comment, how many most significant bits are we looking at. As we indeed can end up with 4, 5, 3, and yes, "product [being] scaled down by the expected number of bits minus 4" eliminates both ambiguities...

dot-asm · 2017-11-17T11:54:36Z

crypto/rsa/rsa_gen.c

+                 * in 4 prime case to avoid long loop. Max retry times
+                 * is set to 4.
+                 */
+                i = -1;


I see no statistical advantage in discarding 1st prime. I.e. i = 0 would do. I also find comment confusing. ~~It's sound~~ It sounds like it will fail after four attempts to generate 4-prime key. While what happens is that it takes 4 attempts in order to start over, and failure is not an option.

dot-asm · 2017-11-19T11:32:31Z

@dot-asm As for references to legacy weak algorithms and schemes.

Which I read as:

And it should also be read as "argument that one can make about support of legacy weak algorithms and schemes don't apply in context of this request [because it is not about legacy]."

t-j-h · 2017-11-20T00:47:22Z

Other than nitpicking on comments and a disagreement about technical enforcement of the maximum number of primes (or the minimum size of each prime) is there anything else left on this PR?

t-j-h · 2017-11-21T06:18:11Z

This PR at various times has had @mattcaswell @t-j-h and @levitte approval.
None of the subsequent discussion has raised any items about the code (only about policy that belongs in at least my view elsewhere). @InfoHunter has pretty much applied all the feedback that could reasonably be applied (noting that some of the feedback is conflicting).

@mattcaswell - if your approval still stands mine certainly does so this is ready to merge (assuming you clean up the noted libcrypto.num conflict ...)

* Introduce RSA_generate_multi_prime_key to generate multi-prime RSA private key. As well as the following functions: RSA_get_multi_prime_extra_count RSA_get0_multi_prime_factors RSA_get0_multi_prime_crt_params RSA_set0_multi_prime_params RSA_get_version * Support EVP operations for multi-prime RSA * Support ASN.1 operations for multi-prime RSA * Support multi-prime check in RSA_check_key_ex * Support multi-prime RSA in apps/genrsa and apps/speed * Support multi-prime RSA manipulation functions * Test cases and documentation are added * CHANGES is updated

InfoHunter · 2017-11-21T06:40:04Z

Conflicts are resolved and all commits are squashed into one.

bernd-edlinger

Approved.

Note however I would still prefer to set
RSA_MIN_PRIME_SIZE to 256
and RSA_MAX_PRIME_NUM to 8.
Which is not perfectly safe, but makes
it harder to choose completely unsafe
settings.

mattcaswell · 2017-11-21T15:06:21Z

I think this has moved on someway since my review - but since @bernd-edlinger and @t-j-h both approve I don't feel a need to reconfirm. Please go ahead without my review.

InfoHunter · 2017-11-21T16:25:49Z

Cool, seems it's pushed forward.

mattcaswell · 2017-11-21T16:45:23Z

@bernd-edlinger will you merge?

* Introduce RSA_generate_multi_prime_key to generate multi-prime RSA private key. As well as the following functions: RSA_get_multi_prime_extra_count RSA_get0_multi_prime_factors RSA_get0_multi_prime_crt_params RSA_set0_multi_prime_params RSA_get_version * Support EVP operations for multi-prime RSA * Support ASN.1 operations for multi-prime RSA * Support multi-prime check in RSA_check_key_ex * Support multi-prime RSA in apps/genrsa and apps/speed * Support multi-prime RSA manipulation functions * Test cases and documentation are added * CHANGES is updated Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from #4241)

bernd-edlinger · 2017-11-21T17:31:03Z

Merged to master. Thanks!

InfoHunter · 2017-11-21T17:57:06Z

Thanks!

InfoHunter force-pushed the rsa-mp branch 7 times, most recently from eb50bcf to c8ccaf8 Compare August 24, 2017 16:33

FdaSilvaYY reviewed Aug 26, 2017

View reviewed changes

snhenson closed this Aug 26, 2017

snhenson reopened this Aug 26, 2017

InfoHunter force-pushed the rsa-mp branch from c8ccaf8 to 5b5d378 Compare August 29, 2017 08:09

mattcaswell requested changes Sep 27, 2017

View reviewed changes

snhenson reviewed Sep 27, 2017

View reviewed changes

InfoHunter force-pushed the rsa-mp branch from 5b5d378 to 2b8c55a Compare September 29, 2017 13:34

InfoHunter force-pushed the rsa-mp branch from f2f4924 to dda12b9 Compare October 9, 2017 07:44

mattcaswell approved these changes Oct 9, 2017

View reviewed changes

mattcaswell added the approval: review pending This pull request needs review by a committer label Oct 9, 2017

snhenson added the hold: need omc decision The OMC needs to make a decision label Oct 9, 2017

InfoHunter force-pushed the rsa-mp branch from 9ac63e3 to f77466e Compare November 13, 2017 07:55

dot-asm reviewed Nov 17, 2017

View reviewed changes

InfoHunter force-pushed the rsa-mp branch from f77466e to a9dfbb8 Compare November 21, 2017 06:39

bernd-edlinger approved these changes Nov 21, 2017

View reviewed changes

mattcaswell added approval: done This pull request has the required number of approvals and removed approval: review pending This pull request needs review by a committer labels Nov 21, 2017

bernd-edlinger closed this Nov 21, 2017

InfoHunter deleted the rsa-mp branch November 21, 2017 17:57

This was referenced Nov 21, 2017

rsa/rsa_gen.c: ensure backward compatibility with external rsa->meth. #4770

Closed

Cap amount of primes in multi-prime RSA #4791

Closed

dot-asm mentioned this pull request Dec 1, 2017

A method to switch off mandatory prime number limit #4826

Closed

2 tasks

Support multi-prime RSA (RFC 8017) #4241

Support multi-prime RSA (RFC 8017) #4241

Conversation

InfoHunter commented Aug 24, 2017 • edited

Checklist

johndoe31415 commented Aug 24, 2017

InfoHunter commented Aug 25, 2017

FdaSilvaYY Aug 26, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

snhenson commented Aug 26, 2017

briansmith commented Aug 26, 2017

briansmith commented Aug 26, 2017

InfoHunter commented Aug 29, 2017

InfoHunter commented Sep 21, 2017

mattcaswell left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

InfoHunter commented Sep 29, 2017

mattcaswell commented Oct 2, 2017

InfoHunter commented Oct 9, 2017

mattcaswell left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

snhenson commented Oct 9, 2017

dot-asm commented Nov 13, 2017

dot-asm commented Nov 13, 2017

InfoHunter commented Nov 16, 2017

dot-asm commented Nov 17, 2017

vdukhovni commented Nov 17, 2017

dot-asm commented Nov 17, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dot-asm Nov 17, 2017 • edited

Choose a reason for hiding this comment

dot-asm commented Nov 19, 2017

t-j-h commented Nov 20, 2017

t-j-h commented Nov 21, 2017

InfoHunter commented Nov 21, 2017

bernd-edlinger left a comment

Choose a reason for hiding this comment

mattcaswell commented Nov 21, 2017

InfoHunter commented Nov 21, 2017

mattcaswell commented Nov 21, 2017

bernd-edlinger commented Nov 21, 2017

InfoHunter commented Nov 21, 2017

InfoHunter commented Aug 24, 2017 •

edited

FdaSilvaYY Aug 26, 2017 •

edited

dot-asm Nov 17, 2017 •

edited