ArcPro "cryptography" library?

[JamesCrandall]

Hello!  I am in the process of migrating existing implementations over to Pro and running into issues where the py libraries we've been using are not going to be readily available and looking to see if we can replicate functionality with the installed packages that come with ArcPro 2.9

Specifically we've been using these:

from Crypto.Cipher import AES
import ConfigParser

Where we have an .enc file with credentials that the .py script will decrypt using AES and locate the key required for that decryption using ConfigParser to read an .ini text file on a network folder.

I see there's a cryptography library that comes with ArcPro installs https://pro.arcgis.com/en/pro-app/latest/arcpy/get-started/available-python-libraries.htm and wondering if anyone has any simple examples.

[GeneHorodecki]

You could also use pycryptodome.  It has AES and is supported.

[RhettZufelt]

Not sure about the Crypto, but for Pro (python 3.x):

import configparser

R_

[ShaunWalbridge]

Pro includes a number of cryptographic packages, including a full OpenSSL installation if you want to work with that. Probably easiest is to use the `cryptography` package to make your calls: https://cryptography.io/en/latest/

It supports a wide range of cryptographic primitives and is heavily tested for security. You may be better served by switching to Fernet (https://cryptography.io/en/latest/fernet/) rather than working directly with AES, and if your only goal is to securely store credentials, I'd recommend instead looking at https://keyring.readthedocs.io/en/latest/index.html which is also included in Pro. Keyring lets you store the credentials directly in the Windows Credential store and access them there, which avoids multiple classes of issues in trying to manage your own cryptographic system.

[JamesCrandall]

Your feedback is appreciated.  I hoped to just port over our current GP services that implement ConfigParser and AES but coming to terms with the need to just come up with a replacement.  Simple is best as this really is more or less about not having any credentials all over the place and maintaining a single .enc file that could be decrypted at runtime is super simple.

Also: this will all be part of GP tools as well as them published out as GP services (inside our DMZ).  Essentially we're just supporting token-based authentication by having a GP service hit a generateToken endpoint of an on-prem AGS Enterprise -- that token is used by custom widgets in WAB apps.