[Cryptography] An encrypted message exchange mechanism with file attachments

Ralf Senderek crypto at senderek.ie
Sun Apr 16 09:20:32 EDT 2023


The SafeWebdrop message exchange mechanism may be even more useful if exchanged
messages can be extended with an encrypted file attachment. Thus I have added
two more protocols to provide one encrypted file to be sent with each message.

Please note, that this message + attachment exchange mechanism can be used in
every project where users and server administrator and different users can
exchange registrationcodes and initial secrets in person.


File Attachment Extension
-------------------------

Sending SafeWebdrop Messages with an Encrypted File Attachment

CASE 1) unauthorized:  B : any user
This is always forbidden for obvious reasons.

CASE 2) authorized user on the same server S:  C : User that is registered on S
         <https>
 	C  -> S:  A, C, base64(message), { hash(message) } RSAprivC
 	                                # S verifies C's signature as C's pubkey is on the server
 					# after registration and checks that the hash
 					# matches the message and finally:
 					# S checks that A exists
 					# S checks that message is in AES encrypted
 					# OpenPGP message format
 					# S stores message in A's directory using Number

 	S  -> C:  Number
 					# Server returns the number under which the message
 					# is stored.
 					# C uses https PUT for file-upload in the next transfer

 	C  -> S:  A, C, encryptedFile, { Num, hash(encryptedFile)} RSAprivC
 					# Server reads maxbytes from stdin, checks that the
 					# data is in  OpenPGP format, checks that less than
 					# maxfiles are already stored in A's directory
 					# S checks C's signature and stores the file in A's
 					# directory using Number to identify the corresponding
 					# message
 	S  -> C:  OK
         </https>

CASE 3) registered user D on another server CROSS:

As the cross server user D is registered on S using the shared initial secret between A and D.
This case can be handled exactly like CASE 2. D%CROSS's public key is in A's contacts directory
and can be used in the same way as the authorized user C in CASE 2.

Reading SafeWebdrop Messages with an Encrypted File Attachment

         <https>
 	A  -> S : UID, NEW
 					# server checks that UID exists and
 					# has a public key
 	S  -> A : hash(Nonce)		# S uses a new stored Nonce

 	A  -> S : UID, { UID, hash(Nonce), GETATTACH } RSAprivA
 					# S performs the checks as in registration
 					# S concatenates all safewebdrop messages
 					# prefixed with their filename and
 					# generates a hash and a list of the messages
 					# S concatenates all stored encrypted files
                                         # prefixed with their filename and
                                         # generates a hash2 and a list2 of the files
 					# S stores both hashes, the Nonce and the IP in
 					# A's request file

 	S  -> A : allsafewebdropmessages, "&", base64(allencryptedfiles)

 	A  -> S : UID, { UID, hash(Nonce), hash(allmessages), hash(allfiles) } RSAprivA

 					# S performs checks and verifies both hashes
 					# S deletes all safewebdrop messages and files,
 					# if the hashes match those in the request file.
 	S  -> A : OK
         </https>

Please don't hesitate to send me your comments!

     --ralf



More information about the cryptography mailing list