how to implement one time pad encryption for images?

One time pad is an interesting method i implemented it on alphabets .I need help in implementing it on images?

[Image Analyst]

I don't know what this is but I don't think the Mathworks wants discussion of encryption on their servers. Now, encoding is okay, but not encryption. (I know from personal experience!)

[Bjorn Gustavsson]

Care to expand why one-time-pad encryption would be sensitive?

[Walter Roberson]

Discussion of One Time Pad is prohibited without advance permission from a branch of the government of the USA. The criteria is whether the encryption protocol "could" be extended beyond 56 bits of key by the user, and for One Time Pads the answer is a huge Yes, that the key is the length of the message itself.

[megha prabhu]

Thank you i had no idea about that i came across a IEEE research paper on this so thought i could work on it

[Walter Roberson]

One Time Pad is considered the most secure encryption in itself. However it suffers badly from "the key distribution problem".

[David Goodmanson]

Hello Walter, do you have a reference you could cite for discussion of one time pad being prohibited without government permission?

[Walter Roberson]

https://epic.org/crypto/export_controls/regs_1_00.html

"2. In §740.13, Technology and Software Unrestricted, changes are made to reflect amendments to the Wassenaar Arrangement. Specifically, encryption software is no longer eligible for mass market treatment under the General Software Note. Encryption commodities and software are now eligible for mass market treatment under the new Cryptography Note in Category 5 - Part 2 of the CCL. This Note multilaterally decontrols mass market encryption commodities and software up to and including 64-bits. Such products, after review and classification by BXA, are classified under Export Commodity Control Numbers (ECCNs) 5A992 or 5D992, thereby releasing them from "EI" (Encryption Items) and "NS" (National Security) controls, and making them eligible for export and reexport to all destinations (see §742.15(b)(1)(iii) of the EAR). Once mass market encryption software and commodities are released from "EI" controls they may be eligible for de minimis and publicly available treatment (see part 734 of the EAR)."

However, if you examine the details:

https://www.bis.doc.gov/index.php/forms-documents/encryption/335-supplement-no-1-to-part-774-category-5-part-ii-information-security/file

"N.B. to Note 3 (Cryptography Note): You must submit a classification request or encryption registration to BIS for mass market encryption commodities and software eligible for the Cryptography Note employing a key length greater than 64 bits for the symmetric algorithm (or, for commodities and software not implementing any symmetric algorithms, employing a key length greater than 768 bits for asymmetric algorithms or greater than 128 bits for elliptic curve algorithms) in accordance with the requirements of § 742.15(b) of the EAR in order to be released from the “EI” and “NS” controls of ECCN 5A002 or 5D002. "

For anything posted on Mathwork's servers in the USA and made available outside the USA, Mathworks would be considered the entity responsible for submitting the classification requests or encryption registrations, and those requests would have to be done and approved before the material could be made available outside of the USA. This is not practical: it would require pre-approval of every question and answer and comment... and of course a lot of cost. Easier by far to say that such material is not permitted.

Then there is:

"Note 3: Cryptography Note: ECCNs 5A002 and 5D002 do not control items that meet all of the following [...]

b. The cryptographic functionality cannot be easily changed by the user"

Because nearly all software in the source can be easily changed by the user to increase the key length (even a simple Caesar Cypher can be arbitrarily extended), the general releases permitted do not apply and it is necessary to go through the more controlled approval-required routes every time, for every post.

And notice under 5E002:

"License Requirement Note: When a person performs or provides technical assistance that incorporates, or otherwise draws upon, “technology” that was either obtained in the United States or is of US origin, then a release of the “technology” takes place. Such technical assistance, when rendered with the intent to aid in the “development” or “production” of encryption commodities or software that would be controlled for “EI” reasons under ECCN 5A002 or 5D002, may require authorization under the EAR even if the underlying encryption algorithm to be implemented is from the public domain or is not of U.S. origin"

Therefore it is not just the people asking the questions that are affected: every volunteer that answers is considered to be "releasing" technology even for algorithms in the public domain.

The public domain software exemptions for complete software (rather than discussion of implementation and debugging) do not require prior approval, but they do require that the person doing the software release notify BIS at the time of the release.

[Jan]

@megha prabhu: "i came across a IEEE research paper" Yes, of course. And you are allowed to work on it. As long as it is written to paper (or a PDF) the distribution is allowed even in the US. See NIST: AES encryption (see: PDF). It is allowed to publish the details of 128 bit encryption in written form, because then it is covered by the freedom of speech. Even the pseudo code or an example implementation in C can be published in a PDF - but not as source code.

A strong AES encryption is implemented in each internet browser and in java also, but the 3 lines of Matlab code to call the java function are not allowed to be published on servers, which are hosted in the USA, because you would support evil nations or terrorists to hide their secrets. Therefore all AES implementations have been removed from the FileExchange. I'm not sure if discussing in the forum belongs to "freedom of speech" or to "exporting source code to potential evil nations".

This is far beyond any logic.

[David Goodmanson]

Thanks Walter, lots of good information. And thanks Jan, for the clarification.

As far as the one time pad, the 64, 768 and 128 bit rules appear to refer to specific algorithms. The one time pad does seem like a different animal. It contains a huge number of bits all right, but unlike those algorithms it comes with a distribution problem as Walter mentioned, which is ongoing all the time. And it can't be broken, so continual improvement of the algorithm is not an issue. So I'm curious about the following:

Let's say I (a) write a piece of software to create one time pads. (b) trusting the mail, I put a one time pad on a flash drive and send it to my friend Paul in Quintana Roo, Mexico. (c) I write some software to code and decode messages. This can be really simple since the one time pad is doing all the work. (d) I email that software to Paul. (e) I encode King Lear and email that to Paul so he can decode it.

Would this be illegal? And if I have a discussion with anybody in or out of the country about software improvements in (a) and (c), would this be illegal also?

[Walter Roberson]

Typical OTP is done by just XOR'ing the data with the key. Because the same key is used to both encrypt and decrypt, that counts as a symmetric system, the key limit for which is 64 bits before some of the provisions kick in. So you could encrypt 8 bytes. You might be tempted to just keep repeating those 8 bytes of key, but if you do so then it is not OTP and is relatively easily susceptible to statistical analysis.

"And it can't be broken, so continual improvement of the algorithm is not an issue."

However, given source code (what we are talking about here) then it is likely very easy to just extend the maximum length of the key, violating the requirement that "The cryptographic functionality cannot be easily changed by the user"

"Would this be illegal?"

I do not know. I do not have enough background in encryption case law to understand what the boundaries are of the permitted uses. For example would you be emailing the software in source or in compiled form? Compiled form would not be easily changed by the user, so different sections might kick in.

Answer 1

[Jan]

Your problem does not concern Matlab, but US laws about exporting information which is considered to be relevant for warfare and terrorism. Although Walter has a reliable knowledge about legal questions, I'd really rely only on answers given by the U.S. Dept. of Commerce, Bureau of Industry and Security in written form.

I cannot reconsider why publishing C-code in a PDF is legal, while posting the 3 lines of java code in the forum is not. It matters, if I copy&paste the code from the PDF-viewer or HTML-browser. And it does not concern a cheap copyright infringement, but "exporting technology concerning warfare".

I had published a Matlab implementation of 128-bit AES encryption in the FileExchange. After it could be downloaded for 2 years and was a pick of the week, MathWorks removed it to avoid serious troubles. I'm still allowed to use my function and share it on servers outside the USA. If I limit the key length to 56 bit, posting it as code would be legal again - although any Matlab programmer could remove the artificial limit easily by editing the source code. Nevertheless, it is possible that I'm being accused to support terrorism.

You need a lawyer, who discusses your problem with the U.S. Dept. of Commerce, Bureau of Industry and Security and with the corresponding bureau in your own country. Your problem is beyond the topic of this forum.

[Walter Roberson]

It is not the DHS that is responsible, it is the Bureau of Industry and Security, of the US Department of Commerce.

[Jan]

Thanks for the clarification, Walter. I've fixed it.