| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RFC 6030 implies that the MAC should be performed over the ciphertext
but some earlier drafts implied that the MAC should be performed on the
plaintext. This change accpets the MAC if either the plaintext or
ciphertext match.
Note that this change allows for a padding oracle attack when CBC
encryption modes are used because decryption (and unpadding) needs to be
done before MAC checking. However, this module is not expected to be
available to users to process arbitrary PSKC files repeatedly.
This removes the tests for a missing MAC key (and replaces it for tests
of missing EncryptionMethod) because falling back to using the
encryption key (implemented in a444f78) in combination with this change
means that decryption is performed before MAC checking and is no longer
possible to trigger a missing MAC key error.
|
| |
|
| |
|
|
|
|
|
| |
This fixes the pragma directives to be be correct independently of
whether lxml is installed or not.
|
|
|
|
|
| |
This sets up Tox with various versions of Python and for each version a
run with and without lxml.
|
|
|
|
|
| |
This ensures that the files that are read in the test suite are properly
closed to avoid leaking open file descriptors.
|
| |
|
|
|
| |
This accidentally slipped in as part of beafc6b.
|
| |
|
| |
|
|
|
|
|
| |
This uses a custom data descriptor (property) for secret, counter,
time_offset, time_interval and time_drift.
|
|
|
|
|
|
|
|
| |
This allows having multiple keys per device while also maintaining the
previous API.
Note that having multiple keys per device is not allowed by the RFC 6030
schema but is allowed by some older internet drafts.
|
|
|
|
|
| |
Similar to the change for parsing, move the XML serialisation of PSKC
data to a single class in a separate module.
|
|
|
|
|
|
| |
This moves all the parse() functions to a single class in a dedicated
module that can be used for parsing PSKC files. This should make it
easier to subclass the parser.
|
| |
|
|
|
|
| |
This enables branch coverage testing and adds tests to improve coverage.
|
|
|
|
| |
This also ensures that the PRF URL is normalised.
|
| |
|
|
|
|
|
|
| |
This tries to make it clearer that the setup_preshared_key() and
setup_pbkdf2() functions are meant to be used when writing out PSKC
files.
|
|
|
|
|
|
| |
This uses the encryption key also as MAC key if no MAC key has been
specified in the PSKC file. Earlier versions of the PSKC draft specified
this behaviour.
|
|
|
|
|
|
| |
In older versions of the PSKC standard it was allowed to have a global
initialization vector for CBC based encryption algorithms. It is
probably not a good idea to re-use an IV in general.
|
|
|
|
|
| |
This makes it much easier to test the encryption, decryption and HMAC
processing separate from the PSKC parsing.
|
|
|
|
| |
This makes the creation if internal instances a litte more consistent.
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| | |
This adds support for setting up encryption keys and password-based key
derivation when writing PSKC files. Also MAC keys are set up when
needed.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
This method allows configuring a pre-shared encryption key and will
chose reasonable defaults for needed encryption values (e.g. it will
choose an algorithm, generate a new key of the appropriate length if
needed, etc.).
|
| |
| |
| |
| |
| | |
This factors out the PBKDF2 key derivation to a separate function and
introduces a function to configure KeyDerivation instances with PBKDF2.
|
| |
| |
| |
| |
| | |
This method will set up a MAC key and algorithm as specified or use
reasonable defauts.
|
| | |
|
| |
| |
| |
| |
| |
| | |
This also makes the MAC.algorithm a property similarly as what is done
for Encryption (normalise algorithm names) and adds a setter for the
MAC.key property.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Encryption class now has a fields property that lists the fields
that should be encrypted when writing the PSKC file.
This adds an encrypt_value() function that performs the encryption and
various functions to convert the plain value to binary before writing
the encrypted XML elements.
|
| |
| |
| |
| |
| |
| | |
This removes calling parse() from the Encryption and MAC constructors
and stores a reference to the PSKC object in both objects so it can be
used later on.
|
| |
| |
| |
| |
| |
| | |
This writes information about a pre-shared key or PBKDF2 key derivation
in the PSKC file. This also means that writing a decrypted version of a
previously encrypted file requires actively removing the encryption.
|
|/
|
|
|
| |
This property on the Encryption object provides a list of key sizes (in
bytes) that the configured encryption algorithm supports.
|
| |
|
|
|
|
|
| |
This supports reading the encryption password or key from the command
line or from a file.
|
|
|
|
|
|
| |
Ensure that when writing an XML file all namespace definitions are on
the toplevel KeyContainer element instead of scattered throughout the
XML document.
|
|
|
|
|
| |
This supports writing the XML output to binary streams as well as text
streams in Python 3.
|
|
|
|
|
|
|
|
|
|
| |
This adds tests to ensure that incorrect attribute and value types in
the PSKC file raise a ValueError exception and extends the tests for
invalid encryption options.
This removes some code or adds no cover directives to a few places that
have unreachable code or are Python version specific and places doctest
directives inside the doctests where needed.
|
|
|
|
|
|
| |
RFC 6030 is not clear about whether the attribute of ChallengeFormat and
ResponseFormat should be the singular CheckDigit or the plural
CheckDigits. This ensures that both forms are accepted.
|
|
|
|
|
| |
This checks for unknown policy elements in the PSKC file and will cause
the key usage policy check to fail.
|
|
|
|
|
| |
Some vendor-specific files were lifted from the LinOTP test suite and
another Feitian file was found in the oath-toolkit repository.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This extends support for handling various encoding methods for integer
values in PSKC files. For encrypted files the decrypted value is first
tried to be evaluated as an ASCII representation of the number and after
that big-endian decoded.
For plaintext values first ASCII decoding is tried after which base64
decoding is tried which tries the same encodings as for decrypted
values.
There should be no possibility for any base64 encoded value (either of
an ASCII value or a big-endian value) to be interpreted as an ASCII
value for any 32-bit integer.
There is a possibility that a big-endian encoded integer could be
incorrectly interpreted as an ASCII value but this is only the case for
110 numbers when only considering 6-digit numbers.
|