meta user
network profile
| bio | website | |
|---|---|---|
| location | Madrid, Spain | |
| age | ||
| visits | member for | 5 months |
| seen | 5 mins ago | |
| stats | profile views | 5 |
|
Mar 18 |
comment |
How to use GCM mode and associated-data properly Anyway, I'm now clear on how to use GCM mode - thanks. |
|
Mar 18 |
comment |
How to use GCM mode and associated-data properly Sorry to be a pain in the a$$ but I was under the impression that salts (whether for hashes or KDFs) didn't need to be secret. Is there an advantage to keeping them secret? |
|
Mar 18 |
comment |
How to use GCM mode and associated-data properly the nonce must be kept secret? I've never used CTR or GCM mode in production, but I understood that it's similar to the IV in CBC mode in that it isn't secret, and can be prepended to the ciphertext in the clear. Is that incorrect? |
|
Mar 17 |
comment |
How to use GCM mode and associated-data properly As for GCM mode already incorporating any params that could affect the outcome of the decryption, if I use PBKDF2 to generate a key from a password, and the iterations and salt (may) change for each encryption, then changing them would obviously affect the outcome of the decryption. GCM can't automatically incorporate these params unless it knows about them, so is it right to assume that they should be included as associated data? Thanks for your explanation... I gather that the Associated Data param works like the 'info' param in HKDF. |
|
Mar 15 |
comment |
BCrypt vs Key Stretching MD5 not an obvious reason, no. There are much, much stronger options which are quite commonplace, and not hard to implement. Look at the chart below; compared with PBKDF2 (using sha256, as below) key-stretching with MD5 and a similar number of iterations would be much weaker. |
|
Mar 15 |
comment |
What are the constraints for an IV using AES in CBC mode? For memory, the IV in CBC mode should not only be unique, but also cryptographically secure (as opposed to a mode like CTR, where the IV only needs to be unique). Would you consider the IV in this protocol to be CS? @StephenTouset 's suggestion to use GCM is good advice. |
|
Mar 15 |
comment |
BCrypt vs Key Stretching MD5 You mention the MD5 iteration count, but not the bcrypt work-factor - in terms of security, there's a relationship between the two. The (loose) recommendation for PBKDF2 using SHA256 (a much more robust hash than MD5) in 2013 is somewhere in the order of 50000 to 100000 iterations (and increasing exponentially), so 10000 iterations of MD5 doesn't seem very secure. For low-entropy input such as passwords, Scrypt is widely considered to offer better security than Bcrypt and PBKDF2. One disadvantage of Bcrypt is that the output length is not configurable. |
|
Mar 6 |
comment |
What should I be aware of when implementing algorithms myself? @PaytonTurnage - just for clarification, do you mean writing your own implementations from scratch (ie, from specs), or are you referring to porting code from one language to another? |
|
Mar 6 |
comment |
is AES secure for java application licensing @dendini: No, whether someone can decompile your app and distribute a cracked version (with code modified to bypass the licensing) has nothing to do with the licensing scheme (ie, RSA Digital Signature) you use. It can happen, and there's nothing you can do to prevent it. If you can't accept that then don't release your software. Take IlmariKaronen's and StephenTouset's advice: RSA is the best option. For java, the BouncyCastle APIs are easy to use, likewise with Openssl on the server-side. See here for easy cert generation. Note: an SSL Cert is not required. |
|
Mar 5 |
comment |
is AES secure for java application licensing Ok, so perhaps your question A) should state: "is there any known effective cryptanalysis of AES?"... to which the answer is no. |
|
Mar 5 |
comment |
is AES secure for java application licensing A) assumes that the license key can be decrypted and verified by the software, which logically requires that the AES key be embedded in the software. In this sense it ceases to be a 'secret' key, and thus, loses the confidentiality that secret-key cryptography provides. For this reason, using RSA would make much more sense. A) asks whether the attacker, for every instance of 'Y', can calculate 'Z'. The answer is yes, because obtaining the embedded secret key from the software is trivial, and not embedding the key would invalidate the scheme. |
|
Mar 5 |
comment |
is AES secure for java application licensing Let me answer your questions more explicitly: A) - Yes. B) Yes and no. No - using a public key sign/verify scheme is not useless. Yes - an attacker can decompile your app and do whatever they want with the code. |
|
Mar 4 |
comment |
Algorithm/Technique for Steganography Of course, there are lots variables, and results are subjective to the image. However, I've created my own steganographic app and modifying the LSB does not result in a discernable change to the image, even on flat-color such as a blue sky. Assume each pixel contains 3 color values, R, G and B. Each value is between 0 and 255. Modifying the LSB might (assuming the value you're encoding is 1 or 0) result in a change of 1. You're not going to notice a change of 1/255, especially when it's only in 1 of the 3 color channels. Of course, I'm talking about visual inspection, not computational. |
|
Mar 3 |
comment |
What information to include is the 'info' input for HKDF? According to the RFC, the IKM (input key material) listed in section 2.2 ('Step 1: Extract') is the key derivation data. The info parameter is defined as being optional. Also, section 3.1 stresses the importance of using a salt, stating that "the use of salt adds significantly to the strength of HKDF". Despite this - I think your answer makes sense. So I guess the info parameter is required only when using the same IKM for deriving multiple keys, in which case the info should contain data specific to that context. If anyone else has anything to add, I'd be interested to hear it. |
|
Mar 2 |
comment |
Why is CAMELLIA suddenly so widely used? @Jumbogram - yes, Yahoo is mentioned in the link that I posted. Still, that's the only one that I'm aware of. I certainly wouldn't say that Camellia is "widely used" (despite being a strong algorithm). |
|
Mar 1 |
comment |
Why is CAMELLIA suddenly so widely used? Personally - I've never seen Camellia in use in the wild. Could you post some links to sites which use it? (I'm curious). RC4 or AES seem to be the most common SSL algorithms these days. There's some discussion of Camellia here. |
|
Feb 27 |
comment |
Is Truecrypt's multiple/cascading encryption safe? That's exactly the kind of objective, sensible response to this question that I've been looking for - thank you. |
|
Feb 26 |
comment |
What information to include when calculating the HMAC of ciphertext So, the concern is that Alice encrypts a message, Mallory intercepts the ciphertext and modifies it, and Bob decrypts the modified ciphertext (without verifying it's integrity properly), resulting in incorrect decryption (which could help Mallory in launching a padding-oracle attack)? Excluding the metadata (such as IV) from the HMAC-calculation (or not using a HMAC at all) does not per se help Mallory decrypt the message successfully. Do I understand this correctly? |
|
Feb 26 |
comment |
Algorithm/Technique for Steganography You're right in saying that lossy formats like JPG are not suitable, but PNG is actually a (typically) lossless bitmap format, ideal for steganography - and it's used very commonly on the internet - unlikely to draw attention. The 'static' you refer to would not appear if you're only modifying the LSB. Modifying even the 2nd or 3rd least significant bits would only result in a difference that is difficult to discern with the human eye (depending on the image). Also, it's common to space out encoded information uniformly across an image, so as to be less conspicuous. |
|
Feb 21 |
comment |
Scrypt as a KDF with one-time high-entropy input thanks for the context - it's always helpful to know the 'why' instead of just the 'how to' |
