From 87618d45086290ef5ab26c3c7fbf21f5fb17fadf Mon Sep 17 00:00:00 2001 From: Danny Al-Gaaf Date: Sun, 9 Mar 2014 00:19:08 +0100 Subject: [PATCH] session_authentication.rst: fix some typos Signed-off-by: Danny Al-Gaaf --- doc/dev/session_authentication.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/doc/dev/session_authentication.rst b/doc/dev/session_authentication.rst index 94a5636c938..fd2651dd05d 100644 --- a/doc/dev/session_authentication.rst +++ b/doc/dev/session_authentication.rst @@ -32,11 +32,11 @@ that the sender had better be in agreement with the receiver on the session secu since otherwise messages will be uniformly dropped between them. The code is also prepared to handle encryption and decryption of session messages, which would -add secrecy to the ingrity provided by the signatures. No protocol currently implemented +add secrecy to the integrity provided by the signatures. No protocol currently implemented encrypts the ongoing session messages, though. For this functionality to work, several steps are required. First, the sender and receiver must have -a succesful run of the cephx protocol to establish a shared key. They must store that key somewhere +a successful run of the cephx protocol to establish a shared key. They must store that key somewhere that the pipe can get at later, to permit messages to be signed with it. Sent messages must be signed, and received messages must have their signatures checked. @@ -142,7 +142,8 @@ Adding Encryption to Sessions The existing code is partially, but not fully, set up to allow sessions to have their packets encrypted. Part of adding encryption would be similar to adding a new authentication method. -But one would also need to add calls to the encryption and decryption routines in ``write\_message()`` and ``read\_message()``. These calls would probably go near where the current calls for +But one would also need to add calls to the encryption and decryption routines in ``write\_message()`` +and ``read\_message()``. These calls would probably go near where the current calls for authentication are made. You should consider whether you want to replace the existing calls with something more general that does whatever the chosen form of session security requires, rather than explicitly saying ``sign`` or ``encrypt``.