Cryptography | modern ciphers in C language | Encryption library

GCM is a stream cipher mode and therefore does not require padding. During encryption, an authentication tag is implicitly generated, which is used for authentication during decryption. Also, an IV/nonce of 12 bytes is recommended for GCM.

The posted Python code unnecessarily pads and doesn't take the authentication tag into account, unlike the JavaScript code, which may be the main reason for the different ciphertexts. Whether this is the only reason and whether the JavaScript code implements GCM correctly, is difficult to say, since the getMessageEncoding() method was not posted, so testing this was not possible.

Also, both codes apply a 16 bytes IV/nonce instead of the recommended 12 bytes IV/nonce.

Cryptography offers two possible implementations for GCM. One implementation uses the architecture of the non-authenticating modes like CBC. The posted Python code applies this design, but does not take authentication into account and therefore implements GCM incompletely. A correct example for this design can be found here.
Cryptography generally recommends the other approach for GCM (s. the Danger note), namely the AESGCM class, which performs implicit authentication so that this cannot be accidentally forgotten or incorrectly implemented.

The following implementation uses the AESGCM class (and also takes into account the optional additional authenticated data):

The referenced Python code uses P-384 (aka secp384r1) as elliptic curve. This is compatible with the WebCrypto API, which supports three curves P-256 (aka secp256r1), P-384 and P-521 (aka secp521r1), see EcKeyImportParams.

The following WebCrypto code generates a shared secret using ECDH and derives an AES key from the shared secret using HKDF. In detail the following happens:

• To allow comparison of the derived key with that of the referenced Python code, predefined EC keys are applied. The private key is imported as PKCS#8, the public key as X.509/SPKI. Note that due to a Firefox bug concerning the import of EC keys, the script below cannot be run in the Firefox browser.
• After the import the shared secret is created with ECDH using deriveBits() (and not deriveKey()).
• The shared secret is imported with importKey() and then the AES key is derived using HKDF, again with deriveBits().

you must open file in binary mode for reading and writing. since encrypt method expect bytes as a parameter, this way you can encrypt any file no matter it's type.

The reason here is that you're constructing a public/private key pair in both applications.

Essentially you're trying to encrypt something with Bob's public key, and trying to decrypt that with Alice's private key. This won't work.

You need to construct 1 pair, and then use the public key from that pair for the encryption, and the private key from the same pair for the decryption.

This works:

It is well written in the documentation;

Implementation

Fernet is built on top of a number of standard cryptographic primitives. Specifically it uses:

• AES in CBC mode with a 128-bit key for encryption; using PKCS7 padding.
• HMAC using SHA256 for authentication.
• Initialization vectors are generated using os.urandom().

For complete details consult the specification.

Therefore you cannot use AES-256 with Fernet

• Cryptography.io library has other modes too, in the hazardous material layer including CBC, CTR, and GCM for AES-256, too.

PyCrypto can use a wide range of mode of operations for AES-256 including CBC, CTR, GCM, SIV, and OCB

Not clear how you get 44 bytes, here is the way to get the 32-bytes;

It might be possible that Ansible is not parsing the updated inventory file file, or the hosts name is being malformed in as it updates the inventory.

In this scenario, you can use the -vv or -vvvv parameter in your Ansible command to get extra logging.

This will give you a complete picture into what Ansible is actually doing as it tries to parse hosts.

I found a solution to my problem. In fact, just as I suspected, there was a missing directory to my PYTHONPATH. It was the directory that contained the gtts package.

Solution: If you have the same problem,

1. Find the package

I looked at that post

1. Add it to sys.path (which will also add it to PYTHONPATH)

Add this code at the top of your script (in my case, the pipelines.py):

The reason you're getting this error has nothing to do with Content-Type request header :). The real culprit is same header getting added multiple times (Content-Length in your case).

Essentially what is happening is that you're manually adding Content-Length header and Invoke-RestMethod is also adding Content-Length request header. Because this header is added multiple times, you're getting this error. Once you removed Content-Length header from your request, the issue was solved because now this header is added just once.

Please see this issue on Github for more details: https://github.com/PowerShell/PowerShell/issues/12500#issuecomment-777757252. This is where I found this solution.

Your approach is correct and should work if done correctly. Although FYI it doesn't entirely protect from MitM -- ssh-keyscan itself uses an unverified connection and is vulnerable to MitM, although if that connection is legit, checking the key prevents faking on later connections. This is a form/variant of SSH's common 'ToFU' (Trust on First Use) security model.

From my basic understanding, the known_hosts file contains a key. ...

In general, known_hosts contains a mapping from host identities (names and/or IP addresses) to keys. But if your file was created only as you show, it has only one mapping entry containing only one key.

1. make sure you pass the correct path to setKnownHosts, and run as the correct (same) user. If the path you specify cannot be opened (either does not exist or access not allowed) Jsch does NOT throw any error, it just returns without loading anything. You might instead open the file yourself with new FileInputStream(pathstring) and pass to the setKnownHosts(InputStream) overload, so you get an exception if the open fails.

2. make sure you are using the same host identity. If e.g. a host has multiple names (like cloud servers often do) and you use one in ssh-keyscan but a different one in JSch then even though this is actually the same host and key it won't match. But if you are actually using IP addresses in both places, at least if you mean IPv4, this is less likely because very few machines today have multiple public IPv4 addresses. (In the past this was more common and called multihoming.) IPv6 is more possible; most IPv6 machines have both transient and permanent public addresses (as well as local/private ones), and often multiple transients.