Slashdot Mirror

s/shortening/elongating/

There, fixed it for you!

In what world
http://t.co/qLxImbQYvn
http://t.co/VnQBo6VP6g
is shorter than
http://bxr.su/
http://cnst.su/
?

Maybe it's off-topic, but is it just me who see potentially big problems with ed25519.c? e.g. http://bxr.su/OpenBSD/usr.bin/ssh/ed25519.c#25

Hint: no input validation, hard-coded array offsets with no clue about their expected size, etc...

I know, it's open-source (I should contribute, blablabla) but I see this kind of problems all over that code base.

I don't like AES-CTR as a privacy mode for online communications and I don't like this

void
aesctr_keysetup(aesctr_ctx *x,const u8 *k,u32 kbits,u32 ivbits)
{
        x->rounds = rijndaelKeySetupEnc(x->ek, k, kbits);
}

The AES key schedule can be computed inline with the round function, both for encrypt and decrypt.
Computing the key schedule inline means that the state isn't left laying around in memory.
Also, the majority of side channel attacks against key schedule rely on repeated behaviors. A simple principle that is a good mitigation is to never use the same key twice.
Pre-computing the key schedule is only an optimization when you are using the same key repeatedly.
So AES-CTR encourages both sins. Using the same key multiple times and then optimizing by keeping the key schedule state laying around.

The CTR mode is just a non-ideal PRF to generate bits that are XORed with the data. On each block the key is the same but the IV changes.
The PRF is non ideal because no block will match (since AES or any other block cipher, with a fixed key is a bijective mapping) whereas in true random data, blocks may match with the usual statistical probability.

So if we picked a better block cipher based PRF, like say the SP800-90 AES-CTR-DRBG, both key and IV change on each step, so the output looks more like a real PRF and the key isn't used twice and so there's no incentive to optimize with a pre computed key schedule.

The inline computation is nice and simple and constant time. This is a particularly inefficient implementation, you can do better:
void next_key(unsigned char *key, int round)
{
        unsigned char rcon;
        unsigned char sbox_key[4];
        unsigned char rcon_table[12] =
        {
                0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80,
                0x1b, 0x36, 0x36, 0x36
        };

        sbox_key[0] = sbox(key[13]);
        sbox_key[1] = sbox(key[14]);
        sbox_key[2] = sbox(key[15]);
        sbox_key[3] = sbox(key[12]);

        rcon = rcon_table[round];

        xor_32(&key[0], sbox_key, &key[0]);
        key[0] = key[0] ^ rcon;

        xor_32(&key[4], &key[0], &key[4]);
        xor_32(&key[8], &key[4], &key[8]);
        xor_32(&key[12], &key[8], &key[12]);
}

If anyone's looking to grok it and potentially get involved, there's a fast OpenGrok available:

http://bxr.su/o/lib/libssl/src...

On i386, OpenBSD 5.4 can be installed from either one of the 3 floppies:

%ftp ftp://ftp.nluug.nl/pub/OpenBSD/5.4/i386/
...
ftp> ls floppy*
150 Here comes the directory listing.
-rw-r--r-- 1 500 450 1474560 Jul 30 18:27 floppy54.fs
-rw-r--r-- 1 500 450 1474560 Jul 30 18:27 floppyB54.fs
-rw-r--r-- 1 500 450 1474560 Jul 30 18:27 floppyC54.fs
226 Directory send OK.

Which one do you use? You'd have to see which one supports your hardware, which is documented in the INSTALL.i386 file, generated from src/distrib/notes/i386/hardware, amongst other files:

Drivers for hardware marked with [A] are NOT included in floppy A.
Drivers for hardware marked with [B] are NOT included in floppy B.
Drivers for hardware marked with [C] are NOT included in floppy C.

In summary, it would seem like OpenBSD is only intended to be boot-strapped from a floppy (e.g. to fetch the rest of the files from the network), and from a single floppy at that. So, even with the licence aside, including something like gnupg is indeed unrealistic and cumbersome.

Which one does the Linux kernel use?

Not sure, but OpenBSD has this at the very end of its main():

while (1)
tsleep(&proc0, PVM, "scheduler", 0);
/* NOTREACHED */

I tried finding the FreeBSD equivalent, but their (Newbus?) code makes it entirely non-obvious where the loop is. Feel free to try your luck — only the comment to what the startup function is supposed to do matches, but the rest is quite unique, even a different function name — mi_startup() on FreeBSD.

Which one does the Linux kernel use?

Not sure, but OpenBSD has this at the very end of its main():

while (1)
tsleep(&proc0, PVM, "scheduler", 0);
/* NOTREACHED */

I tried finding the FreeBSD equivalent, but their (Newbus?) code makes it entirely non-obvious where the loop is. Feel free to try your luck — only the comment to what the startup function is supposed to do matches, but the rest is quite unique, even a different function name — mi_startup() on FreeBSD.

And the other ~150

The nginx on BXR had a soft FD limit of 128 (:openfiles-cur=128:) through the default login.conf(5), which it doesn't seem to increase automatically, and which it was hitting at 17:59 (if not earlier) as per fstat(1), and which applies to internet sockets, too, so, during some time between 17:52 and 18:03, when nginx was manually restarted with the increased soft limit, BXR was indeed slashdotted!

BTW, this was probably due to the HTTP keep-alive feature, and not the raw number of requests, which are all served up very quickly due to mfs and good caching. No other problems to report since then; even the search is still very fast, as it should be.

Recent `fstat | fgrep nginx` runs indicate the highest FD is around 200 now, but it did quickly jump to around 400 right after the 128 limit was lifted (within ten minutes of the story being published).

The nginx on BXR had a soft FD limit of 128 (:openfiles-cur=128:) through the default login.conf(5), which it doesn't seem to increase automatically, and which it was hitting at 17:59 (if not earlier) as per fstat(1), and which applies to internet sockets, too, so, during some time between 17:52 and 18:03, when nginx was manually restarted with the increased soft limit, BXR was indeed slashdotted!

BTW, this was probably due to the HTTP keep-alive feature, and not the raw number of requests, which are all served up very quickly due to mfs and good caching. No other problems to report since then; even the search is still very fast, as it should be.

Recent `fstat | fgrep nginx` runs indicate the highest FD is around 200 now, but it did quickly jump to around 400 right after the 128 limit was lifted (within ten minutes of the story being published).

The referenced source file has no actual implementation of the encryption in it, so claiming 100 lines is a bit silly...

Yeap. The rest is in about 200 lines of code.