Tag Info

New answers tagged

0

The data is protected. The attacker can't decrypt its contents, not even with the (partial) plaintext (otherwise we would be talking of AES as a broken cipher). However, you also need to protect the integrity. For example suppose that the survey contains some Yes/No questions and we were encrypting in CTR mode. If Eve has access to the answers to the ...


2

I would highly recommend you look at redesigning your solution to be able to use a hash, rather than either work with anything other than a one-way hash. If you absolutely need to work with the cleartext password, it should be encrypted using a a high level library like NaCl (http://nacl.cr.yp.to/). Symmetric vs. public-key encryption will be a function ...


5

Yeah, if you are describing it accurately this is completely broken, to the point of useless. The initial AES key is compromised by being in the app, anyone with the app has access to the AES key. If this is global, then it is well and truly screwed, if it is unique to each application, there may be a small sliver of hope. The SHA-1 is completely ...


4

Well, the AES key embedded in the library is completely useless, and there seems to be no validation of the server side. I see many problems with this scheme. Anyone with access to the Android library can extract the AES key. Sending a hash of a static value over plain HTTP is the same as sending a password over plain HTTP. Anyone can grab it from ...


2

The core of GCM is CTR: successive values of a counter are encrypted with AES (each value is represented over a 16-byte block), thus generating a key-dependent pseudorandom stream. Actually encryption (and decryption as well) is done by XORing that stream with the data to encrypt. The XOR is done bit by bit and can be stopped at any length without any need ...


2

Hashes are not meant to be reversed, and so there is no way you use a hash algorithm to protect a password and see the plain-text later. What you can do is use a proper encryption algorithms or public and private keys to encrypt and decrypt the passwords, for example PGP.


2

1). No, assuming a secure block-cipher mode (e.g., CBC, CTR) was used (basically any mode other than ECB) provided the initialization vectors are not reused. With ECB mode you could match up messages with patterns of repeated blocks in the plaintext to corresponding repeated blocks in the ciphertext. See ECB description on wikipedia for more. Reusing ...


6

The quick answer is NO, you can not. A detailed answer: On this official documentation, you can read: When only the key is specified using the -K option, the IV must explicitly be defined. When a password is being specified using one of the other options, the IV is generated from this password. IV stands for Initialization Vector. You can ...


4

"AES-128" means "AES used with a 128-bit key". "AES-256" means "AES used with a 256-bit key". By definition, you should use a 128-bit key with AES-128, and a 256-bit key with AES-256. What happens when you give a 256-bit key to AES-128, or a 128-bit key to AES-256 ? By all rights, it should blow up in your face. However, some implementations are more ...


0

Very unreasonable. The first question I think you need to ask is if file encryption is necessary. Based on your question it sounds like the answer is yes. To me that means that you A) should implement file encryption and B) do it well. What you describe is A but not B which is arguably worse than nothing at all because it may give your users a false ...


4

Consequences of an IV reuse range from "serious" to "dramatic", depending on the encryption mode. AES, by itself, is a block cipher: it processes blocks of 128 bits. When encrypting a message (with a length other than exactly 16 bytes), one must use a block cipher mode of operation. Many such modes are "sequential" in some way, with a running state, and the ...


0

I'm no expert either, but from what I understand, the actual payload is encrypted with a random (supposedly unique) IV for each packet, which is the right way to do things. It doesn't matter that the payloads are very similar. The header, on the contrary, is very susceptible to attacks (see this question for a more thorough explanation), but since it's ...


1

What you have explained sounds similar to WEP encryption for 802.11. I am not a cryptologist either, but have read through the Aircrack-ng docs quite a few times. Using this encryption technique for a static data set opens the application to statistical based attacks such as Korek and FMS. A deep explanation of how these attacks are done on WEP can be found ...


4

AES is encryption; it is meant to maintain confidentiality. Encryption does not maintain integrity by itself: an attacker who can access encrypted data can modify the bytes, thereby impacting the cleartext data (though the encryption makes the task a bit harder for the attacker, it is not as infeasible as is often assumed). To get integrity, you need a MAC, ...


2

My flash has password protected and I do not know password. Is it possible, to crack password in some way? Short answer: No, since neither me nor you know how the device operates inside. Long answer: This requires a lot of knowledge on how this specific device implements the claimed Enterprise-Grade Security. My best bet would be, most of users here ...


4

Sounds like you're well on your way to figuring this out. I've never exploited ECB chosen plaintext, but I recently did a padding oracle exploit, so I've got some idea how you would do this. The basic idea is to brute force one byte at a time. Just suppose we have a simple example where there is no other data inserted so it's just "[username][secret]". ...



Top 50 recent answers are included