network profile
| bio | website | nclabs.org |
|---|---|---|
| location | Amsterdam, The Netherlands | |
| age | 18 | |
| visits | member for | 4 months |
| seen | May 15 at 13:26 | |
| stats | profile views | 0 |
Freelance programmer and script kiddo :)
|
Apr 16 |
accepted | Is it safe to assume Salsa20 to be a PRP? |
|
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)? |
|
Apr 16 |
asked | Is it safe to assume Salsa20 to be a PRP? |
|
Mar 9 |
comment |
ChaCha cipher + Poly1305 @dchest: ah I see, that explains it - thanks. |
|
Mar 8 |
accepted | ChaCha cipher + Poly1305 |
|
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 |
awarded | Commentator |
|
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 8 |
awarded | Teacher |
|
Mar 8 |
answered | ChaCha cipher + Poly1305 |
|
Mar 6 |
asked | ChaCha cipher + Poly1305 |
|
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). |
|
Mar 6 |
accepted | Is it safe for the ChaCha8 nonce to be deterministic? |
|
Mar 1 |
asked | Is it safe for the ChaCha8 nonce to be deterministic? |
|
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 27 |
asked | “Free” key exchange in a Ed25519 PKI? |
|
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 5 |
awarded | Student |
|
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. |
