djsundog/circuitpython
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
028776d97b
circuitpython/docs/library/cryptolib.rst

41 lines
1.4 KiB
ReStructuredText
Raw Normal View History

docs: Replace ufoo with foo in all docs. Anywhere a module is mentioned, use its "non-u" name for consistency. The "import module" vs "import umodule" is something of a FAQ, and this commit intends to help clear that up. As a first approximation MicroPython is Python, and so imports should work the same as Python and use the same name, to a first approximation. The u-version of a module is a detail that can be learned later on, when the user wants to understand more and have finer control over importing. Existing Python code should just work, as much as it is possible to do that within the constraints of embedded systems, and the MicroPython documentation should match the idiomatic way to write Python code. With universal weak links for modules (via MICROPY_MODULE_WEAK_LINKS) users can consistently use "import foo" across all ports (with the exception of the minimal ports). And the ability to override/extend via "foo.py" continues to work well. Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
2021-08-11 23:59:29 -04:00
:mod:`cryptolib` -- cryptographic ciphers
=========================================
docs/ucryptolib: Add docs for new ucryptolib module.
2018-01-10 14:47:08 -05:00
docs: Replace ufoo with foo in all docs. Anywhere a module is mentioned, use its "non-u" name for consistency. The "import module" vs "import umodule" is something of a FAQ, and this commit intends to help clear that up. As a first approximation MicroPython is Python, and so imports should work the same as Python and use the same name, to a first approximation. The u-version of a module is a detail that can be learned later on, when the user wants to understand more and have finer control over importing. Existing Python code should just work, as much as it is possible to do that within the constraints of embedded systems, and the MicroPython documentation should match the idiomatic way to write Python code. With universal weak links for modules (via MICROPY_MODULE_WEAK_LINKS) users can consistently use "import foo" across all ports (with the exception of the minimal ports). And the ability to override/extend via "foo.py" continues to work well. Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
2021-08-11 23:59:29 -04:00
.. module:: cryptolib
docs/ucryptolib: Add docs for new ucryptolib module.
2018-01-10 14:47:08 -05:00
:synopsis: cryptographic ciphers
Classes
-------
.. class:: aes
.. classmethod:: __init__(key, mode, [IV])
Initialize cipher object, suitable for encryption/decryption. Note:
after initialization, cipher object can be use only either for
encryption or decryption. Running decrypt() operation after encrypt()
or vice versa is not supported.
Parameters are:
* *key* is an encryption/decryption key (bytes-like).
* *mode* is:
docs: Replace ufoo with foo in all docs. Anywhere a module is mentioned, use its "non-u" name for consistency. The "import module" vs "import umodule" is something of a FAQ, and this commit intends to help clear that up. As a first approximation MicroPython is Python, and so imports should work the same as Python and use the same name, to a first approximation. The u-version of a module is a detail that can be learned later on, when the user wants to understand more and have finer control over importing. Existing Python code should just work, as much as it is possible to do that within the constraints of embedded systems, and the MicroPython documentation should match the idiomatic way to write Python code. With universal weak links for modules (via MICROPY_MODULE_WEAK_LINKS) users can consistently use "import foo" across all ports (with the exception of the minimal ports). And the ability to override/extend via "foo.py" continues to work well. Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
2021-08-11 23:59:29 -04:00
* ``1`` (or ``cryptolib.MODE_ECB`` if it exists) for Electronic Code Book (ECB).
* ``2`` (or ``cryptolib.MODE_CBC`` if it exists) for Cipher Block Chaining (CBC).
* ``6`` (or ``cryptolib.MODE_CTR`` if it exists) for Counter mode (CTR).
docs/ucryptolib: Add docs for new ucryptolib module.
2018-01-10 14:47:08 -05:00
* *IV* is an initialization vector for CBC mode.
extmod/moducryptolib: Add AES-CTR support. Selectable at compile time via MICROPY_PY_UCRYPTOLIB_CTR. Disabled by default.
2019-04-23 05:39:05 -04:00
* For Counter mode, *IV* is the initial value for the counter.
docs/ucryptolib: Add docs for new ucryptolib module.
2018-01-10 14:47:08 -05:00
.. method:: encrypt(in_buf, [out_buf])
Encrypt *in_buf*. If no *out_buf* is given result is returned as a
newly allocated `bytes` object. Otherwise, result is written into
mutable buffer *out_buf*. *in_buf* and *out_buf* can also refer
to the same mutable buffer, in which case data is encrypted in-place.
.. method:: decrypt(in_buf, [out_buf])
Like `encrypt()`, but for decryption.
Reference in New Issue Copy Permalink