meta user
network profile
| bio | website | google.com |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 1 year, 8 months |
| seen | 20 hours ago | |
| stats | profile views | 23 |
|
Apr 25 |
comment |
repeating-key xor and hamming distance My best guess is that one is hoping that the plaintext is sparse. $\:$ |
|
Apr 25 |
answered | Tamper-proofing log files |
|
Apr 24 |
comment |
Combining AEAD with RSA We only necessarily have that "weak authentication" if the core public key scheme is at least RCCA secure. For (standard) authentication the sender needs either a pre-established secret or access to a manual channel (eprint.iacr.org/2007/131.pdf). $\;\;$ |
|
Apr 24 |
answered | Which public key was used. PGP |
|
Apr 24 |
comment |
Combining AEAD with RSA "The symmetric key used by AES would be randomly generated" by anyone "who knows your public key". |
|
Apr 24 |
comment |
Combining AEAD with RSA That would take slightly more computation. $\:$ |
|
Apr 24 |
answered | Combining AEAD with RSA |
|
Apr 24 |
comment |
Which public key was used. PGP I seem to remember having read (either here or at security.SE) that PGP $\hspace{1.8 in}$ intentionally makes it easy to do that. $\:$ |
|
Apr 24 |
comment |
Tamper-proofing log files Yes, in this case, since you will have to keep state anyway, IV generation won't be an issue. $\;\;$ |
|
Apr 24 |
comment |
Tamper-proofing log files Yes. $\:$ I don't know what "AAD" is, so it might be correct to include the IV in it. $\:$ However, with $\hspace{.4 in}$ AEAD, the only thing to worry about is IV generation. $\;\;$ |
|
Apr 24 |
comment |
Tamper-proofing log files So far, none of the proposed methods give any integrity protection after a compromise of the logger. |
|
Apr 24 |
comment |
Tamper-proofing log files In what sense does that give you "integrity and authenticity"? $\:$ (Hint: it's not the right sense.) |
|
Apr 24 |
comment |
What happen if a asymmetric crypto-system deals with only one key What was your last sentence supposed to say? $\:$ |
|
Apr 23 |
comment |
Using the output of a stream cipher, how to guarantee the integrity of 4 bytes of data? Is the problem that your messages will usually be just 4 bytes, but might sometimes be much longer? |
|
Apr 20 |
comment |
A lower bound on the insecurity of CipherCloud? They do specifically say "of Salesforce". $\:$ |
|
Apr 20 |
comment |
A lower bound on the insecurity of CipherCloud? What you have now is farther from correct than what you had originally. $\:$ |
|
Apr 20 |
answered | A lower bound on the insecurity of CipherCloud? |
|
Apr 20 |
comment |
A lower bound on the insecurity of CipherCloud? I think their lower bound is the $\;\; \log(\sqrt{m}\hspace{.01 in}) \: = \: \frac12 \cdot \log(m) \;\;$ high-order bits of a given message. $\;\;\;\;$ |
|
Apr 19 |
comment |
Can prepending “junk” be equivalent to an IV when encrypting using CBC? Choose n uniformly from [0,2^118) and then store AES(k,(1000*n)+123). $\hspace{1.7 in}$ |
|
Apr 18 |
comment |
GPG and PAR2 error correction data from the plain archive, will it compromise security? The first alternative considered in this answer will work as long as the user makes sure that each file is encrypted separately and that each ciphertext is stored as its own file. $\:$ |
