summary |
shortlog |
log |
commit | commitdiff |
tree
raw |
patch |
inline | side by side (from parent 1:
478cc53)
The section on client-server authentication is no longer accurate
because it depends on the version of client and server whether sha1
or sha256 is used for authentication. Since the hash function is an
implementation detail which should not be mentioned in the manual,
let's avoid the term and talk about cryptographic hash functions
instead.
- para_client receives the encrypted buffer and decrypts it with the
user's private key, thereby obtaining the challenge buffer and the
- para_client receives the encrypted buffer and decrypts it with the
user's private key, thereby obtaining the challenge buffer and the
-session key. It sends the SHA1 hash value of the challenge back to
-para_server and stores the session key for further use.
+session key. It hashes the challenge buffer with a crytographic hash
+function, sends the hash value back to para_server and stores the
+session key for further use.
-- para_server also computes the SHA1 hash of the challenge and compares
+- para_server also computes the hash value of the challenge and compares
it against what was sent back by the client.
- If the two hashes do not match, the authentication has failed and
it against what was sent back by the client.
- If the two hashes do not match, the authentication has failed and
paraslash relies on the quality of the pseudo-random bytes provided
by the crypto library (openssl or libgcrypt), on the security of
the implementation of the RSA and AES crypto routines and on the
paraslash relies on the quality of the pseudo-random bytes provided
by the crypto library (openssl or libgcrypt), on the security of
the implementation of the RSA and AES crypto routines and on the
-infeasibility to invert the SHA1 function.
+infeasibility to invert the hash function.
Neither para_server or para_client create RSA keys on their
own. This has to be done once for each user as sketched in
Neither para_server or para_client create RSA keys on their
own. This has to be done once for each user as sketched in
AFS database. It contains the information needed to stream each audio
file. In particular the following data is stored for each audio file.
AFS database. It contains the information needed to stream each audio
file. In particular the following data is stored for each audio file.
-- SHA1 hash value of the audio file contents. This is computed once
-when the file is added to the database. Whenever AFS selects this
-audio file for streaming the hash value is recomputed and checked
-against the value stored in the database to detect content changes.
+- The cryptographic hash value of the audio file contents. This is
+computed once when the file is added to the database. Whenever AFS
+selects this audio file for streaming the hash value is recomputed
+and checked against the value stored in the database to detect
+content changes.
- The time when this audio file was last played.
- The time when this audio file was last played.
File renames and content changes
--------------------------------
File renames and content changes
--------------------------------
-Since the audio file selector knows the SHA1 of each audio file that
+Since the audio file selector knows the hash of each audio file that
has been added to the afs database, it recognizes if the content of
a file has changed, e.g. because an ID3 tag was added or modified.
Also, if a file has been renamed or moved to a different location,
has been added to the afs database, it recognizes if the content of
a file has changed, e.g. because an ID3 tag was added or modified.
Also, if a file has been renamed or moved to a different location,