meta user
network profile
| bio | website | |
|---|---|---|
| location | Saarbrücken, Germany | |
| age | 25 | |
| visits | member for | 1 year, 7 months |
| seen | 5 hours ago | |
| stats | profile views | 24 |
|
May 21 |
comment |
Do I need to keep a 64-bit version number secret? To answer that we would need to know what exactly your security goal is and what exactly the application is. For the confidentiality it shouldn't matter. But if your application needs some kind of unlinkability or something like that it could be a problem. We simply do not have enough information to judge the security of what you are trying to do. |
|
May 21 |
comment |
Do I need to keep a 64-bit version number secret? Well, if it does not pose a problem, then how can anything ever help. If there's no problem, then there is no need to solve anything. And no it would not help, because the information is still accessible to the hypothetical attacker. It is almost never valid to assume that the attacker does not know how your scheme works. |
|
May 21 |
comment |
Do I need to keep a 64-bit version number secret? The question is: Does exposing said information cause any security-loss in your application? If no, then there is no reason to try hiding it. If yes, then security by obscurity is definitely not the solution. |
|
May 18 |
comment |
When truncating an AES MAC value by “w” , how do I justify that “w” is still negligible? That may be the case, but in the area of cryptography it is very uncommon to use the term outside of the context of asymptotic security. |
|
May 17 |
comment |
When truncating an AES MAC value by “w” , how do I justify that “w” is still negligible? That's a misuse of the term negligible. Negligibility is defined for functions. (Roughly the function is dominated by the inverse of any polynomial for large enough input values.) No constant non-zero function (such as $2^{-63}$) can ever be negligible. |
|
May 16 |
comment |
Generate fixed length cipher text from arbitrary length plaintext Yes you are of course correct. So in conclusion, while the functionality as stated is theoretically impossible, it can be emulated in most practical circumstances, if the benefit outweighs the potentially large overhead. |
|
May 16 |
comment |
Generate fixed length cipher text from arbitrary length plaintext I'm just not sure that this answers the question. Of course you can always assume some upper bound (space on harddrive, duration of your "random" stream) and pad your plaintexts to this length. (This is essentially what you are doing) but the question explicitly stated that an upper bound was not wanted. |
|
May 16 |
comment |
Generate fixed length cipher text from arbitrary length plaintext What exactly is the end you do achieve that way? |
|
May 15 |
comment |
Encrypting a broadcast channel @PaŭloEbermann From an efficiency standpoint, it would probably be a disaster to use an actual broadcast-encryption scheme to stream large amounts of data. I was more thinking of a broadcast-encryption scheme as a solution to the problem you highlighted in your last paragraph. |
|
May 14 |
comment |
Encrypting a broadcast channel Well what you would be looking for is a (aptly named) broadcast encryption scheme. I think the notion was first introduced by Fiat and Naor at CRYPTO 93 (Broadcast Encryption") but I do not know what the current state of the art is. |
|
May 13 |
comment |
Why is the following RSA PRNG cryptographically secure? Note 5.39 states that the assumption required for the PRNG to be secure is stronger, i.e. intractability of the RSA problem is not sufficient. In general that's a bad thing. We want weak assumptions. I'm not sure if that's what you meant, I just wanted to clarify that. |
|
May 7 |
comment |
What does $(\mathbb{Z}_n^*)^2$ mean? It could mean $\mathbb{Z}_n^*\times \mathbb{Z}_n^*$, i.e., the set of pairs of elements from $\mathbb{Z}_n^*$. A little bit of context might help. |
|
May 7 |
comment |
Indistinguishability attack example Just for the record: The solution I had in mind uses the fact that when you encrypt something blockwise using a fully deterministic algorithm any patterns you embed in the blocks will be visible in the ciphertext, too. So choose $m^{(0)}=a||a,m^{(1)}=a||b$, receive ciphertext $c=c_0||c_1$, if $c_0 = c_1$ output $0$, otherwise $1$. |
|
May 7 |
comment |
Indistinguishability attack example There seems to be some very basic misunderstanding of the experiment here. The adversary is absolutely free in their choice of $m^{(0)},m^{(1)}$. So even if there exists only a single pair that allows you to distinguish, that's fine because you can always choose that pair. Concerning your solution above: It was not the one I had in mind, but assuming that you choose $a,b,c,d$ such that $a \oplus b \neq c \oplus d$ it nevertheless should work. |
|
May 6 |
comment |
Indistinguishability attack example Choosing $m_0=m_1$ will never help you. You have to distinguish between the two cases. If the two cases are exactly the same, then they are perfectly indistinguishable for obvious reasons. So no, they have to differ. |
|
Apr 30 |
comment |
How to compare two datasets „anonymously”? I think private set intersection should be what you are looking for. |
|
Apr 27 |
comment |
Is OAEP reversible? Why would the hash-functions be unknown? Those should usually be considered public information. |
|
Apr 26 |
comment |
How can a key pair be derived from an arbitrary hash? You could simply seed the PRG used by your key generation algorithm using the hash you computed. That way the key-generation algorithm will always generate the same keypair. |
|
Apr 26 |
comment |
Algorithm digipass-like You would have to specify some kind of security you want to achieve. As the question currently stands, the solution is trivial. Use the identity function as E and check that the values are the same in D. |
|
Apr 18 |
comment |
How can I become familiar with the logic syntax used in Cryptography papers? Could you maybe give an example of the things you do not understand? |
