# Append text to file without decrypting & encrypting again

Is it possible to add a line to a file which is encrypted symmetrically or asymmetrically (private key refers to readkey below, public key refers to append key then) without decrypting it?

I was thinking about s.th. like:

msg1="hello" msg2="world" appendkey=... readkey=... file=touch(...) addLine(msg1, file, appendkey) addLine(msg2, file, appendkey) ERROR=decrypt(file, appendkey) WORKS=decrypt(file, privkey)

Then the WORKS equals to:

hello world

The idea is, that various number of people can add s.th. to a file without seeing its content. Only the owner of the file can decrypt it once to see all lines (he/she should not decrypt all the lines individually for performance reasons). For me this scenario typically sounds asymmetrically, thats the reason why I thought that there could be a mechanism to use the public key to append s.th...

• How is the file actually encrypted? Asymmetric crypto is usually not used directly for content, but instead hybrid encryption is used. In that case you'd need the same random symmetric key - and everyone who knows it can read the entire file. – tylo Aug 7 '18 at 21:39
• I dont mind if its either symmetric, asymmetric or hybrid. The important part is, that the ones writing to it cannot read the content only the owner (owner in a sense of owning a key, not file owner in filesystem) can read it. – Techradar Aug 8 '18 at 8:09
• ideally you should also take authentication into account – hunter Aug 10 '18 at 9:59
• @hunter Authentication is not scope of the question. Assume, we have a authentication layer before it ;-) – Techradar Aug 10 '18 at 12:30
• @Techradar I don't think you understand my comment. I'm referring to authentication of the integrity of the ciphertext, not authenticating the user. The former is implicit to your question. If you're implementing any form of authentication (which you probably should), then appending data to your ciphertext will have implications ;-) – hunter Aug 10 '18 at 19:15

There may be a relatively straightforward answer, depending on your requirements: could you use a multipart MIME message with separate MIME sections, one for each user's encrypted contents?

If you're looking instead for an asymmetric cryptosystem that supports appends, then maybe you can update your question to make that clear.

• Thanks! I read through it, but I don't get how you stream to it without decrypting each section individually or using a shared key? – Techradar Aug 8 '18 at 8:59
• Each new MIME section gets appended to the blob that came before it. Each MIME section contains unique content, and is encrypted separately from the other sections (using the same public key), like sausage links. The recipient decrypts each section one at a time. Maybe I misunderstood the question. – Russ Aug 8 '18 at 11:32
• Ah sorry, forgot to mention, that the idea is to boost performance by only decrypting the file once not all lines individually. – Techradar Aug 8 '18 at 12:40
• Sounds like you want a single symmetric key that everyone can use to encrypt data, but that breaks security. Asymmetric algorithms (public key) are thousands of times slower than symmetric (e.g., AES) algorithms, so what usually happens is someone generates a symmetric key of say 256 bits, encrypts bulk data with that, then wraps the key itself using an asymmetric public key and appends it. For N blobs, that's N operations of: decrypt the symmetric key, decrypt that blob, next blob. My gut says you're not going to get better performance without sacrificing security. – Russ Aug 8 '18 at 13:45
• Ok, but would then mean, that in case of 500k entries, the receiver must to decrypt 500k entries. I dont mind if its sym/asym, I just wanted to find out if there's a solution, that you don't have to decrypt 500k times and that "most" of the work is done at the client when he appends an entry to the "parent" without reading all the previous entries. And later, when the receiver receives the file he only has to decrypt it once to get all entries. Is there a solution to this? – Techradar Aug 10 '18 at 8:06