Fix critical stack overflow arising from VLA usage

[hugbubby]

Two instances of VLA usage in the encrypt/decrypt functions of crypto_core left users vulnerable to a stack overflow. Here is a patch and addition to the encryptsave test to make sure it doesn't reappear.

---

This change is 

[codecov]

Codecov Report

Merging #1242 into master will increase coverage by 0.4%.
The diff coverage is 82.6%.

@@           Coverage Diff            @@
##           master   #1242     +/-   ##
========================================
+ Coverage    83.2%   83.6%   +0.4%     
========================================
  Files          82      82             
  Lines       14827   14867     +40     
========================================
+ Hits        12342   12436     +94     
+ Misses       2485    2431     -54

Impacted Files	Coverage Δ
auto_tests/encryptsave_test.c	95.7% <100%> (+0.6%)	⬆️
toxcore/crypto_core.c	91.4% <72.4%> (-8.6%)	⬇️
toxcore/LAN_discovery.c	84.9% <0%> (-1%)	⬇️
toxcore/Messenger.c	86.9% <0%> (+0.1%)	⬆️
toxav/toxav.c	68.4% <0%> (+0.3%)	⬆️
toxcore/onion_client.c	96.1% <0%> (+0.7%)	⬆️
toxav/msi.c	65.3% <0%> (+0.8%)	⬆️
toxcore/net_crypto.c	95% <0%> (+1.2%)	⬆️
toxcore/TCP_server.c	82.9% <0%> (+2.5%)	⬆️
toxcore/TCP_client.c	67.5% <0%> (+2.8%)	⬆️
... and 2 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0f8f82a...b4144fa. Read the comment docs.

[zugz]

You should check for nullptr returns from malloc in the crypto_core functions. More importantly: I'm worried that putting copies of the plaintext on the heap is a bad idea. These functions could be used for sensitive information, right? Doing a crypto_memzero before freeing should be enough to deal with this, afaics. @iphy, could you comment on this please?

[hugbubby]

@zugz crypto_memzeroed it for now.

[iphydf]

Reviewable status: 0 of 1 approvals obtained (waiting on @hugbubby and @zugz)

---

auto_tests/encryptsave_test.c, line 158 at r2 (raw file):

    int ciphertext_length2a = size_large + TOX_PASS_ENCRYPTION_EXTRA_LENGTH;
    int plaintext_length2a = size_large;
    uint8_t *encrypted2a = (uint8_t *) malloc(ciphertext_length2a);

No space after the cast.

---

auto_tests/encryptsave_test.c, line 164 at r2 (raw file):

    free(in_plaintext2a);

    //Decryption of same message.

Space after //.

---

toxcore/crypto_core.c, line 159 at r2 (raw file):

    }

    size_t size_temp_plain = length + crypto_box_ZEROBYTES;

const

---

toxcore/crypto_core.c, line 162 at r2 (raw file):

    size_t size_temp_encrypted = length + crypto_box_MACBYTES + crypto_box_BOXZEROBYTES;

    uint8_t *temp_plain = crypto_malloc(size_temp_plain);

uint8_t *const temp...

[hugbubby]

@iphydf I... (think?) I implemented your requests correctly? Travis is complaining about a build but it seems to be unrelated.

Thank you for doing the crypto_malloc and crypto_memzero, by the way. I know I said I would but somehow was under the impression that you wanted me to do it after this got merged. Sorry about that.

[zoff99]

@iphydf why is this critical fix not merged yet? can you have a look please.

[tvladyslav]

One small check just in case.

[hugbubby]

@iphydf @zoff99 I can't merge this until we fix travis's clang build.

[iphydf]

@hugbubby it's green now, but the commits aren't signed.