network profile
| bio | website | nclabs.org |
|---|---|---|
| location | Amsterdam, The Netherlands | |
| age | 18 | |
| visits | member for | 5 months |
| seen | Jun 15 at 22:25 | |
| stats | profile views | 0 |
Freelance programmer and script kiddo :)
|
Jun 12 |
comment |
How to choose the appropriate public (i, m) and private (j, m) keys? I assume you mean keys, not kies? |
|
Apr 16 |
comment |
Is it safe to assume Salsa20 to be a PRP? What if you'd remove the applicability of the two-time-pad property through proper usage (that is, to never encode a different $P_1, P_2$ with the same key, nonce and block number)? |
|
Mar 9 |
comment |
ChaCha cipher + Poly1305 @dchest: ah I see, that explains it - thanks. |
|
Mar 8 |
comment |
ChaCha cipher + Poly1305 Thank you for your explanation. |
|
Mar 8 |
comment |
ChaCha cipher + Poly1305 @dchest: yes, but what I'm referring to in my answer as "strange key expansion" is the difference between NaCl and XSalsa20 in the paper. XSalsa20 is defined as $Salsa(HSalsa(key, n1), n2)$ if you split up the 24-byte nonce into 16 bytes (n1) and 8 bytes (n2). However, NaCl does something else: $Salsa(HSalsa(HSalsa(key, 0), n1), n2)$. There's no explanation for this in the paper, hence I referred to it as "some strange key expansion". |
|
Mar 8 |
comment |
ChaCha cipher + Poly1305 I don't think this is correct (I might be wrong though). The security proof works by proving that $H_r(m) = H_r(m') + g$ is rare, by finding an upper limit. Using the $H_r(m)$ building block the $Poly1305$ function is defined, but changes to $Poly1305$ do not affect the security proof of $H_r$. The idea that using XOR in the Poly1305 function would suddenly mean that the underlying $H_r$ proof also must use XOR eludes my understanding. |
|
Mar 6 |
comment |
XOR cipher for encrypting compiled C code @Praetorian: My suggestion here would be the ChaCha cipher. It's easy to implement (even in very little code space), very fast, only requires slightly more than 64 bytes of RAM and has top notch security. The author recommends a 256-bit key, but I think unless your facing a serious threat of the NSA throwing billions of dollars at computing your secret key (while they could use a $5 solution) a 128-bit key will probably do fine (and is supported by ChaCha). |
|
Feb 28 |
comment |
“Free” key exchange in a Ed25519 PKI? CodesInChaos: well yes, it is actually. I'm quite new to crypto in general and even more so to elliptic crypto, so could I perhaps contact you personally (in a chat) with some questions as to implement the layer to bridge the (probably small) gap between Ed25519 and Curve25519 public/private keypairs? |
|
Feb 8 |
comment |
Why programming languages don't provide simple encryption methods? Let's not forget that cryptography is restrained or even illegal in many countries, and as such limits the distribution of the language if included. |
|
Feb 4 |
comment |
Crypto puzzle as proof of randomness? Allright, just for future reference, I added the implementation to my github ed25519 repo, available as the ed25519_add_scalar function. |
|
Feb 3 |
comment |
Crypto puzzle as proof of randomness? I managed to implement it, thanks a ton! This property of Ed25519 is really cool. |
|
Feb 3 |
comment |
Crypto puzzle as proof of randomness? I'm new to elliptic curve cryptography, how would the sum A and the sum a be calculated? A general answer is nice, but if you could comment on it using the terminology/functions used in the SUPERCOP implementation (also available from my github) that would be nice. |
|
Feb 3 |
comment |
Crypto puzzle as proof of randomness? @CodesInChaos: the authoritative server :) |
|
Feb 3 |
comment |
Crypto puzzle as proof of randomness? The server is allowed to influence the public key. |
|
Feb 3 |
comment |
Crypto puzzle as proof of randomness? @CodesInChaos: the public key is used as a node id in the Kademlia DHT, being able to choose it allows for attacks like the Eclipse attack. |
