Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Why is crypto software so fucking bad?

Name: Anonymous 2015-03-25 2:21

/* Ask for the key size. ALGO is the algorithm. If PRIMARY_KEYSIZE
is not 0, the function asks for the size of the encryption
subkey. */
static unsigned
ask_keysize (int algo, unsigned int primary_keysize)
{
unsigned int nbits, min, def = DEFAULT_STD_KEYSIZE, max=4096;
int for_subkey = !!primary_keysize;
int autocomp = 0;
if(opt.expert)
min=512;
else
min=1024;
if (primary_keysize && !opt.expert)
{
/* Deduce the subkey size from the primary key size. */
if (algo == PUBKEY_ALGO_DSA && primary_keysize > 3072)
nbits = 3072; /* For performance reasons we don't support more
than 3072 bit DSA. However we won't see this
case anyway because DSA can't be used as an
encryption subkey ;-). */
else
nbits = primary_keysize;
autocomp = 1;
goto leave;
}
switch(algo)
{
case PUBKEY_ALGO_DSA:
def=2048;
max=3072;
break;
case PUBKEY_ALGO_RSA:
min=1024;
break;
}
[…]


Things of note:
- The procedure is impure for no fucking reason.
- The control flow is needlessly interleaved. Why is max initialized at the beginning and not within the switch, like it is for DSA keys?
- The author defines completely arbitrary upper limits on key sizes.
- The justification for the DSA limit makes no sense. Supporting bigger key sizes doesn't degrade the overall performance.
- The much more important RSA limit is not explained at all, as if it's the most natural thing in the world to limit RSA keys to 4096 bits. Word has it the reason for the RSA limit is identical to the DSA one, but since RSA is used for encryption, it is even more of a non-argument than it is in the DSA case.
- The limits are defined through magic numbers. A patch intending to fix this garbage must therefore manually track down all places that could possibly limit RSA keysize; this includes an allocation sequence that uses a multiple of 4096 and a different procedure that just fucking resets the key size to 4096 if it's higher, so even if you change/remove max, your key is still going to be 4096 bits long.

This snippet was taken from GnuPG-2.0.26. The situation of OpenSSL is well-known. How can this be, /prog/? Why is software so fundamental to security in such horrible shape? Do all authors of popular crypto software just happen to be more incompetent than a CS freshman? Is the NSA involved?

Name: Anonymous 2015-03-25 2:52

Is the NSA involved?
I'm pretty sure this is the correct answer. Taking their resources in account, I suppose they have dedicated teams for sabotaging open-source projects, as well as secret agents in key open-source development positions.

Name: Anonymous 2015-03-25 2:55

How is this function impure? From this snippet, it seems pretty pure.

Name: Anonymous 2015-03-25 3:00

>>3
I think it's because it reads from global variables.

Name: Anonymous 2015-03-25 3:14

>>3
If PRIMARY_KEYSIZE is not 0, the function asks for the size of the encryption subkey.
The snippet is not the complete code.

Name: Anonymous 2015-03-25 3:23

>>4-5
I see, thanks

Name: Anonymous 2015-03-25 3:37

>>1 >>2
Definitely looks like underhanded C. There is a whole contest
devoted to that:
http://www.underhanded-c.org/
http://underhanded.xcott.com/

Name: >>1 2015-03-25 4:49

I'll correct the point about purity a bit. It makes sense that a procedure called ask_keysize asks for the key size, but that doesn't excuse the limit bullshit that is both nonsensical and mentioned nowhere in the documentation or name.

Name: Anonymous 2015-03-26 1:01

def = DEFAULT_STD_KEYSIZE, max=4096;
^ ^ ^

I've heard it's very hard for neurotypicals to keep some consistence in the most simple tasks.

Name: Anonymous 2015-03-26 6:57

>>7
neat.

Name: Anonymous 2015-03-26 7:33

check 'em

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List