Tag Info

New answers tagged

0

There are several libraries that allow for authenticated encryption in .NET. Bouncy Castle, mentioned in an earlier answer, is not. Microsoft itself offers an open source library that is quite low-level, just wrapping the CNG APIs that offer authenticated symmetric encryption in Windows, called CLR Security. The CLR Security library is going to be the ...


0

For the first question you can use openssl for decryption: $ openssl enc <MODE> <ENC/DECRYPT> -in <INPUT_FILE> -out <OUTPUT_FILE> As an example: $ openssl enc -aes-256-cbc -d -in encrypted.VHD -out decrypted.VHD See this list of system recovery tools for linux distributions: SystemRescueCD, gddrescue and testdisk. The later ...


0

This is probably a little late but just as a recommendation for other people who stumble on this. For this type of problem I would always use ProtectedData over rolling your own implementation with AesManaged for two reasons. First, you don't need to deal with managing cryptographic keys with ProtectedData which is a hassle to do correctly. Second, there's a ...


1

I will keep my members password in database with SHA-512 hash. I will use SALT for password. So i will keep SALT keys in database for each member. Is it safe and ok to implement that way? Yes, if you are using salt (which you should) then you should store the salt (in the clear) alongside the hash. Should i keep IV (Initialization Vector) in the ...


-1

Is not the solution to encrypt with the recipient's public key? Anybody could have written it but only the intended receiver can read it.


1

I'll step by step and then overall crypto system, seems most logical to me. Generate a new AES 256bit/CBC/PKCS7 Master Key (Km) Generate a new 128bit IV (strong PRNG) CBC is fine here as there isn't any sort of oracle the attacker would have access to and bit-flipping attacks are ruled out by the tag. Random IV is correct, 256 bits is more than ...


2

The salt is here to prevent cost sharing by attackers. If two passwords are hashed with the same salt, then an attacker could hash a potential password using that salt value, and compare the output with the hashed versions of the two passwords; in other words, the attacker can attack the two hashed passwords for the cost of attacking one. This scales up: if ...


0

The main purpose of the salt is to protect against rainbow table attacks. There are different scenarios: If you do not use salts, an attacker could already have a rainbow table ready to start attacking your passwords. If you use the same salt for every entry, the attacker would need to generate a new rainbow table based on your salt, which he could then ...


1

Knowing the timestamp would help an attacker only if it affects any of the other token parts. If your IV is dependent on the timestamp, then you've failed already. Getting the entropy of the IV from something that is not dependent of the time it was created is the best way to solve this. On a higher level knowing the creation time of a token could help the ...


2

Block ciphers like CBC require an input as multiple of the block size. In this case P would need to be padded to be one block long. Another thing to notice is that the first block of P is being XORed with the IV which is also one block long - this will also ensure that you start with an input data of size which is at least one block long. Being a block ...


30

All of the weaknesses in your protocol can be summed up as "use SSL" or even "use SSL, dammit !". In more details: All the protocol is of course vulnerable to impersonation, specifically the double impersonation that is also known as Man-in-the-Middle attack. Similarly, if any of potential attackers that can eavesdrop on the line decides to do a ...


12

No this protocol isn't safe. As already mentioned in the comments: Don't roll your own crypto. Chances are you're getting it wrong. Especially if you admit that you don't really know what you're doing. First, you seem to have standard problems for which there are already standard protocols, which have nice properties and security proofs. The protocol for ...


-4

It's pretty good but I would do this in an easier manner which I think is more secure and similar to what you thought of. Since the communication is client-server: Mobile client generates key using PRNG Client sends step 1 key using server public key (only server has private to decrypt) Client encrypts user/password with step 1 key and sends to server If ...


5

Device generates private RSA key, and sends the public key to server. Server generates unique to user AES key and uses the RSA public key to encrypt it and send it back to device. Device gets the AES key. Uses it to encrypt password and username and sends it to the server. Anonymous key exchange. There is no authentication. Your key exchange ...


0

There was a time when some cryptographers considered it infeasible for an attacker to find a P and K so as to produce a given C through AES, and there were attempts to build hash functions from AES based on this assumption. But, hash functions based on AES did not turn out to be as secure as other hashing algorithms (see Why AES is not used for secure ...


5

No. Not with the key alone. If you have a known plaintext and a known cipher text then the problem of getting the key from that is known as a "known plaintext attack". And any modern crypto system, including AES, is hardened against this. Several terabytes of plaintext/cipher text pairs will still not allow you to get at the key within reasonable time. ...


1

Initialization vectors aren't meant to be private. The goal of an IV isn't to strengthen the key but to make sure that no two identical (or similar) clear text will result in the same (or similar) cipher text. It works like this: AES (along with most - but not all - modern crypto algorithm) is a block cipher. It only operate on a fixed amount of data (in ...


6

For password-based encryption, you need to: transform the password into a key suitable for the encryption algorithm (a process called key derivation); use that key to encrypt the file. Assuming that everything about the encryption phase was done properly, and the used algorithm is not weak, then the most direct attack route is the password: the attacker ...



Top 50 recent answers are included