285 reputation
18
bio website
location
age
visits member for 2 years, 2 months
seen Oct 23 at 15:36

Jan
23
comment Understanding padding oracles - is an attack plausible in my scenario?
The vector I see for the padding oracle attack is to impersonate the server during a legitimate user's login, and pass back malformed chosen plaintexts. The server isn't encrypting or decrypting anything; it simply accepts, stores, then retrieved and sends data already encrypted by the client. The attacker would have to be "on" the computer receiving these packets as well, in order to get the error message. The client app won't tell the server that the data it was given was bad; it tells the user that decryption failed (in so many words).
Jan
23
comment Understanding padding oracles - is an attack plausible in my scenario?
Anyway, dropping the SHA-512 key-"lengthening" (I won't call it "stretching" anymore) in favor of PBKDF2 for the AES key derivation would require some other way to send the password securely. BCrypting it on the client before sending it is totally an option (it's what we're doing now). So is knuckling under and setting up a PKI in our network, giving the DB a certificate and using TLS-secured communications to the DB server.
Jan
23
comment Understanding padding oracles - is an attack plausible in my scenario?
I didn't say I was disagreeing with you; you stated that you didn't quite understand what was going on, and assumptions you seemed to make about what's done where were incorrect, so I was explaining. I totally agree there is a huge hole in the AES key derivation method.
Jan
23
comment Understanding padding oracles - is an attack plausible in my scenario?
As built, however, there is no service layer performing any validation, so data is easy to get, and an attack could then be performed offline. The vector is still brute-forcing the password, not trying to reverse-engineer the plaintext. I still see no vector for a padding oracle attack that wouldn't require enough control over a legitimate user's system to simply install a keylogger.
Jan
23
comment Understanding padding oracles - is an attack plausible in my scenario?
As designed, the scheme uses a service layer to do the BCrypting and initial password validation, before returning the encrypted credentials for decryption by the client. So, the initial round of SHA-512 was partially to obfuscate the password on its way to the server. Pre-imaging this hash naively with just the data seen on the wire would be difficult and would not necessarily produce the correct other half of the actual hash (but trying common passwords might). The encrypted data coming back is, well, encrypted, and the key is never sent over the wire, so that data's safe as well.
Jan
23
comment Understanding padding oracles - is an attack plausible in my scenario?
The symmetric decryption happens in a thick client application accessing a database server. Theoretically, this all happens inside a trusted network in the first place, but I'm trying to add some defense in depth because we've seen a few holes, and plaintext credentials in the DB are just a Very Bad Thing. The original scheme as designed assumed that connections from client to server couldn't use TLS, which currently holds. Therefore, the idea was that an attacker who'd penetrated the outer defense could never sniff credentials as they were passed back and forth inside our trusted network.
Jan
23
comment Understanding padding oracles - is an attack plausible in my scenario?
The user has a password to the application. That application must authenticate with a third party, in my case a cloud provider, using a separate set of credentials. These credentials must be secured in reversible fashion; they can't be BCrypted like the main application password, because the client app needs them in plain text to send to the cloud provider.
Dec
13
comment Is AES in CBC mode secure if a known and/or fixed IV is used?
... Except that in my case I'm using a PBKDF, and SymmetricAlgorithm.CreateEncryptor() doesn't have an overload accepting only a key.
Dec
11
comment How are primes generated for RSA?
The generation of a random number of the proper length as a stream of bits is pretty much the same as flipping a coin 2048 times. While the hamming weight of the numbers produced (basically the number of "1"s in the bitstream) follows a binomial distribution (pretty much by definition), the actual numbers a CSPRNG produces are designed to be evenly distributed. There is theoretically an equal chance of getting the number 1 as there is of any other number. However, pseudorandomness isn't true randomness, and anyone that saw a PRNG produce a string of 2047 zeroes and one 1 would say it's broken.
Dec
3
comment Weakness in using only one RSA key pair for two-way communication?
As far as padding, see my edited question; let's assume OEAP padding. "Secure" is defined as Cindy not being able to discover the plaintexts of either message given only the ciphertexts; we can assume that Cindy has no access to Alice or Bob's plaintext messages on either end (before encryption or after decryption), or their keys.
Dec
3
comment Weakness in using only one RSA key pair for two-way communication?
@CodesInChaos - Obviously there are other possible solutions when secure key transmission is possible. I was merely curious if the inverse-operation nature of the RSA scheme could be used as a two-way communication channel, or if being able to see messages enciphered using both keys would present a mathematical vulnerability.
Dec
3
comment Weakness in using only one RSA key pair for two-way communication?
@fgrieu - Cindy does not know any part of the keyset including the shared modulo. She does not know any plaintexts involved. All she can see are the ciphertexts passed back and forth.
Dec
3
comment Weakness in using only one RSA key pair for two-way communication?
@RickyDemer For the sake of argument we'll say both parties are padding using OAEP.
Dec
3
comment Weakness in using only one RSA key pair for two-way communication?
By "encrypting with the secret key", I mean that by Wikipedia, a decryption exponent d can be derived from e and n, and given that, the decryption formula is nearly identical to the encryption formula. Alice's key is (e,n) and Bob's is (d,n). Since the two modulo operations are shown to be inverses, the only question in my mind is whether Cindy could derive d and e by seeing messages encrypted with both exponents (but not their plaintexts).
Dec
1
comment Weakness in using only one RSA key pair for two-way communication?
By half, I mean that both parties are in possession of an RSA key, the two keys forming a normal asymmetric key pair. Usually, this keypair provides a one-way channel by distributing a public key to encrypt and keeping the other secret to decrypt; however, if both keys of the keypair were considered "private" (the keys were securely transmitted), and each side used their key both to encrypt messages they were sending and decrypt messages they received, would the encryption still be secure, or would the math allow a user to derive the keys given only the ciphertexts encrypted with each key?
Dec
1
comment Weakness in using only one RSA key pair for two-way communication?
How would that make a difference?
Nov
19
comment Is this a valid real-time authentication scheme?
RSA doesn't differentiate between "encrypting" and "decrypting" keys; given a pair of them, you can encrypt with either one and then decrypt with the other. While it may become possible to discover both keys given the plaintexts and ciphertexts as encrypted with each half of the pair, it can't be done until the purpose of the process has been accomplished, at which time those keys are discarded.
Nov
19
comment Is this a valid real-time authentication scheme?
Ah. got it. Well, this is still two-way; most clients don't have X.509 certificates, but you could use it to have two clients of the same secure server handshake and trust each other based on them both being authenticated by the server, with disposable proof of authentication between the two clients that does not involve exchanging the credentials or authentication results from their server auth.
Nov
19
comment Is this a valid real-time authentication scheme?
MACs can be spoofed, and long-term-use keys like in signatures can be cracked. The key pair in question here is used for a couple of seconds at most, it's near useless forever after, and the only thing it tests is that both Alice and Bob know Cindy well enough to get the two halves of the key pair, and thus that they should trust each other. The information actually encrypted with it would be plainly visible to any man in the middle, and as long as the information is highly unlikely to be repeated, that's just fine.
Oct
18
comment Is AES in CBC mode secure if a known and/or fixed IV is used?
Yeah, I wasn't going to use System.Random no matter what. .NET has a CSPRNG built in that's easy enough to use, especially to generate byte arrays