435 reputation
18
bio website
location
age
visits member for 8 months
seen Oct 7 '13 at 16:07

Sep
15
comment bcrypt and pbkdf2 double hashing
Why would you even consider the possibility that F(G(·)) is hard to invert? If this is a tangible possibility, it means that there is some message m that is considered weak - namely F(m) is not hard to invert (in your scenario, we declare m = G(·) ). Is there a message that is considered weak for any of the common hash functions?
Sep
9
comment Should we trust the NIST-recommended ECC parameters?
When you ask "can we trust these parameters", I see in front of me Schneier's comment "Cryptographers are a conservative bunch: We don't like to use algorithms that have even a whiff of a problem". Since there is a legitimate concern now among the memebrs of the community who are tasked with applying the standards in real-life products, the onus is on the standards body, namely NIST, to come up with a good explanation about the source of these parameters. As long as they decline, I'd say to avoid anything based on those parameters.
Sep
7
comment Is javascript RSA signing safe?
All those negatives may or may not be practically meaningful - depending upon the application and environment. The Stanford's SJCL is a reasonable implementation, including the Fortuna-based RNG (granted that, since JS can't access system params as native apps do, the available entropy pool is not as strong, but it is still reasonable for practical use). If you download the code not as embedded in HTML page but as a packaged file to run locally (with a hash fingerprint), then I would consider it trustworthy. To fend off mistakes, need to run some test vectors during code review.
Aug
25
comment Do ciphertexts leak information about their algorithmic creators?
1.If an attacker carries a futuristic computer such that iterating through 2^128 key space would be feasible, she would still have to go through k key-space cycles - in effect the strength is increased to 128 + log2(k) 2. If we talk about practical attacks, the only option that I see is finding a weakness in an algorithm, let's say reducing its cipher strength to a barely feasible 2^70. Such weakness will surely impose months of effort to decrypt but has a chance of only 1:k to succeed if the algorithm is not known - again increasing the strength of my proposal by a work factor of k.
Aug
25
comment Do ciphertexts leak information about their algorithmic creators?
Now, why aren't you sure that I can realize 128+k cipher strength of I choose one among k encryption engines (assuming a PW of 128 strength or more) ? please consider the following 2 scenarios: (continued)
Aug
25
comment Do ciphertexts leak information about their algorithmic creators?
@ Henrick: I fail to see the applicability of the password substitution example you provided, since attacks on passwords carry different methodology compared to attacks on cipertexts. Just as side note, I think that with your PW example I will increase the strength if I choose a consistent (i.e. non-random) substitution character(s) outside the 7-bit ANSI range, since dictionary attacks will fail on that. (continued)
Aug
25
comment Do ciphertexts leak information about their algorithmic creators?
@Fixee - I have a difficulty following your nuance in terminology. In commercial programs and books I looked at, although there is a noticable tilt toward defining cipher as a building block of an encryption algorithm, many use cipher and encryption process interchangeably. openSSL, for example, calls blowfish AES etc ciphers. See openssl.org/docs/apps/enc.html . And openSSL and various books do refer to IV as an injectable entity to Feistel block cipher in AES for randomization, so the concept does seem to apply. Anyway, I assume that from my detailed scenario my intent was clear.
Aug
24
comment Do ciphertexts leak information about their algorithmic creators?
@Fixee: I meant an encryption engine using a block cipher - an approved cipher engine like AES-128, Twofish, Serpent etc. So if, as you claim, there are some indications as to a known IV structure in some ciphers, then one can deduce for example, seeing a 256 bit IV, that engines of 128 bit have not been used in the process. This is my concern: since algorithms used are normally public knowledge and are not meant to be secret, they might leak some info out. I wonder if the literature has any info on this.
Aug
24
comment Do ciphertexts leak information about their algorithmic creators?
I am more concerned about out-in-the-field good crypto program, not a theoretical cipher. If a practical cipher whould produce a perfect random output, we could have used it as a perfect RNG, which is not the case. So I wonder if any approved cipher engine out there (e.g. AES-128, Twofish, Serpent etc) might somehow leak out a characteristic tell-tale sign of their algorithm. I guess that an answer to this question may appear in some cryptanalysis paper, but I don't know of any.
Aug
23
comment Keepass Twofish plugin security
@Thomas - Thank you. I will investigate the code further.
Aug
21
comment Will our app be FIPS 140-2 compliant if we use our own AES algorithm implementation?
@poncho: I looked again at my prior reference, and suddenly it is not clear anymore. You might be right. However, an interesting easy read about what we can expect from FIPS is here tinyurl.com/fips140 , and this is an interesting quote: "It ensures that you're using only FIPS-approved algorithms, and only in a way that's specified by NIST. Finally, validation will tell you whether you're implementing those algorithms correctly -- or more accurately, whether your outputs match a set of test vectors provided by your testing lab, which is mostly, but not entirely the same thing."
Aug
21
comment Will our app be FIPS 140-2 compliant if we use our own AES algorithm implementation?
To clarify what poncho said in "Use a FIPS-certified library to perform all the FIPS-approved crypto operations" - to be certified for FIPS 140-2 compliance, you still need to submit your application to a testing lab so they can verify that you did apply the library modules correctly. Using certified modules will help in the certification process, since the lab need not analyze the crypto modules themselves - just the implementation.
Aug
17
comment Are there cryptographic hash functions that can be computed using only paper and pen without leaking any information about the plaintext?
@vyu - if this has a practical application, please explain the environment a bit better: assume that you are in an insecure environment, and try to regenerate your PW. You would do this only in order to get back your private PGP/X.509 keys, and later use those keys to decrypt a ciphertext or deal with clear text. Either the decrypting of the keys using the regenerated PW or subsequent operations require a computer - and no more secrets on that computer, therefore it must be a secured computer. Why can't you also regenerate your hashed PW on that computer? Why only mental PW decryption allowed?
Aug
17
comment Are there cryptographic hash functions that can be computed using only paper and pen without leaking any information about the plaintext?
It is also important to know if the adversary has a use of a computer - in that case, as nightcracker indicated, don't expect any security from this process. If he has only brain+paper, then you may come up with something. I'd say that for any practical PW creation application, it would be much better to spent the alloted time to mentally(+pen-paper) compose a high-entropy PW whithout coming up with a actual mental hashing function which most probably would be a one-shot affair.
Aug
17
comment Are there cryptographic hash functions that can be computed using only paper and pen without leaking any information about the plaintext?
I guess that this an academical assignment whereby the instructor would want you to show your understanding of hashing, secrecy and security in an interesting way. In that case, it requires quite a bit of analytical effort which I doubt you will get it here. Otherwise, I can't see any practical application to your requeirements, since I can't fathom a person doing hours of calculations to come up with a high-entropy PW and still expect to remember all steps after a few weeks, when he wants to regenenerate it. (continued)
Aug
12
comment AES encryption using a Diffie-Hellman key exchange
@tylo while you come from the cryptographic agorithm point of view, I tried to answer from a application usage point of view. Judging from the question, I take it that the user has a AES encryption application, needs to enter a password, and wonder how to exchange that password with a remote user. I would dare to say that your response, as well as the others here, are too technical for the OP.
Aug
6
comment Achieving 256-bit encryption strength with PBKDF2 - HMAC-SHA1
Now about the inability to increase "entropy" going through a deterministic function - if I judge "entropy" in a sense of a "strength against attack" contained in a password, don't I increase the strength, hence "entropy", by deterministically iterating n times through the hash?
Aug
6
comment Achieving 256-bit encryption strength with PBKDF2 - HMAC-SHA1
@Henrick Thanks you for the formal answer. Regarding your addendum, I am not sure about your claim: The thermodynamic property is very well defined, and a closed thermodynamic system doing work will always have its entropy increased - never staying the same or decreasing. Since there is a "chaotic" element to the natural progression of such systems, cryptographers borrowed that term for their use - but, as you say, "entropy" in the crypto world can go down or stay the same.
Aug
5
comment Achieving 256-bit encryption strength with PBKDF2 - HMAC-SHA1
Thanks for the help and explanation. Your solution will work for me. Sorry that I can't vote you up, but if you post it as an answer, I'd certainly accept it.
Aug
5
comment Achieving 256-bit encryption strength with PBKDF2 - HMAC-SHA1
@Henrik - I would also appreciate it if you could explain why applying the Skein hash "before" is stronger than applying "after". The only thing that comes to my amaturish mind is that this would be the case only if the intial password strength was more than 160 bits (for simplicity of the argument I assume here just 1 iteration through the PBKDF2), thus being strength-truncated by the SHA1.