Projects/Encryption performance - Revision history

TomYu at 04:12, 16 February 2010

2010-02-16T04:12:31Z

2009-11-20T17:40:42Z

2009-10-19T03:16:19Z

‎Testing

2009-10-05T17:28:14Z

‎Implementation Design

2009-09-28T15:32:54Z

‎API Proposal

2009-09-08T17:05:04Z

note approval

2009-08-05T19:27:12Z

‎Approvals

2009-08-05T19:23:52Z

2009-07-21T22:57:51Z

‎Implementation Design

2009-07-21T20:23:27Z

‎Implementation Design

← Older revision		Revision as of 03:16, 19 October 2009
Line 82:		Line 82:

	The existing test suite should adequately test the changes to the code paths associated with the auth_context and id_rec structures.		The existing test suite should adequately test the changes to the code paths associated with the auth_context and id_rec structures.
		+
		+	Some sample performance gains from derived key caching on a 64-bit Linux/x86 machine, with AES-128 keys:
		+
		+	* 1 million encryptions of 16 bytes: 6.4s -> 1.8s (72% reduction)
		+	* Half a million encryptions of 1024 bytes: 8.4s -> 6.1s (27% reduction)
		+	* 1 million checksums of 16 bytes: 3.6s -> 1.2s (67% reduction)
		+	* Half a million checksums of 1024 bytes: 3.5s -> 2.4s (31% reduction)

	==Future Work==		==Future Work==

@@ Line 69: / Line 69: @@
 ==Implementation Design==
-The existing krb5_c versions of the new functions will be reimplemented in terms of the krb5_k functions.  Internal functions and the enc_provider, hash_providers, and enctype vtables will be redefined using krb5_key so that back ends only need to implement one version of the interface.
+The existing krb5_c versions of the new functions will be reimplemented in terms of the krb5_k functions.  Internal functions and the enc_provider, hash_providers, and enctype vtables will be redefined using krb5_key so that back ends only need to implement one version of the interface.  To avoid excessive conversions, a few internal interfaces will still use keyblocks, particularly many the interfaces which construct keys.
 The krb5_key_st structure will initially contain a linked list of derived keys, mapping a derivation constant (krb5_data) to a krb5_key.  krb5_derive_key will cache derived keys in this list.  The krb5_key_st structure will contain a flag to disable caching so that we don't waste the time allocating and copying such information for keyblock-using functions like krb5_c_encrypt which wouldn't preserve the cache.

@@ Line 20: / Line 20: @@
   krb5_error_code krb5_k_create_key(krb5_context context, krb5_keyblock *key_data,
                                     krb5_key *out);
-  krb5_error_code krb5_k_free_key(krb5_context context, krb5_key key);
+  void krb5_k_free_key(krb5_context context, krb5_key key);
   krb5_error_code krb5_k_key_keyblock(krb5_context context, krb5_key key,
                                       krb5_keyblock **key_data);

← Older revision		Revision as of 19:27, 5 August 2009
Line 114:		Line 114:

	===Approvals===		===Approvals===
		+
		+	#[[User:SamHartman\|SamHartman]] 15:27, 5 August 2009 (EDT)

	===Discussion===		===Discussion===

← Older revision	Revision as of 19:23, 5 August 2009
(No difference)

@@ Line 71: / Line 71: @@
 The existing krb5_c versions of the new functions will be reimplemented in terms of the krb5_k functions, using an internal non-copying keyblock-to-key_st converter.  Internal functions and the enc_provider, hash_providers, and enctype vtables will be redefined using krb5_key so that back ends only need to implement one version of the interface.
-The krb5_key_st structure will initially contain a linked list of derived keys, mapping a derivation constant (krb5_data) to a krb5_key.  krb5_derive_key will cache derived keys in this list.
+The krb5_key_st structure will initially contain a linked list of derived keys, mapping a derivation constant (krb5_data) to a krb5_key.  krb5_derive_key will cache derived keys in this list.  The krb5_key_st structure will contain a flag to disable caching so that we don't waste the time allocating and copying such information for keyblock-using functions like krb5_c_encrypt which wouldn't preserve the cache.
 In krb5_auth_context and krb5_gss_ctx_id_rec, all keyblock fields will be replaced with krb5_keys, and all usages of those fields changed to use the krb5_k APIs.