# Tag Info

3

A message encrypted with AES-GCM can be decrypted with an AES-CTR library IF the authentication tag is stripped from the message. If you are encrypting with AES-GCM and then adding an HMAC tag, you need to strip the HMAC and the GTAG off the message in order to decrypt it, assuming the IV section of the message is in the correct location for each library to ...

2

First lets acknowledge this is a horrible hack - you really should find a way to do what you want more directly or risk code maintenance issues and likely bugs in the future. Second, while the question isn't about your key strengthening step it seems like you should ask about the security. There are lots of good key derivation methods out there and I don't ...

2

I did some more research and yes it does include both AD length and ciphertext length, so is not vulnerable to a length extension attack as length is part of GCM GHASH. Based on NIST SP-800-38D (PDF) page 18 len(A) and len(C) are both part of the input into the GHASH function. And double-checked this in an implementation gcm_finish method: both lengths are ...

2

Fgrieu has already posted a good answer, which I won't try to repeat. However, here are a few additional observations: For an embedded system, you may want to consider using CMAC-AES instead of HMAC, since you can reuse your AES implementation, and don't need a separate hash function. Further consider using SIV mode (RFC 5297). It's very similar to ...

2

Dmitry's suggestion to use AES in counter mode sounds good to me, assuming that you only need confidentiality, and not integrity protection. (Counter mode, like most stream ciphers, is very malleable.) One trick you can use to save a bit of space is to use the current time as part of the nonce. (Of course, this only works if your devices have fairly well ...

2

A self-made modification to CBC is a bad idea, since your "IV" will not be random enough, whereas it must be truly random for CBC. Stream cipher is a good idea. You may use AES in the Counter mode, or you could use Salsa20, or any other eStream portfolio cipher (software and hardware implementations are available for all of them). Ensure that you have ...

2

Why not using VeraCrypt http://en.wikipedia.org/wiki/VeraCrypt, which is a successor of the famous discontinuited TrueCrypt. VeraCrypt is open source, and was developped by M. Idrassi an crypto-expert, take a look at https://github.com/veracrypt/VeraCrypt . There was controversy about the TrueCrypt, mysterious stoping. VeraCrypt corrected some know flaws and ...

1

Not a definite answer but too much for comments: That help msg shows that OpenSSL on OSX is an old version (<= 0.9.8) before GCM was added. (Probably =; 0.9.7 end-of-lifed around 2008. -salt has been the default since about 2004 so anyone who claims you need to specify it should be treated very skeptically.) You could add HMAC on top of AES-CBC ...

1

You are correct: if the AddRoundKey step is skipped, no key material is ever used, so decryption is trivial. In case of using a bitwise OR, information would be lost in the encryption process. XOR is reversible, but OR isn't, so no decryption would be possible.

1

It doesn't make too much sense at all to send the IV together with the key. The whole idea of an IV is that it is unique per key. But if the key changes value each time, then any IV is unique. So you could use a static IV or even an IV that consists of all zeros. In that case you only need to worry that you don't reuse the key at other locations in the ...

1

It depends on the format. The size suggests it is a video. However, video formats seems to be designed to be seekable. That means, the attacker seems to be able to: Create some header (guessing the resolution and some other information) If the beginning was damaged, play and seek in the file.

1

Information leakage in systems that do data deduplication typically involves timing hints that the data is already stored and related leverage of that information. See the comments in Online backup : how could encryption and de-duplication be compatible? for insights there. Suggest you consider your attacker's profile and see of any of those issues apply as ...

1

(Note: I'm using hexadecimal numbers to denote AES field elements and decimal numbers to denote integers.) First of all, you have to fix a generator of the AES field's multiplicative group. There's quite a lot of them: 0x03 0x05 0x06 0x09 0x0b 0x0e 0x11 0x12 0x13 0x14 0x17 0x18 0x19 0x1a 0x1c 0x1e 0x1f 0x21 0x22 0x23 0x27 0x28 0x2a 0x2c 0x30 0x31 0x3c 0x3e ...

1

I cannot prove that your scheme is secure, but as far as I know, a non-cryptographic hash function would work fine as there is an infinite number of inputs to any given hash, making it impossible to bruteforce all but the shortest messages (which would be an issue for short messages, you may want to append some sort of 128-bit padding). However, that said, ...

1

To simulate $n$ times iterated ECB encryption, you can set your input plaintext block as the IV, encrypt a "plaintext" consisting of $n$ all-zero blocks using either CBC or CFB mode (which are identical for all-zero plaintext), and take the $n$-th block of the resulting ciphertext (discarding the rest of the output). Note that, if your CBC mode ...

1

0: you have the wrong CipherValue. The one you show is in MACMethod/MACKey and is the encryption of the MAC key, see 6.1.1. The encryption of the subject key is in Key/Data/Secret/EncryptedValue and is AAECAwQFBgcICQoLDA0OD+cIHItlB3Wra1DUpxVvOx2lef1VmNPCMl8jwZqIUqGv. 1: openssl enc in most cases, including the one you used, does password-based encryption. ...

Only top voted, non community-wiki answers of a minimum length are eligible