Reputation
1,607
Top tag
Next privilege 2,000 Rep.
Access moderator tools
Badges
1 8 18
Newest
 Caucus
Impact
~49k people reached

Jun
25
comment Why is the public/private key length used in libsodium so much shorter than needed for RSA
"For libsodium, the main problem is taking discrete logarithms"... libsodium (github.com/jedisct1/libsodium) is a cryptographic library which uses many primitives including (but not limited to) authenticated symmetric encryption, key agreement, public-key signatures, and key derivation. Do you mean Curve25519?
Jun
25
comment Why is the public/private key length used in libsodium so much shorter than needed for RSA
libsodium uses curve25519, which is based on elliptic curve cryptography — it is an entirely different algorithm to RSA (and yes , ECC key sizes are much smaller... see here for a reference... linuxjournal.com/content/elliptic-curve-cryptography). Aside from that, your question is broad - you should do some reading.
Jan
21
comment HMAC-Ripemd-160 in TrueCrypt
Personally, in 2015, I wouldn't feel comfortable with anything less than 100'000 pbkdf2 iterations as a baseline, but a million would be preferable. Using something like Scrypt is better still. Of course, if you have a sufficiently strong password, then 3000 iterations of Ripemd-160 is fine.
Jan
7
comment NTRU key generation
@CodesInChaos - I'm not sure where that number comes from, but it's also mentioned in the documentation: github.com/NTRUOpenSourceProject/ntru-crypto/blob/master/…
Jan
5
comment NTRU key generation
+1 - thanks! I accepted the other answer because it also addressed the other doubt I had
Jan
5
comment NTRU key generation
Very succinct - thanks!
Jan
5
comment NTRU key generation
1718 bytes. To illustrate further, here is a pastebin of sample public and private keys (obviously they're not production keys)
Jan
5
comment NTRU key generation
The string above is just to illustrate the repetition of zeros towards the end of a much larger (and seemingly pseudorandom) key. The key itself is 1718 bytes. As for the representation - I'm not sure how to answer. I'm just using the API - (ntru_crypto_ntru_encrypt_keygen) provided in the implementation, it returns the private key as a byte array (uint8_t).
Jan
5
comment NTRU key generation
it's hex (sorry, I neglected to mention that)
Dec
29
comment Do I have to transfer the private key to digitally sign a remote document?
DSC => Digital Signature Certificate (I suppose)
Nov
27
comment How to establish if a string contains a message
see here for some relevant reading...
Nov
10
comment Extending key sizes in Salsa20 and ChaCha?
@John - "So.. if you can extend the key size, without impacting performance, why not do it?" Because you're not a trained cryptographer and you may well end up making the algorithm weaker, not stronger.
Nov
9
comment Extending key sizes in Salsa20 and ChaCha?
"Is there something I'm not seeing here" ? Yes... extending the key beyond 256 bits is entirely redundant.
Nov
4
comment The use of the term “sound” in cryptography
Context and/or reference, please.
Sep
14
comment Hashing passwords
The first option should absolutely not be used. As for the second, see PBKDF2
Sep
2
comment Is MAC algorithm same at both sender and receiver end
Cursory research should answer your questions
Aug
28
comment Choice of authenticated encryption mode for whole messages
@Gilles - be sure to check out this article
Aug
25
comment Found a way to crack AES-128, what now?
@poncho - yeah I know... I'm not really taking this claim seriously.
Aug
25
comment Found a way to crack AES-128, what now?
Prove it. Algo = AES-128. Mode = CTR. Nonce (hex) = 9f22f26e4285f9cf69f19eabccde81c7. Ciphertext = 683a5a98232f31fe3580f0c5bb104a03e8acfd7e0cb763ae844858af48d929a28156f41f1c18a580‌​94. The plaintext is a simple sentence in English. The key you'll have to figure out for yourself... get back to us in 1-2 days? ;-)
Jul
21
comment Use AES-256 Or AES-CTR-256 For One Block?
@srgblnch - indeed.