network profile
| bio | website | |
|---|---|---|
| location | Helsinki, Finland | |
| age | 34 | |
| visits | member for | 1 year, 9 months |
| seen | Mar 19 at 18:13 | |
| stats | profile views | 15 |
|
May 19 |
awarded | Popular Question |
|
Dec 15 |
awarded | Self-Learner |
|
Aug 16 |
awarded | Yearling |
|
Oct 21 |
comment |
uniquely identify a symmetric key Hashing is meant to be secure in this case. If the key is actually generated from randomness (and not a password or something similar), reversing the hash is the classical pre-image attack and well covered by hash function security. |
|
Sep 22 |
comment |
Converting a stream cipher into a block cipher You are right, any old stream cipher won't do and it isn't trivial, so it is not a generic solution. |
|
Sep 21 |
comment |
Designing a key expander out of ciphers If a hash algorithm is used to expand the key, then that hash algorithm can be attacked to gain knowledge of all the keys - in effect, if your hash algorithm isn't stronger than all the ciphers, the hash algorithm becomes the weakest link. Alternatively, if your hash algorithm is stronger than all the ciphers, you can just use the hash algorithm for encryption (although that is somewhat non-trivial to do securely if your hash algorithm isn't really good). |
|
Sep 21 |
comment |
Designing a key expander out of ciphers This works. Alternatively, any all-or-nothing transform could be used, such as OAEP, but then that transform could be attacked. XOR is only weak in the sense that knowing the first byte of every plaintext reveals the first byte of the key - but hopefully the ciphers used are not weak like this. |
|
Sep 20 |
comment |
Converting a stream cipher into a block cipher Using Salsa20 and a three round feistel in BEAR/LION style constructs one can achieve a block cipher of small block size (say 128-bit) with around a 15x slowdown compared to the stream cipher. For Salsa20 or similar, this could be only a few times slower than AES in software. For larger block sizes, the slowdown is even less. I would consider them practical and not very slow if you actually have the need - but obviously a real block cipher is always faster. |
|
Sep 20 |
awarded | Critic |
|
Sep 20 |
comment |
Is Convergent Encryption really secure? Great answer. However, one more attack: an attacker can guess plaintexts and test if you have that file. This attack will reveal passwords in configuration files that haven't been modified otherwise, for example. |
|
Sep 20 |
comment |
Is Convergent Encryption really secure? You should explain your notion of "secure", as convergent encryption is either secure or not secure depending on your definition. |
|
Sep 20 |
comment |
Is Convergent Encryption really secure? This same question is asked here: security.stackexchange.com/questions/7142/… |
|
Sep 18 |
answered | What is the post-quantum cryptography alternative to Diffie-Hellman? |
|
Sep 10 |
comment |
SHA1 usage for passwords, alternatives and advantages? @Niklas R: Please read the comments and the links and try to read things a bit more carefully. Your comments are pretty much all over the place. crypt is not only DES and you are mixing up the hash algorithm with the "operating mode". PBKDF2 may use SHA1 internally and it is as secure as any. The point is not to use simple concatenation of salt and password hashed, but something more complex - the point is not to change the actual hash function used. |
|
Sep 8 |
comment |
Does NTRU decrypt correctly now? Just to make it even more obvious: those parameters have been chosen for a $2^{256}$ security level in general, and the failure probability is also smaller than $2^{-256}$. So exploiting a decryption failure requires just as much work as breaking other parts of the system. |
|
Sep 5 |
comment |
SHA1 usage for passwords, alternatives and advantages? The very very very old DES crypt was vulnerable to just about everything and ignores everything after the first 8 characters. The crypt(3) in modern Linuxes uses SHA-256, has no password length limits, has a configurable amount of rounds just like PBKDF2, uses a 16 character salt, etc. The same function on OpenBSD is bcrypt. crypt(3) is just an interface. |
|
Sep 5 |
comment |
SHA1 usage for passwords, alternatives and advantages? If it wasn't obvious, import crypt in Python is just a wrapper for the crypt(3) function in the underlying platform - and as such, behaves differently on different UNIX systems. |
|
Sep 5 |
comment |
SHA1 usage for passwords, alternatives and advantages? Actually, using crypt(3) doesn't actually fix the algorithm to anything specific - there are many different implementations of the UNIX crypt and some of them provide really weak security. Please see more at: en.wikipedia.org/wiki/Crypt_(Unix) and manpages.courier-mta.org/htmlman3/crypt.3.html Also, for example the SHA-256 and SHA-512 algorithms for crypt(3) are really weird: akkadia.org/drepper/SHA-crypt.txt I'm not sure if I can recommend those fully. |
|
Sep 5 |
comment |
Does NTRU decrypt correctly now? Found a paper saying mostly what I said: "Furthermore, note that the sender cannot test if the decryption will fail or not, since the private key f is required.": homes.esat.kuleuven.be/~fvercaut/papers/cc03.pdf |
|
Sep 5 |
revised |
SHA1 usage for passwords, alternatives and advantages? Added links. |
