2,575 reputation
820
bio website touset.org
location San Francisco, CA
age 31
visits member for 2 years, 7 months
seen yesterday

Cyclist. Rubyist.


2d
comment Is it possible to make a more secure random number generator algorithm by XORing two or more less secure random number algorithms?
It's possible to improve two bad ones (for example, two truly random numbers which were provided and recorded by the NSA and GCHQ respectively, who for the sake of argument have no ability to communicate with each other or the rest of the world whatsoever). It's also possible (and dramatically more likely) for the combined construct to either fail to improve the security or worse, to worsen security when compared to each independently (like the LCG example in the post).
Feb
24
comment Could overlapping SHA256 hash begin to loop at some point?
The user submits their guess before they know anything about the outcome of the roll. What's the opportunity for a user to cheat?
Feb
23
comment Could overlapping SHA256 hash begin to loop at some point?
If it's a simple dice game, it's likely that all you need to do is perform a simple commitment scheme prior to a user making their choice. For instance, generate a random 256-bit value, and use those bits somehow to determine the outcome of the die roll. Before a user submits their guess, publish the hash of the value you used. Once the game is complete, publish the original value.
Feb
23
comment is encrypted body http secure
IV's should be rotated every time you encrypt data, not simply each "session".
Feb
20
comment Is “password knocking” a good idea?
Something like bcrypt is a far better way to slow down an attacker, as that also helps even if the attacker has your hashed passwords. Regardless, the latency of two extra requests to the server could be trivially simulated by calling sleep.
Feb
20
awarded  Nice Answer
Feb
20
comment Is “password knocking” a good idea?
To be more clear, if you consider typing this password in, your effective password is literally 123<Enter>456<Enter>789. You could argue that an attacker wouldn't know to hit enter at those precise locations, but that argument could be made for any character that could be typed there. This would be no different than if your password was instead 123|456|789. Ask yourself, when considering the literal act of sitting at a keyboard and typing in this password, what somehow grants the Enter key additional security over the | key.
Feb
20
comment Is “password knocking” a good idea?
But that is precisely mathematically equivalent to having those three passwords concatenated. If your "first" password is "123", your second password is "456", and your "third" password is "789", an attacker must spend the same amount of effort as if they were attempting to guess the single password "123456789". With the argument that they might not know that this is your scheme, that is true of the password itself; the attacker does not know that it's a nine-character password (or, equivalently, three three-character passwords). They must try all combinations until they find the right one.
Feb
20
comment Is “password knocking” a good idea?
@AviD I feel like this result must be patently obvious. Your password is literally now A <Submit> B <Submit> C. They are now simply concatenated by using the Return key.
Feb
20
comment Is “password knocking” a good idea?
@IsmaelMiguel You may continue to disagree all you like, but as members of the community have attempted to explain to you through several different approaches, the strength of the proposed scheme is virtually indistinguishable from concatenating the individual passwords.
Feb
19
comment Is “password knocking” a good idea?
If an attacker doesn't know your password is A || B || C, s/he will have to try each possible password once and most likely will never find the correct sequence. So yeah, it is the case. If an attacker has A, B, and C, you've lost regardless.
Feb
19
answered Is “password knocking” a good idea?
Feb
17
comment Is it necessary to encrypt nonce in cryptographic communication?
Assume, for the sake of argument, that M is exactly one AES block in length. CBC ciphertexts are malleable, so an attacker can trivially garble the component of the ciphertext containing the nonce. If you don't check that the nonce is one that you have previously sent (and not simply one you haven't seen before), an attacker will be able to replay any message he pleases. You may want to a) use CTR and have an incrementing IV and no nonce, b) use an AEAD mode like GCM with the nonce as the AAD instead of part of the plaintext, or c) just use TLS and avoid reinventing the wheel.
Feb
17
comment Is it necessary to encrypt nonce in cryptographic communication?
Your notation appears to indicate you would reuse a pair K/IV pair for the second encryption. Independent of the answer to this, never reuse an IV with the same key.
Feb
9
comment Are credit card number look ups more secure with a hash function than with a deterministic encryption algorithm?
Hashing doesn't help you here, even with bcrypt and scrypt. There are only 15 "free" digits in a credit card (the last number is a check digit), leaving log2(10^15) or roughly 50 bits of entropy. Worse, card tokens are frequently stored alongside their cleartext bin number (the first six digits) and their last four digits. This leaves only five digits, or less than six bits of entropy to break any individual card. Long story short, your best option is likely to use an HMAC with a key stored in an HSM.
Feb
6
answered How to retrieve the MAC address of a remote IP
Feb
4
comment What is the ideal HMAC message format if message is an array?
There is no "best" way, insofar as there are only ways that satisfy that requirement, and there are ways that don't. I'd suggest any method is "best" that is obviously correct and, secondarily, produces the smallest inputs to the HMAC function (to reduce the number of calls to the underlying compression function and therefore maximizing performance).
Feb
4
comment What is the ideal HMAC message format if message is an array?
The only requirement I am aware of is that each unique associative array must map onto a single, unique byte representation.
Jan
29
comment Using AES in CTR for TCP/IP based network connections - need to encrypt the IVs?
First, there exist non-RSA ciphersuites for TLS (e.g., ECDHE-ECDSA-AES128-GCM-SHA256, which is based on elliptic curves and have bit lengths on par with symmetric encryption). Second, even then it doesn't matter because 4,096-bit RSA is fine — the bit length is almost entirely irrelevant as long as it's large enough to provide the margin of security you're looking for given the choice of algorithm. And regardless, whatever home-brew system you concoct is infinitely more likely to be a source of weakness than 4,096-bit RSA keys.
Jan
28
comment Using AES in CTR for TCP/IP based network connections - need to encrypt the IVs?
Based on what relevant experience and/or expertise do you make that claim? SSL (secure sockets layer) was designed to protect virtually any streaming socket (e.g., TCP), not as a secure HTTP layer. It has been put to use countless application-level protocols on top of TCP. And it doesn't matter that you also support HTTPS; you're only as secure as your weakest link, and if that weak link ends up being your homegrown transport protocol, that's the one attackers will exploit.