Hello again!
Kenny Paterson's once again turning the theoretical into practical. This time he's pointed out that if one configures IPsec to MAC-then-encrypt (do packet authentication first, THEN encrypt the packet), one is open to cryptographic attack. Here's a citation for his ACM CCS paper.
The good news is that we cannot configure the IPsec SPD to perform MAC-then-encrypt at all. One could configure transport mode to just MAC, then have the packet transit a tunnel that just encrypts, but then you'll see warnings about the encryption-only tunnel configuration. This has been true for a LONG time (starting with S9, maybe even S8).
So basically, we don't make it easy for you to shoot yourself in the foot this way. You really have to try, and as I pointed out earlier, the encryption-only part will warn you.
#include <stdio.h>
int
main(int argc, char *argv[])
{
double p;
int i, listened, total, tries;
if (argc != 4) {
fprintf(stderr,
"usage: ipod [listened-songs] [total-songs] [tries]\n");
return (1);
}
p = 1.0;
listened = atoi(argv[1]);
total = atoi(argv[2]);
tries = atoi(argv[3]);
for (i = 0; i < tries; i++)
p *= (double)(total - listened - i) / (double)(total - i);
printf("P(NO repeat for %d on the second playthough): %lf%%\n", tries,
p * 100.0);
printf("P(Repeat for %d on the second playthough): %lf%%\n", tries,
(1 - p) * 100.0);
return (0);
}
Turns out, I need to hear 40 songs to have a coinflip's chance of hearing one of the previous 30 songs I heard before reshuffling the 1763 total songs.
mactavish(~/sources)[0]% ./a.out 30 1763 40 P(NO repeat for 40 on the second playthough): 49.942794% P(Repeat for 40 on the second playthough): 50.057206% mactavish(~/sources)[0]%The above program should work for any sized iPod/iPhone collection, or any sized song-memory/patience. I really hope I got the math/derivation right. Any probability wizards in the audience can feel free to school me in the comments section.
Dan's blog is powered by blahgd