Codebase list python-castellan / 9ecd300
Fix length usage in VaultKeyManager.create_key. Previous code was considering length as bytes, but the API contract considers the length param to be bits so that the considering `km` as a VaultKeyManager, the call `km.create_key(ctx, 'AES', 256)` should generate a 256 bit AES key and not a 2048 bit AES key instead. Closes-Bug: #1817248 Change-Id: I5815cb74394e18b6058f4c5cf69b656d7cc2c43b Signed-off-by: Moisés Guimarães de Medeiros <moguimar@redhat.com> Moisés Guimarães de Medeiros 4 years ago
2 changed file(s) with 17 addition(s) and 2 deletion(s). Raw diff Collapse all Expand all
297297 msg = _("User is not authorized to use key manager.")
298298 raise exception.Forbidden(msg)
299299
300 if length % 8:
301 msg = _("Length must be multiple of 8.")
302 raise ValueError(msg)
303
300304 key_id = uuid.uuid4().hex
301 key_value = os.urandom(length or 32)
305 key_value = os.urandom((length or 256) // 8)
302306 key = sym_key.SymmetricKey(algorithm,
303 length or 32,
307 length or 256,
304308 key_value,
305309 key_id,
306310 name or int(time.time()))
311
307312 return self._store_key_value(key_id, key)
308313
309314 def store(self, context, key_value, **kwargs):
0 ---
1 fixes:
2 - |
3 Fixed VaultKeyManager.create_key() to consider the `length` param as bits
4 instead of bytes for the key length. This was causing a discrepancy between
5 keys generated by the HashiCorp Vault backend and the OpenStack Barbican
6 backend. Considering `km` as an instance of a key manager, the following
7 code `km.create_key(ctx, "AES", 256)` was generating a 256 bit AES key when
8 Barbican is configured as the backend, but generating a 2048 bit AES key
9 when Vault was configured as the backend.