Results 1 ... 48 found in asciilifeform for 'serpent'
unpx: https://eprint.iacr.org/2009/038.pdf <<< ``We find that there is some discrepancy between the properties of the actual S-boxes of Serpent and the claims of the designers. It is surprising that this has not been pointed out by any body so long. This leads the revisiting the Security of the serpent.''
gregorynyssa: asciilifeform: are you saying that 32 Opteron cores are required to decrypt Serpent at line-rate?
asciilifeform: signpost: thinking about it, one only needs to decrypt 8 bytes (well, 16, being the serpent block size) past the nonce, to see timestamp. but still.
asciilifeform: gregorynyssa: see in his 'serpent.py'.
asciilifeform: gregorynyssa: if yer looking at blatta src, it is confusing in this respect, thimbronion in fact pasted in an implementation 'serpent_cbc_encrypt/decrypt' that takes an 'iv' defaulting to 0 (and never sets it), but does start msg with the nonce per spec (so in fact works out logically to correct algo)
asciilifeform suspects that gregorynyssa's confusion stems from having worked w/ aes , where there is an explicit init vector. in serpent, there aint one. the 'nonce' referred to in pest spec simply sits down as the 1st 16byte block.
gregorynyssa: I have made some progress with the "classpath" issue, and also with implementing Serpent on my own.
gregorynyssa: so the ADA version of Serpent is included in GNAT?
asciilifeform: if yer thing can link w/ gcc .o, can use the classic ada serpent, it is entirely straightforward and const-time
asciilifeform: gregorynyssa: i've a cl serpent, from while back, but not cycles to do anyffin useful w/it presently
gregorynyssa: have you implemented Serpent on your own yet?
dulapbot: Logged on 2021-12-30 23:32:59 asciilifeform: d4: serpent was the original winner of the old 'aes' contest, was vetoed by reich supposedly because 'too expensive in hardware'.
verisimilitude: On the topic of Pest, I'll eventually finish my Serpent implementations, and then I'll have all required pieces for combining.
asciilifeform wrote the rudiments of serpent for ice40, never had the cycles to finish
asciilifeform: ditto serpentism
asciilifeform: d4: serpent was the original winner of the old 'aes' contest, was vetoed by reich supposedly because 'too expensive in hardware'.
d4: May I guess the reasons behind choosing Serpent over say AES or ChaCha20 are because of funny influence of some agency and in the latter of DJB respectuful and undoubted name? asciilifeform
dulapbot: Logged on 2021-09-19 19:29:47 asciilifeform: and so nomoar problem with ciphertext not being multiple of serpent blocksize.
dulapbot: Logged on 2021-12-01 01:57:29 verisimilitude: I read an interesting paper about the serpent cipher, for implementation. Unfortunately, this means any interesting metaprogramming I could've done with a Common Lisp implementation is no longer feasible, so I may not bother to even write that version.
verisimilitude: I read an interesting paper about the serpent cipher, for implementation. Unfortunately, this means any interesting metaprogramming I could've done with a Common Lisp implementation is no longer feasible, so I may not bother to even write that version.
verisimilitude: Say, I may as well ask, have ye any recommended reading for better understand S-boxes and other such things? While I could implement the Serpent cipher already, I'd prefer to have a better understanding of it.
asciilifeform: formally, imho payload (i.e. the 428byte msg) of 0xFE oughta consist of : 32bytes ('my handle') + 4 bytes ('my ip') + 2 bytes ('my port') + 10 bytes nulls (padding) == 48bytes serpented, and anuther 48bytes of hmac (via signing key of addressee/sender pairing), summing to 96byte, and 332 nulls.
asciilifeform: verisimilitude: didja ever describe what you found lacking in the classic ada serpent ?
verisimilitude: With the CHIP-8 game jam over now, I expect I'll write my Serpent implementations this month.
asciilifeform: by using same key and same plaintext in two different functions (in this case, hypothetically, hmac and serpent) you weaken both.
dulapbot: Logged on 2021-09-27 16:54:21 verisimilitude: My SHA design required the others, because they influenced message length calculation, but Serpent doesn't have this concern.
verisimilitude: My SHA design required the others, because they influenced message length calculation, but Serpent doesn't have this concern.
dulapbot: Logged on 2021-09-24 23:59:06 verisimilitude: Now, asciilifeform isn't actually going to use that old Ada Serpent implementation, is he; I found the code horrible, and will write a nicer implementation.
verisimilitude: Now, asciilifeform isn't actually going to use that old Ada Serpent implementation, is he; I found the code horrible, and will write a nicer implementation.
dulapbot: (trilema) 2017-10-18 asciilifeform: fwiw there is a quite short ada serpent existing, passes the test set ( and branch-free ).
asciilifeform: ( e.g. the ancient ada serpent asciilifeform dug out in era2 gave only three functions -- key eater, encrypt(16bytes), decrypt(16bytes) )
asciilifeform: thimbronion: 'iv' is an aesism. what we'll be doing instead is ct_0 := serpent_e(pt_0); ct_1 := serpent_e(pt_1 ^ ct_0); ct_2 := serpent_e(pt_2 ^ ct_1); .... ctn := serpent_e(pt_n ^ ct_n-1) .
asciilifeform: and so nomoar problem with ciphertext not being multiple of serpent blocksize.
thimbronion: asciilifeform: Unable to relase the acluin update today after realizing black packet size still incorrect because not using CBC mode. Fortunately upon closer examination of the serpent lib I'm using I see it *does* support CBC mode, so that's good.
apeloyee: is ECC a bigger "ugh" than serpent?
asciilifeform: user: re mac -- in next draft (0xFD) i've hmac-384 for the sigs, so to free up some room to make payload a multiple of 16, the serpent blocksize. i sure as fuck aint using hmac256 tho, what with the abundance of sha256-bruteforce silicon on planet3. and don't see why the hell to use even smaller.
dulapbot: Logged on 2021-09-12 20:36:51 thimbronion: asciilifeform: encryption question: in updating to the new packet structure, I'm finding that a requirement of the encryption lib is that the packet must be divisible by 16, as 16 bytes is the block size. According to the spec, red packets are 424 bytes, which is not divisible by 16, causing the serpent lib to barf. Is the algo broken or am I missing a step maybe?
thimbronion: asciilifeform: encryption question: in updating to the new packet structure, I'm finding that a requirement of the encryption lib is that the packet must be divisible by 16, as 16 bytes is the block size. According to the spec, red packets are 424 bytes, which is not divisible by 16, causing the serpent lib to barf. Is the algo broken or am I missing a step maybe?
asciilifeform: punkman: that's not the weak link. storage in all cases is. hash,serpentism,etc. parallelize, with e.g. 32cpu you can guarantee processing of valid/invalid packets at nic line rate.
punkman: no idea what performance looks like for serpent and other parts
thimbronion: PeterL: According to the code in infosec.py 24 characters. According to the code in the Serpent lib, 32 bytes. Not clear to me at the moment why I set the max lower than what Serpent allows.
thimbronion: PeterL: there is a limit on the size of the key used by serpent, but the secret used to create the key could be hashed I suppose so there would be no limit in that case.
thimbronion: asciilifeform: the encryption algo will be Serpent, right?
dulapbot: Logged on 2021-07-04 14:23:37 asciilifeform: so what remains is symmetrics, e.g. serpent, with shared key.
asciilifeform: so what remains is symmetrics, e.g. serpent, with shared key.
asciilifeform: trinque, upstack : ftr asciilifeform spent ~years~ just about 'praying to satan' for a 'fdr scenario' . where perhaps suddenly e.g. serpent hardware ciphrator, to shoot in the head very concept of 'digital evidence', would be suddently marketable.
asciilifeform: the serpent demo is good intro, there is link re what the c & ada proggies looked like, and then how it was simmed, and inputs/outputs