Aiootp

Latest version: v0.23.7

Safety actively analyzes 641102 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 7 of 9

0.9.3

Not secure
-------------------------


Major Changes
^^^^^^^^^^^^^

- Speed & efficiency improvements in the ``Comprende`` class & ``azip``.


Minor Changes
^^^^^^^^^^^^^

- Various refactorings & code cleanups.
- Added ``apop`` & ``pop`` ``Comprende`` generators to the library.
- Switched the default character table in the ``ato_base``, ``to_base``,
``afrom_base``, & ``from_base`` chainable generator methods from the 62
character ``ASCII_ALPHANUMERIC`` table, to the 95 character ``ASCII_TABLE``.
- Made the digits generators in ``randoms.py`` automatically create a new
cryptographically secure key if a key isn't passed by a user.
- Some extra data processing functions added to ``generics.py``.

0.9.2

Not secure
-------------------------


Major Changes
^^^^^^^^^^^^^

- Added ``passcrypt`` & ``apasscrypt`` instance methods to ``OneTimePad``,
``Keys``, & ``AsyncKeys`` classes. They produce password hashes that are
not just secured by the salt & passcrypt algorithm settings, but also by
their main symmetric instance keys. This makes passwords infeasible to
crack without also compromising the instance's 512-bit key.


Minor Changes
^^^^^^^^^^^^^

- Further improvements to the random number generator in ``randoms.py``.
Made its internals less sequential thereby raising the bar of work needed
by an attacker to successfully carry out an order prediction attack.
- Added checks in the ``Passcrypt`` class to make sure both a salt &
password were passed into the algorithm.
- Switched ``PermissionError`` exceptions in ``Passcrypt._validate_args``
to ``ValueError`` to be more consistent with the rest of the class.
- Documentation updates / fixes.

0.9.1

Not secure
-------------------------


Minor Changes
^^^^^^^^^^^^^

- Now any falsey values for the ``salt`` keyword argument in the library's
``keys``, ``akeys``, ``bytes_keys``, ``abytes_keys``, ``subkeys``, &
``asubkeys`` infinite keystream generators, & other functions around the
library, will cause them to generate a new cryptographically secure
pseudo-random value for the salt. It formerly only did this when ``salt``
was ``None``.
- The ``seeder`` & ``aseeder`` generators have been updated to introduce
512 new bits of entropy from ``secrets.token_bytes`` on every iteration
to ensure that the CSPRNG will produce secure outputs even if its
internal state is somehow discovered. This also allows for simply calling
the CSPRNG is enough, there's no longer a strong reason to pass new
entropy into it manually, except to add even more entropy as desired.
- Made ``size`` the last keywordCHECKSUMS.txt argument in ``encrypt`` &
``aencrypt`` to better mirror the signatures for rest of the library.
- Added ``token_bits`` & ``atoken_bits`` functions to ``randoms.py`` which
are renamings of ``secrets.randbits``.
- Refactored & improved the security og ``randoms.py``'s random number
generator.

0.9.0

Not secure
-------------------------


Major Changes
^^^^^^^^^^^^^

- Added hmac codes to ciphertext for the following functions: ``json_encrypt``,
``ajson_encrypt``, ``bytes_encrypt``, ``abytes_encrypt``,
``Database.encrypt`` & ``AsyncDatabase.aencrypt``. This change greatly
increases the security of ciphertext by ensuring it hasn't been modified
or tampered with maliciously. One-time pad ciphertext is maleable, so
without hmac validation it can be changed to successfully allow
decryption but return the wrong plaintext. These functions are the
highest level abstractions of the library for encryption/decryption,
which made them excellent targets for this important security update.
As well, it isn't easily possible for the library to provide hmac codes
for generators that produce ciphertext, because the end of a stream of
ciphertext isn't known until after the results have left the scope
of library code. So users will need to produce their own hmac codes for
generator ciphertext unless we find an elegant solution to this issue.
These functions now all return dictionaries with the associated hmac
stored in the ``"hmac"`` entry. The bytes functions formerly returned
lists, now their ciphertext is available from the ``"ciphertext"`` entry.
And, all database files will have an hmac attached to them now. These
changes were designed to still be compatible with old ciphertexts but
they'll likely be made incompatible by the v0.11.x major release.
- Only truthy values are now valid ``key`` keyword arguments in the
library's ``keys``, ``akeys``, ``bytes_keys``, ``abytes_keys``, ``subkeys``,
& ``asubkeys`` infinite keystream generators. Also now seeding extra entropy
into ``csprng`` & ``acsprng`` when ``salt`` is falsey within them.
- Only truthy values are now valid for ``password`` & ``salt`` arguments in
``apasscrypt``, ``passcrypt`` & their variants.


Minor Changes
^^^^^^^^^^^^^

- Updates to documentation & ``README.rst`` tutorials.
- The ``kb``, ``cpu``, & ``hardness`` arguments in ``sum_passcrypt`` &
``asum_passcrypt`` chainable generator methods were switched to keyword
only arguments.

0.8.1

Not secure
-------------------------


Major Changes
^^^^^^^^^^^^^

- Added ``sum_passcrypt`` & ``asum_passcrypt`` chainable generator methods
to ``Comprende`` class. They cumulatively apply the passcrypt algorithm
to each yielded value from an underlying generator with the passcrypt'd
prior yielded result used as a salt. This allows making proofs of work,
memory & space-time out of iterations of the passcrypt algorithm very
simple.


Minor Changes
^^^^^^^^^^^^^

- Various inaccurate docstrings fixed.
- Various refactorings of the codebase.
- Made ``kb``, ``cpu``, & ``hardness`` arguments into keyword only arguments
in ``AsyncDatabase`` & ``Database`` classes.
- The ``length`` keyword argument in functions around the library was
changed to ``size`` to be consistent across the whole package. Reducing
the cognitive burden of memorizing more than one name for the same concept.
- Various efficiency boosts.
- Edits to ``README.rst``.
- Added ``encode_salt``, ``aencode_salt``, ``decode_salt`` & ``adecode_salt``
functions to the library, which gives access to the procedure used to
encrypt & decrypt the random salt which is often the first element
produced in one-time pad ciphertexts.
- Added cryptographically secure pseudo-random values as default keys in
encryption functions to safeguard against users accidentally encrypting
data without specifying a key. This way, such mistakes will produce
ciphertext with an unrecoverable key, instead of without a key at all.

0.8.0

Not secure
-------------------------


Major Changes
^^^^^^^^^^^^^

- Fix ``test_hmac``, ``atest_hmac`` functions in the keys & database
classes. The new non-constant-time algorithm needs a random salt to be
added before doing the secondary hmac to prevent some potential exotic
forms of chosen plaintext/ciphertext attacks on the algorithm. The last
version of the algorithm should not be used.
- The ``Keys`` & ``AsyncKeys`` interfaces were overhauled to remove the
persistance of instance salts. They were intended to be updated by users
with the ``reset`` & ``areset`` methods, but that cannot be guaranteed
easily through the class, so it is an inappropriate interface since
reusing salts for encryption is completely insecure. The instances do
still maintain state of their main encryption key, & new stateful methods
for key generation, like ``mnemonic`` & ``table_key``, have been added.
The ``state`` & ``astate`` methods have been removed.
- Gave ``OneTimePad`` instances new stateful methods from the ``ciphers.py``
module & ``keygens.py`` keys classes. Its instances now remember the main
symmetric key behind the ``key`` property & automatically passes it as a
keyword argument to the methods in ``OneTimePad.instance_methods``.


Minor Changes
^^^^^^^^^^^^^

- Update ``CHANGES.rst`` file with the updates that were not logged for
v0.7.1.
- ``BYTES_TABLE`` was turned into a list so that the byte characters can
be retrieved instead of their ordinal numbers.

Page 7 of 9

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.