New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

miniLock file format version 2 #136

Closed
wants to merge 5 commits into
base: master
from

Conversation

Projects
None yet
6 participants
@45678

45678 commented Aug 13, 2014

I’ve run into a few situations where I wanted to know more about a miniLock file. I can get the original file name, file size and sender identity from the current file format which is great. But I’d like to also know when the file was encrypted.

For example, I keep My miniLock IDs.txt.minilock on my thumb drive so that I can do crypto operations on the computers at the library. Sometimes I end up with a few copies of this file after I’ve updated the list a few times and I’m not certain which minilock file is the most up-to-date. It would be really nice in those situations to know when a file was encrypted so I can quickly sort the keepers from the goners.

This proposal adds an optional encryptedAt member to the encrypted fileInfo properties in the header of the file. I suggest miniLock programs should always add the encryptedAt member by default because it is helpful. I made it strictly optional so that programs are backwards compatible with the original format and to let people override the default when they want to exclude the encryption time for some reason.

What do ya’ll think of this idea?

@45678

This comment has been minimized.

Show comment
Hide comment
@45678

45678 Aug 13, 2014

For context, here is how the file encryption time might be displayed in another miniLock program:

screen shot 2014-08-13 at 12 36 00 pm

45678 commented Aug 13, 2014

For context, here is how the file encryption time might be displayed in another miniLock program:

screen shot 2014-08-13 at 12 36 00 pm

@jdluzen

This comment has been minimized.

Show comment
Hide comment
@jdluzen

jdluzen Aug 13, 2014

I would go one step further: have an entirely optional section (subobject) in the header which to throw whatever you want in. Though the design seems to tolerate this right now, it would be helpful to make it explicit.

jdluzen commented Aug 13, 2014

I would go one step further: have an entirely optional section (subobject) in the header which to throw whatever you want in. Though the design seems to tolerate this right now, it would be helpful to make it explicit.

@ovalseven8

This comment has been minimized.

Show comment
Hide comment
@ovalseven8

ovalseven8 Aug 13, 2014

Well, I think it should be (if at all) an optional feature. There could be security issues and you don't want that others can see when the file was encrypted.
Further a look at the file attributes could solve the problem.

ovalseven8 commented Aug 13, 2014

Well, I think it should be (if at all) an optional feature. There could be security issues and you don't want that others can see when the file was encrypted.
Further a look at the file attributes could solve the problem.

@45678

This comment has been minimized.

Show comment
Hide comment
@45678

45678 Aug 13, 2014

And here is how it might look onscreen in the miniLock Chrome app:

image

45678 commented Aug 13, 2014

And here is how it might look onscreen in the miniLock Chrome app:

image

@45678

This comment has been minimized.

Show comment
Hide comment
@45678

45678 Aug 13, 2014

Thanks for your feedback @ovalseven8. Could you give me a few of examples of the security issues that would be of concern if the recipient knows when the file was encrypted?

45678 commented Aug 13, 2014

Thanks for your feedback @ovalseven8. Could you give me a few of examples of the security issues that would be of concern if the recipient knows when the file was encrypted?

@kaepora

This comment has been minimized.

Show comment
Hide comment
@kaepora

kaepora Aug 13, 2014

Owner

Whoa, hold up. You can't just modify the miniLock protocol design like that. Adding encryptedAt to the header requires careful consideration and the issuing of a new version number for the protocol.

Owner

kaepora commented Aug 13, 2014

Whoa, hold up. You can't just modify the miniLock protocol design like that. Adding encryptedAt to the header requires careful consideration and the issuing of a new version number for the protocol.

@45678

This comment has been minimized.

Show comment
Hide comment
@45678

45678 Aug 13, 2014

Sure @kaepora. Is it ok to consider it carefully in a pull request? Or should I do this somewhere else?

45678 commented Aug 13, 2014

Sure @kaepora. Is it ok to consider it carefully in a pull request? Or should I do this somewhere else?

@45678

This comment has been minimized.

Show comment
Hide comment
@45678

45678 Aug 13, 2014

@cathalgarvey I am curious to hear your thoughts about this change from the perspective of deadlock.

45678 commented Aug 13, 2014

@cathalgarvey I am curious to hear your thoughts about this change from the perspective of deadlock.

@ovalseven8

This comment has been minimized.

Show comment
Hide comment
@ovalseven8

ovalseven8 Aug 13, 2014

@45678: miniLock is a application for security, anonymity and privacy. Because of that I think the user should be able to control what he want to share. And I think there could be reasons the sender don't want to show the encryption date. That's why I prefer that this should be (if at all) an optional feature. Also I think the feature won't bring an additional value for the most users.

Well, I know, the security issues are largely theoretical. But, as said, I think there could be a reason someday.

ovalseven8 commented Aug 13, 2014

@45678: miniLock is a application for security, anonymity and privacy. Because of that I think the user should be able to control what he want to share. And I think there could be reasons the sender don't want to show the encryption date. That's why I prefer that this should be (if at all) an optional feature. Also I think the feature won't bring an additional value for the most users.

Well, I know, the security issues are largely theoretical. But, as said, I think there could be a reason someday.

@Fastidious

This comment has been minimized.

Show comment
Hide comment
@Fastidious

Fastidious Aug 13, 2014

I like the timestamp feature. +1

Fastidious commented Aug 13, 2014

I like the timestamp feature. +1

@cathalgarvey

This comment has been minimized.

Show comment
Hide comment
@cathalgarvey

cathalgarvey Aug 13, 2014

I'm with @kaepora, @45678 - I've considered adding extensions to fileInfo, too, and decided against it.
The problem is that right now, fileInfo has a deterministic length. If you start adding anything to it, then it becomes obvious that you're using a non-standard client, which opens users of your client to profiling. One of miniLock's features is that sender and recipient cannot be inferred by looking at the miniLock file, but you weaken that guarantee if statistics based on header size can narrow down which client was used.

I'd like a bunch of things to be added to miniLock's fileinfo header (like mimetypes, so you can write software that distinguishes between files and display-as-is text, like email does with text or attachments), but two things need to happen:

  • Write the extension so that the extended data has a constant length no matter the value.
  • Bump version number, as @kaepora has said,
  • Always, always include the keys when using that version number with values of equal length, even if the values are meaningless, so that the fileInfo header size remains constant.

Anyway, that's my view; I won't be adding any extensions to deadlock until there's a new format, and that format should be agreed upon and implemented exactly alike by all miniLock implementors.

cathalgarvey commented Aug 13, 2014

I'm with @kaepora, @45678 - I've considered adding extensions to fileInfo, too, and decided against it.
The problem is that right now, fileInfo has a deterministic length. If you start adding anything to it, then it becomes obvious that you're using a non-standard client, which opens users of your client to profiling. One of miniLock's features is that sender and recipient cannot be inferred by looking at the miniLock file, but you weaken that guarantee if statistics based on header size can narrow down which client was used.

I'd like a bunch of things to be added to miniLock's fileinfo header (like mimetypes, so you can write software that distinguishes between files and display-as-is text, like email does with text or attachments), but two things need to happen:

  • Write the extension so that the extended data has a constant length no matter the value.
  • Bump version number, as @kaepora has said,
  • Always, always include the keys when using that version number with values of equal length, even if the values are meaningless, so that the fileInfo header size remains constant.

Anyway, that's my view; I won't be adding any extensions to deadlock until there's a new format, and that format should be agreed upon and implemented exactly alike by all miniLock implementors.

@kaepora

This comment has been minimized.

Show comment
Hide comment
@kaepora
Owner

kaepora commented Aug 14, 2014

@jdluzen

This comment has been minimized.

Show comment
Hide comment
@jdluzen

jdluzen Aug 14, 2014

Though I understand @cathalgarvey's concerns, could we do something like pad/round up the header to the next 256/512/etc. bytes?

jdluzen commented Aug 14, 2014

Though I understand @cathalgarvey's concerns, could we do something like pad/round up the header to the next 256/512/etc. bytes?

@Fastidious

This comment has been minimized.

Show comment
Hide comment
@Fastidious

Fastidious Aug 15, 2014

If digital signing were to be added to miniLock in the future (keeping fingers crossed), having this information (date/time) on headers will be needed, no? Whether it means a bump on protocol number or not, I still think this is a good idea.

Fastidious commented Aug 15, 2014

If digital signing were to be added to miniLock in the future (keeping fingers crossed), having this information (date/time) on headers will be needed, no? Whether it means a bump on protocol number or not, I still think this is a good idea.

@cathalgarvey

This comment has been minimized.

Show comment
Hide comment
@cathalgarvey

cathalgarvey Aug 15, 2014

There are plenty of things that'd make good header extensions, but
better to collect such ideas for a while and implement version 2 all at
once, rather than have lots of little versions, for the same reason I
suggested above. You don't want lots of different header sizes allowing
network-level observers to cluster people by protocol version, as that
weakens the anonymity properties of the system.

So, if after a few months we have a list of things like "isSigned",
"mimeType", "encryptedAt", etcetera, we can add them all at once (and
double the size of the header block, but everything comes with a cost)
and bump the version only once. Implementors would then have to
implement the same header length at least, even if it means filling in
the new fields with evenly sized rubbish.

On 15/08/14 13:19, Fastidious wrote:

If digital signing were to be added to miniLock in the future (keeping fingers crossed), having this information (date/time) on headers will be needed, no? Whether is means a bump on protocol number or not, I still think this is a good idea.


Reply to this email directly or view it on GitHub:
#136 (comment)

Twitter: @onetruecathal, @formabiolabs
Phone: +353876363185
Blog: http://indiebiotech.com
miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM

cathalgarvey commented Aug 15, 2014

There are plenty of things that'd make good header extensions, but
better to collect such ideas for a while and implement version 2 all at
once, rather than have lots of little versions, for the same reason I
suggested above. You don't want lots of different header sizes allowing
network-level observers to cluster people by protocol version, as that
weakens the anonymity properties of the system.

So, if after a few months we have a list of things like "isSigned",
"mimeType", "encryptedAt", etcetera, we can add them all at once (and
double the size of the header block, but everything comes with a cost)
and bump the version only once. Implementors would then have to
implement the same header length at least, even if it means filling in
the new fields with evenly sized rubbish.

On 15/08/14 13:19, Fastidious wrote:

If digital signing were to be added to miniLock in the future (keeping fingers crossed), having this information (date/time) on headers will be needed, no? Whether is means a bump on protocol number or not, I still think this is a good idea.


Reply to this email directly or view it on GitHub:
#136 (comment)

Twitter: @onetruecathal, @formabiolabs
Phone: +353876363185
Blog: http://indiebiotech.com
miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM

@45678

This comment has been minimized.

Show comment
Hide comment
@45678

45678 Aug 15, 2014

I will try to make another version of this where mime type and encryption time are stored in the ciphertext in the same fashion as the original filename.

45678 commented Aug 15, 2014

I will try to make another version of this where mime type and encryption time are stored in the ciphertext in the same fashion as the original filename.

@45678

This comment has been minimized.

Show comment
Hide comment
@45678

45678 Aug 19, 2014

Thanks to everyone who chimed in on this thread.

I have re-thought my proposal for a new version of the miniLock file format. I don’t have any code to bring to miniLock right now but I have prepared a document that explains the format that I have in mind. Take a look at https://45678.github.io/miniLock-file-format/2 if you are curious.

The changes from version 1 are highlighted in this section:
https://45678.github.io/miniLock-file-format/2#the_first_chunk

45678 commented Aug 19, 2014

Thanks to everyone who chimed in on this thread.

I have re-thought my proposal for a new version of the miniLock file format. I don’t have any code to bring to miniLock right now but I have prepared a document that explains the format that I have in mind. Take a look at https://45678.github.io/miniLock-file-format/2 if you are curious.

The changes from version 1 are highlighted in this section:
https://45678.github.io/miniLock-file-format/2#the_first_chunk

@45678 45678 changed the title from When was this file encrypted? to miniLock file format version 2 Aug 19, 2014

@Fastidious

This comment has been minimized.

Show comment
Hide comment
@Fastidious

Fastidious commented Aug 19, 2014

@45678 Amazing work!

@45678

This comment has been minimized.

Show comment
Hide comment
@45678

45678 Aug 19, 2014

You are too kind @Fastidious. Thank you.

45678 commented Aug 19, 2014

You are too kind @Fastidious. Thank you.

@kaepora

This comment has been minimized.

Show comment
Hide comment
@kaepora

kaepora Aug 19, 2014

Owner

@45678 You are an incredibly talented interface designer. What an amazing interactive overview of the miniLock protocol.

Owner

kaepora commented Aug 19, 2014

@45678 You are an incredibly talented interface designer. What an amazing interactive overview of the miniLock protocol.

@kaepora

This comment has been minimized.

Show comment
Hide comment
@kaepora

kaepora Aug 19, 2014

Owner

By the way, while this is a beautiful overview of the protocol, I do not think encryptedAt is a good idea, because it is extremely easy for the sender to fake the time.

Owner

kaepora commented Aug 19, 2014

By the way, while this is a beautiful overview of the protocol, I do not think encryptedAt is a good idea, because it is extremely easy for the sender to fake the time.

@Fastidious

This comment has been minimized.

Show comment
Hide comment
@Fastidious

Fastidious Aug 19, 2014

@kaepora I do not see your point, can you please explain? I know I can change my computer date/time, so date/time is never important then?

Fastidious commented Aug 19, 2014

@kaepora I do not see your point, can you please explain? I know I can change my computer date/time, so date/time is never important then?

@Fastidious

This comment has been minimized.

Show comment
Hide comment
@Fastidious

Fastidious Aug 19, 2014

GPG would do something like this:

gpg: Signature made Tue Aug 19 14:31:54 2014 EDT using RSA key ID XXXXXXX

Fastidious commented Aug 19, 2014

GPG would do something like this:

gpg: Signature made Tue Aug 19 14:31:54 2014 EDT using RSA key ID XXXXXXX

@cathalgarvey

This comment has been minimized.

Show comment
Hide comment
@cathalgarvey

cathalgarvey Aug 19, 2014

I'm also curious to know how it would present a security hazard,
provided it was only there for use in an informational role and never
part of a security protocol.

For example, I can set false time headings on emails, and possibly even
slip them by a few SMTP implementations out there in order to stay on
top of someone's inbox, but at worst that's annoying rather than a
security flaw (although I'm totally gonna try this, now). I can also
arbitrarily alter the timestamps on received mail in my own inbox,
probably including GPG encrypted messages from others as the headers are
not normally signed in ASCII armoured messages IIRC. But again, aside
from abuse of tech-illiterate courts this isn't normally considered a
security flaw.

On 19/08/14 19:43, Fastidious wrote:

GPG would do something like this:

gpg: Signature made Tue Aug 19 14:31:54 2014 EDT using RSA key ID XXXXXXX


Reply to this email directly or view it on GitHub:
#136 (comment)

Twitter: @onetruecathal, @formabiolabs
Phone: +353876363185
Blog: http://indiebiotech.com
miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM

cathalgarvey commented Aug 19, 2014

I'm also curious to know how it would present a security hazard,
provided it was only there for use in an informational role and never
part of a security protocol.

For example, I can set false time headings on emails, and possibly even
slip them by a few SMTP implementations out there in order to stay on
top of someone's inbox, but at worst that's annoying rather than a
security flaw (although I'm totally gonna try this, now). I can also
arbitrarily alter the timestamps on received mail in my own inbox,
probably including GPG encrypted messages from others as the headers are
not normally signed in ASCII armoured messages IIRC. But again, aside
from abuse of tech-illiterate courts this isn't normally considered a
security flaw.

On 19/08/14 19:43, Fastidious wrote:

GPG would do something like this:

gpg: Signature made Tue Aug 19 14:31:54 2014 EDT using RSA key ID XXXXXXX


Reply to this email directly or view it on GitHub:
#136 (comment)

Twitter: @onetruecathal, @formabiolabs
Phone: +353876363185
Blog: http://indiebiotech.com
miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM

@kaepora

This comment has been minimized.

Show comment
Hide comment
@kaepora

kaepora Aug 19, 2014

Owner

I guess the question is whether we are guaranteeing the integrity of the given time or just displaying to to the user informationally, and whether the user can tell the difference.

Owner

kaepora commented Aug 19, 2014

I guess the question is whether we are guaranteeing the integrity of the given time or just displaying to to the user informationally, and whether the user can tell the difference.

@Fastidious

This comment has been minimized.

Show comment
Hide comment
@Fastidious

Fastidious Aug 19, 2014

@kaepora it will simply mean that when the file was encrypted, the sender's machine had XX:XX time. And once it is encrypted, the time on the encrypted file can't be changed, correct?

Fastidious commented Aug 19, 2014

@kaepora it will simply mean that when the file was encrypted, the sender's machine had XX:XX time. And once it is encrypted, the time on the encrypted file can't be changed, correct?

@cathalgarvey

This comment has been minimized.

Show comment
Hide comment
@cathalgarvey

cathalgarvey Aug 19, 2014

That makes me think even further, and realise that we're muddying up
something fundamental.

The header in minilock is ONLY for encryption and validation, at present
it's not used for anything else. Even the filename is made a special
leading block, instead of being in the header.

Even my own suggestion of putting mimeTypes in there is incorrect;
that's an implementor detail that is unrelated to the cryptographic
system of miniLock, so it has no place in the miniLock header.

May I suggest, instead, that as aforementioned we consider a more
dramatic change overall for V2: Expand the concept of a special leading
block (currently only the filename) to become a "metadata block" of
arbitrary block-number, which contains another JSON entry containing
implementor-defined data, plus at-minimum a filename.

That is, the proposed miniLock v2 would consist of:
miniLock|hdr_len|header|metadata|encrypted_data

The header would continue to contain only data needed to verify and
decrypt the metadata and encrypted data. It would need one additional
key to specify the number of blocks occupied by the metadata (usually
only one, as blocks can be 1Mb in size).

I'd propose we also have an overall block count and a final-block-length
keysfor the reason that otherwise junk added by a petty attacker to the
end of the file would lead to failed authentication of the (normally
shorter than 1Mb) final block, which would kill decryption of the whole
file; I'll open another issue to explore this concept.

By pushing metadata into a defined new area, you can let implementors do
whatever they damned like with the encrypted data and provide as much or
as little informational data to recipients as they like, but it won't
change the header length and the length and content of the metadata
extensions are completely opaque to an outside attacker.

On 19/08/14 20:33, Nadim Kobeissi wrote:

I guess the question is whether we are guaranteeing the integrity of the given time or just displaying to to the user informationally, and whether the user can tell the difference.


Reply to this email directly or view it on GitHub:
#136 (comment)

Twitter: @onetruecathal, @formabiolabs
Phone: +353876363185
Blog: http://indiebiotech.com
miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM

cathalgarvey commented Aug 19, 2014

That makes me think even further, and realise that we're muddying up
something fundamental.

The header in minilock is ONLY for encryption and validation, at present
it's not used for anything else. Even the filename is made a special
leading block, instead of being in the header.

Even my own suggestion of putting mimeTypes in there is incorrect;
that's an implementor detail that is unrelated to the cryptographic
system of miniLock, so it has no place in the miniLock header.

May I suggest, instead, that as aforementioned we consider a more
dramatic change overall for V2: Expand the concept of a special leading
block (currently only the filename) to become a "metadata block" of
arbitrary block-number, which contains another JSON entry containing
implementor-defined data, plus at-minimum a filename.

That is, the proposed miniLock v2 would consist of:
miniLock|hdr_len|header|metadata|encrypted_data

The header would continue to contain only data needed to verify and
decrypt the metadata and encrypted data. It would need one additional
key to specify the number of blocks occupied by the metadata (usually
only one, as blocks can be 1Mb in size).

I'd propose we also have an overall block count and a final-block-length
keysfor the reason that otherwise junk added by a petty attacker to the
end of the file would lead to failed authentication of the (normally
shorter than 1Mb) final block, which would kill decryption of the whole
file; I'll open another issue to explore this concept.

By pushing metadata into a defined new area, you can let implementors do
whatever they damned like with the encrypted data and provide as much or
as little informational data to recipients as they like, but it won't
change the header length and the length and content of the metadata
extensions are completely opaque to an outside attacker.

On 19/08/14 20:33, Nadim Kobeissi wrote:

I guess the question is whether we are guaranteeing the integrity of the given time or just displaying to to the user informationally, and whether the user can tell the difference.


Reply to this email directly or view it on GitHub:
#136 (comment)

Twitter: @onetruecathal, @formabiolabs
Phone: +353876363185
Blog: http://indiebiotech.com
miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM

@cathalgarvey

This comment has been minimized.

Show comment
Hide comment
@cathalgarvey

cathalgarvey Aug 19, 2014

Actually, sorry; I mistakenly thought this thread was an issue relating only to the encrypted-when issue, but it's overall about V2. So I'll include my thoughts here on the block-num (ignore last-block-length I mentioned previously, I'd forgotten they're all length prefixed anyway) extension I'd like to see in the primary decryptData field, separate to my now firm belief that we need a new designated dump-your-extensions-here JSON header for the file itself.

Essentially, a DOS attack is easy to imagine on current implementations because the streaming decryptors don't know when a file might end. It's easy for an attacker to modify the length prefix on the final block and to just keep adding junk, perhaps copies of prior blocks to pass NaCl authentication checks. As the decryptor keeps receiving blocks, it will never check the ciphertext hash so it won't detect modifications in time to fail early and abort. This could waste time and bandwidth, or it could screw up decryption, or it could crash the program by filling up memory. Generally, it could discourage users from using mini/dead-lock style encryption.

By simply including a block-length key to the decryptInfo entries, you allow implementations to stream only the number of blocks expected before checking the BLAKE2 hash, and to fail early if there are too many.

Thoughts and criticism welcome.

cathalgarvey commented Aug 19, 2014

Actually, sorry; I mistakenly thought this thread was an issue relating only to the encrypted-when issue, but it's overall about V2. So I'll include my thoughts here on the block-num (ignore last-block-length I mentioned previously, I'd forgotten they're all length prefixed anyway) extension I'd like to see in the primary decryptData field, separate to my now firm belief that we need a new designated dump-your-extensions-here JSON header for the file itself.

Essentially, a DOS attack is easy to imagine on current implementations because the streaming decryptors don't know when a file might end. It's easy for an attacker to modify the length prefix on the final block and to just keep adding junk, perhaps copies of prior blocks to pass NaCl authentication checks. As the decryptor keeps receiving blocks, it will never check the ciphertext hash so it won't detect modifications in time to fail early and abort. This could waste time and bandwidth, or it could screw up decryption, or it could crash the program by filling up memory. Generally, it could discourage users from using mini/dead-lock style encryption.

By simply including a block-length key to the decryptInfo entries, you allow implementations to stream only the number of blocks expected before checking the BLAKE2 hash, and to fail early if there are too many.

Thoughts and criticism welcome.

@cathalgarvey

This comment has been minimized.

Show comment
Hide comment
@cathalgarvey

cathalgarvey Aug 19, 2014

More thoughts; by making metadata occupy their own blocks you force them to occupy at least 1Mb which unnecessarily bloats the file size. So, instead just prepend metadata to the plaintext and encrypt as normal, and add a key to decryptInfo offering the size of the metadata prefix, instead.

To clarify the foregoing for the (justified) TL;DR crowd, I propose the following:

  • Replace the filename leading block with a JSON object, the encoded length of which is placed in decryptInfo.
  • Add to decryptInfo the length of the new metadata JSON prefix, so it can be safely decoded.
  • Add to decryptInfo the total number of ciphertext blocks, so it can fail early on length extension DOS attacks.
  • Allow arbitrary data in the metadata block, but require at least a "fileName" key to replace the current 256-byte leading ciphertext block.

cathalgarvey commented Aug 19, 2014

More thoughts; by making metadata occupy their own blocks you force them to occupy at least 1Mb which unnecessarily bloats the file size. So, instead just prepend metadata to the plaintext and encrypt as normal, and add a key to decryptInfo offering the size of the metadata prefix, instead.

To clarify the foregoing for the (justified) TL;DR crowd, I propose the following:

  • Replace the filename leading block with a JSON object, the encoded length of which is placed in decryptInfo.
  • Add to decryptInfo the length of the new metadata JSON prefix, so it can be safely decoded.
  • Add to decryptInfo the total number of ciphertext blocks, so it can fail early on length extension DOS attacks.
  • Allow arbitrary data in the metadata block, but require at least a "fileName" key to replace the current 256-byte leading ciphertext block.
@cathalgarvey

This comment has been minimized.

Show comment
Hide comment
@cathalgarvey

cathalgarvey Aug 19, 2014

Have suggested another, more radical extension for V2 which would dovetail nicely with an arbitrary metadata block: multi-file miniLocks!

cathalgarvey commented Aug 19, 2014

Have suggested another, more radical extension for V2 which would dovetail nicely with an arbitrary metadata block: multi-file miniLocks!

@45678

This comment has been minimized.

Show comment
Hide comment
@45678

45678 Aug 20, 2014

@kaepora, my intention is for encrypt time to be informational. It is not guaranteed to be accurate but it is guaranteed to be the same time that was set by the author of the file.

It is similar to the filename situation we have currently in version 1. miniLock can’t guarantee that the filename is accurate (the encrypted blob might be something quite different). But miniLock can guarantee that the filename set by the author is the same as the filename received by a recipient.

45678 commented Aug 20, 2014

@kaepora, my intention is for encrypt time to be informational. It is not guaranteed to be accurate but it is guaranteed to be the same time that was set by the author of the file.

It is similar to the filename situation we have currently in version 1. miniLock can’t guarantee that the filename is accurate (the encrypted blob might be something quite different). But miniLock can guarantee that the filename set by the author is the same as the filename received by a recipient.

@45678

This comment has been minimized.

Show comment
Hide comment
@45678

45678 Aug 20, 2014

And I totally agree that the onscreen interface should be as clear as possible @kaepora. It is important to set expectations clearly regarding the integrity and potential accuracy of received bytes.

45678 commented Aug 20, 2014

And I totally agree that the onscreen interface should be as clear as possible @kaepora. It is important to set expectations clearly regarding the integrity and potential accuracy of received bytes.

@45678

This comment has been minimized.

Show comment
Hide comment
@45678

45678 Aug 20, 2014

@cathalgarvey, I think you may have misunderstood my proposal and I am very sorry about that. I should have explained it better.

My version 2 draft does not make any changes to the file header. The name, type and time attributes are all part of the first chunk of ciphertext.

45678 commented Aug 20, 2014

@cathalgarvey, I think you may have misunderstood my proposal and I am very sorry about that. I should have explained it better.

My version 2 draft does not make any changes to the file header. The name, type and time attributes are all part of the first chunk of ciphertext.

@cathalgarvey

This comment has been minimized.

Show comment
Hide comment
@cathalgarvey

cathalgarvey Aug 20, 2014

I see that, it's what I meant when I said "aforementioned". Rather than
new keys in the main header, use the leader sequence to encode arbitrary
metadata.

What I propose as an alternative to your suggestion is that we add an
arbitrary metadata extension in this area with minimal required keys
(at present, just "fileName"), and merely require the version 2 header
to include a length cue to permit easy decoding of this metadata block.

What implementors do with the metadata block is entirely up to them; I'd
personally like to see some creative uses of this block like offering
decoding cues for multi-file miniLocks, for example, or to offer a
mimeType and "suggest" to clients whether to offer file download or
immediately display plain-text contents. Using the metadata block for
mimeTypes could allow email-like text-plus-attachments behaviour, or
torrent-like many-files-many-directories behaviour.

Basically if we're going to have metadata, the contents of which will be
obscured as part of the ciphertext and therefore not subject to length
analysis and user-client profiling based upon that, then we may as well
make it arbitrary in nature and let implementations decide what to do
with it?

On 20/08/14 01:14, 45678 wrote:

@cathalgarvey, I think you may have misunderstood my proposal and I am very sorry about that. I should have explained it better.

My version 2 draft does make any changes to the file header. The name, type and time attributes are all part of the first chunk of ciphertext in my proposal.


Reply to this email directly or view it on GitHub:
#136 (comment)

Twitter: @onetruecathal, @formabiolabs
Phone: +353876363185
Blog: http://indiebiotech.com
miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM

cathalgarvey commented Aug 20, 2014

I see that, it's what I meant when I said "aforementioned". Rather than
new keys in the main header, use the leader sequence to encode arbitrary
metadata.

What I propose as an alternative to your suggestion is that we add an
arbitrary metadata extension in this area with minimal required keys
(at present, just "fileName"), and merely require the version 2 header
to include a length cue to permit easy decoding of this metadata block.

What implementors do with the metadata block is entirely up to them; I'd
personally like to see some creative uses of this block like offering
decoding cues for multi-file miniLocks, for example, or to offer a
mimeType and "suggest" to clients whether to offer file download or
immediately display plain-text contents. Using the metadata block for
mimeTypes could allow email-like text-plus-attachments behaviour, or
torrent-like many-files-many-directories behaviour.

Basically if we're going to have metadata, the contents of which will be
obscured as part of the ciphertext and therefore not subject to length
analysis and user-client profiling based upon that, then we may as well
make it arbitrary in nature and let implementations decide what to do
with it?

On 20/08/14 01:14, 45678 wrote:

@cathalgarvey, I think you may have misunderstood my proposal and I am very sorry about that. I should have explained it better.

My version 2 draft does make any changes to the file header. The name, type and time attributes are all part of the first chunk of ciphertext in my proposal.


Reply to this email directly or view it on GitHub:
#136 (comment)

Twitter: @onetruecathal, @formabiolabs
Phone: +353876363185
Blog: http://indiebiotech.com
miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM

@45678 45678 closed this Sep 4, 2014

@45678 45678 deleted the 45678:time branch Sep 8, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment