InstaHide: Instance-hiding Schemes for Private Distributed Learning
Yangsibo Huang, Zhao Song, Kai Li, Sanjeev Arora
Introduction
In many applications, multiple parties or clients with sensitive data want to collaboratively train a neural network. For instance, hospitals may wish to train a model on their patient data. However, aggregating data to a central server may violate regulations such as Health Insurance Portability and Accountability Act (HIPAA) [Act96] and General Data Protection Regulation (GDPR) [VVdB18].
Federated learning [MMR+17, KMY+16] proposes letting participants train on their own data in a distributed fashion and share only model updates —i.e., gradients—with the central server. The server aggregates these updates (typically by averaging) to improve a global model and then sends updates to participants. This process runs iteratively until the global model converges. Merging information from individual data points into aggregated gradients intuitively preserves privacy to some degree. On top of that, it is possible to add noise to gradients in accordance with Differential Privacy (DP) [DKM+06, DR14], though careful calculations are needed to compute the amount of noise to be added [ACG+16, PCS+19]. However, the privacy guarantee of DP only applies to the trained model (i.e., approved use of data) and does not apply to side-channel computations performed by curious/malicious parties who are privy to the communicated gradients. Recent work [ZLH19] suggests that eavesdropping attackers can recover private inputs from shared model updates, even when DP was used. A more serious issue with DP is that meaningful guarantees involve adding so much noise that test accuracy reduces by over even on CIFAR-10 [PCS+19].
Cryptographic methods such as secure multiparty computation of [Yao82] and fully-homomorphic encryption [Gen09] can ensure privacy against arbitrary side-computations by adversary during training. Unfortunately it is a challenge to use them in modern deep learning settings, owing to their high computational overheads and their needs for special setups (e.g finite field arithmetic, public-key infrastructure).
Here we introduce a new method InstaHide, inspired by a weaker cryptographic idea of instance hiding schemes [AFK87]. We only apply it to image data in this paper and leave other data types (e.g., text) for future work. InstaHide gives a way to transform input to a hidden/encrypted input in each epoch such that: (a) Training deep nets using the ’s instead of ’s gives nets almost as good in terms of final accuracy; (b) Known methods for recovering information about out of are computationally very expensive. In other words, effectively hides information contained in except for its label.
InstaHide encryption has two key components. The first is inspired by Mixup data augmentation method [ZCDLP18], which trains deep nets on composite images created via linear combination of pairs of images (viewed as vectors of pixel values). In InstaHide the first step when encrypting image (see Figure 1) is to take its linear combination with randomly chosen images from either the participant’s private training set or from a large public dataset (e.g., ImageNet [DDS+09]). The second step of InstaHide involves applying a random pattern of sign flips on the pixel values of this composite image, yielding encrypted image , which can be used as-is in existing deep learning frameworks. Note that the set of random images for mixing and the random sign flipped mask are used only once —in other words, as a one-time key that is never re-used for another encryption.
Experiments on MNIST, CIFAR-10, CIFAR-100 and ImageNet datasets (see Section 5) suggest that InstaHide is an effective approach to hide training images from attackers. It is much more effective at hiding images than Mixup alone and provides better trade-off between privacy preservation and accuracy than DP. To enable further rigorous study of attacks, we release a challenge dataset of images encrypted using InstaHide.
As hinted above, InstaHide plugs seamlessly into existing distributed learning frameworks such as federated learning: clients encrypt their inputs on the fly with InstaHide and participate in training (without using DP). Depending upon the level of security needed in the application (see Section 4.1), InstaHide can also be used to present enhanced functionality that are unsafe in current distributed frameworks. For instance, in each epoch, computationally limited clients can encrypt each private input to and ship it to the central server for all subsequent computation. The server may randomize in the pooled data to create its own batches to deal with special learning situations when distributed data are not independent and identically distributed.
Security goal of InstaHide.
The goal of InstaHide is to provide a light-weight encryption method to make it difficult for attackers to recover the training data in a large training dataset in a distributed learning setting, with minor reduction on data utility. It is not designed to provide the level of security strength as encryption methods such as RSA [RSA78]. It is an initial step towards exploring better privacy preservation while maintaining data utility.
Rest of the Paper:
Section 2 recaps Mixup and suggests it alone is not secure. Section 3 presents two InstaHide schemes, and Section 4 analyzes their securityA recent attack [CDG+20] (see Section 9 for details) suggests that the security analysis for InstaHide in the current version may need some revisions. We will release an update with more extensive explanations.. Section 5 shows experiments for InstaHide’s efficiency, efficacy, and security. Section 6 provides suggestions for practical use, and Section 7 describes the challenge dataset. We review related work in Section 8, discuss potential attacks in Section 9 and conclude in Section 10.
Mixup and Its Vulnerability
See Algorithm 1. Given an original dataset, in each epoch of the training the algorithm generates a Mixup dataset on the fly, by linearly combining random samples, as well as their labels (lines 9, 10). Mixup suggests that training with mixed samples and mixed labels serves the purpose of data augmentation, and achieves better test accuracy on normal images.
We describe the algorithm as an operation on images, but previous works mostly used .
We propose an attack to the Mixup method when a private image is mixed up more than once during training. In fact, in Algorithm 1, each image is used times during training, where is the number of samples to mix, and is the number of training epochs.
Assume that pairs of images in are fairly independent at the pixel level, so that the inner product of a random pair of images (viewed as vectors) has expectation (expectation can be nonzero but small). We can think of each pixel is generated from some distribution with standard deviation and describe attacks with this assumption. (Section 5 presents experiments showing that these attacks do work in practice.)
Suppose we have two Mixup images and which are derived from two subsets of private images, and . If and contain different private images, namely , then the expectation of is 0. However, if , and and have coefficients and for the common image in these two sets, then the expectation of is , which means by simply checking the inner products between two ’s, the attacker can determine with high probability whether they are derived from the same image. Thus if the attacker finds multiple such pairs, they can average the ’s to start getting a good estimate of . (Note that the rest of images in the pairs are with high probability distinct and so average to .)
2 Attack on Mixup Between a Private and a Public Dataset
To defend against the previous attack, it seems that a possible method is to modify the Mixup method to mix a private image with images only once to get a single , and use this as surrogate for in all epochs. To ensure is used only once, it uses an additional public dataset (e.g. ImageNet). In other words, for every , it produces by using Mixup between and random images from a large public dataset.
This extension of the Mixup method seems secure at first glance, as naively one can imagine that to violate privacy, the adversary must do exhaustive search over -tuples of public images to determine which were mixed into , and try all possible -tuples of coefficients, and then subtract the corresponding sum from to extract . If this is true, it would suggest that extracting or any approximation to it requires work, where is the number of images in the public dataset. This work becomes infeasible even for . However, we sketch an attack below that runs in time.
It again uses the above assumption about the pairwise independence property of a random image pair. Recall that standard deviation of pixels is . Namely, to determine the images that went into the mixed sample , it suffices to go through each image in the dataset and examine the inner product . If is not one of the ’s then this inner product is of the order at most (see part 1 of Theorem B.3), whereas if it is one of the ’s then it is of the order at least (see part 2 of Theorem B.3). Thus if (which is true if the number of pixels is a few thousand) then the inner product gives a strong signal whether is one of the ’s. Once the correct ’s and their coefficients have been guessed, we obtain up to a linear scaling. Thus the above attack works with good probability and in time proportional to the size of the dataset. We provide results for this attack in Section 5.
This attack of course requires that is being mixed in with images from a public dataset . In the case that is private and diverse enough, it is conceivable that Mixup is safe. (MNIST for example may not be diverse enough but ImageNet probably is.) We leave it as an open question.
3 Discussions
Table 1 summarizes the security of Mixup . Only Mixup with single for each private and within a private dataset(s) has not been identified vulnerable to potential attacks. But this does not necessarily mean it is secure. In addition, the test accuracy in this case is not comparable to vanilla training; it incurs about accuracy loss with CIFAR-10 tasks.
Both methods may be vulnerable to the attacks presented in this section: when is linear (one example in [LWZ+19]), we have , which means the attacker can reconstruct the Mixup image from and run attacks on Mixup. For a nonlinear , may also hold.
InstaHide
This section first presents two schemes: Inside-dataset InstaHide and Cross-dataset InstaHide, and then describes their inference.
The Inside-dataset InstaHide mixes each training image with random images within the same private training dataset. The cross-dataset InstaHide, arguably more secure (see Section 4), involves mixing with random images from a large public dataset like ImageNet.
Algorithm 2 shows Inside-dataset InstaHide. Its encryption step includes mixing the secret image with other training images followed by an extra random pixel-wise sign-flipping mask on the composite image. Note that random sign flipping changes the color of a pixel. The motivation for random sign flips was described around Footnote 2.
Let denote the -dimensional random sign distribution such that , for , is independently chosen from with probability 1/2 each.
To encrypt a private input , we first determine the random coefficient ’s for image-wise combination, but with the constraint that they are at most to avoid dominant leakage of any single image (line 6 in Algorithm 2). Then we sample a random mask and apply , where is coordinate-wise multiplication of vectors (line 10 in Algorithm 2). Note that the random mask and the images used for mixing with , will not be reused to encrypt other images. They constitute a “random one-time private key.”
It may seem that using a different mask for each training sample would completely destroy the accuracy of the trained net, but as we will see later it has only a small effect when is small. Mathematically, this seems reminiscent of the phase retrieval problem [CSV13, LN18] (see Appendix D).
2 Cross-Dataset InstaHide
Cross-dataset InstaHide extends the encryption step of Algorithm 2 by mixing images from the private training dataset and a public dataset , and a random mask as a random one-time secret key.
Although the second dataset can be private, there are several motivations to use a public dataset: (a) Some privacy-sensitive datasets, (e.g. CT or MRI scans), feature images with certain structure patterns with uniform backgrounds. Mixing among such images as in Algorithm 2 would not hide information effectively. (b) Drawing mixing images from a larger dataset gives greater unpredictability, hence better security (see Section 4). (c) Public datasets are freely available and eliminate the need for special setups among participants in a distributed learning setting.
To mix images in the encryption step, we randomly choose images from and the other from , and apply InstaHide to all these images. The only difference in the cross-dataset scheme is that, the model is trained to learn only the (mixed) label of images. We assume images are unlabelled. For better accuracy, we lower bound the sum of coefficients of two private images by a constant .
We advocate preprocessing a public dataset in two steps to obtain for better security. The first is to randomly crop a number of patches from each image in the public dataset to form . This step will make much larger than the original public dataset. The second is to filter out the “flat” patches. In our implementation, we design a filter using SIFT [Low99], a feature extraction technique to retain patches with more than 40 key points.
3 Inference with InstaHide
Either scheme above by default applies InstaHide during inference, by averaging predictions of multiple encryptions (e.g. 10) of a test sample. This idea is akin to existing cryptographic frameworks for secure evaluation on a public server via homomorphic encryption (e.g. [MLS+20]). Since the encryption step of InstaHide is very efficient, the overhead of such inference is quite small.
One can also choose not to apply InstaHide during inference. We found in our experiments (Section 5) that it works for low-resolution image datasets such as CIFAR-10 but it does not work well with a high-resolution image dataset such as ImageNet.
Security Analysis
This section considers the security of InstaHide in distributed learning, specifically the cross-dataset version.
Attack scenario: In each epoch, all clients replace each (image, label)-pair in the training set with some using InstaHide. Attackers observe for some function : in federated learning could involve batch gradients or hidden-layer activations computed using input as well as other inputs.
Argument for security consists of two halves: (1) To recover significant information about an image from communicated information, computationally limited eavesdroppers/attackers have to break InstaHide encryption (Section 4.1). (2) Breaking InstaHide is difficult (Section 4.2).
Suppose an attacker exists that compromises an image in the protocol. We do the thought experiment of even providing the attacker with encryptions of all images belonging to all parties, as well as model parameters in each iteration. Now everything the attacker sees during the protocol it can efficiently compute by itself, and we can convert the attacker to one that, given , extracts information about . We conclude in this thought experiment that a successful attack on the protocol also yields a successful attack on the encryption. In other words, privacy loss during protocol is upper bounded by privacy loss due to the encryption itself. Of course, this proof allows the possibility that the protocol —due to aggregation of gradients, etc.—ensures even greater privacy than the encryption alone.
In our protocol each image is re-encrypted in each epoch. This seems to act as a data augmentation and improves accuracy. The above argument translated to this setting shows that privacy violation requires solving the following problem: private images were each encrypted times ( is size of the private training set, is number of epochs), each time using a new private key. Attacker is given these encryptions. Weaker task: Attacker has to identify which of them came from . Stronger task: Attacker has to identify .
We conjecture both tasks are hard. Visualization (see Figure 2) as well as the Kolmogorov–Smirnov test [Kol33, Smi48] (see Appendix E) suggest that statistically, it is difficult to distinguish among distributions of encryptions of different images. Thus, effectively identifying multiple ’s of same and using them to run attacks seems difficult.
2 Hardness of Attacking InstaHide Encryption
Now we consider the difficulty of recovering information about given a single encryption .
We start by considering the naive attack on cross-dataset InstaHide, which would involve the attacker to either figure out the set of all public images, or to compromise the mask and run attacks on Mixup. This should take time. For cross-dataset InstaHide schemes with a large public dataset (e.g. ImageNet), the computation cost of attack will be , and already makes the attack hard.
Now we suggest reasons why the naive attack may be best possible.
For worst-case pixel-vectors, finding the k𝑘k-image set is hard.
Of course, images are not worst-case vectors. Thus an attack must leverage this fact somehow. The obvious idea today is to use a deep net for the attack, and the experiments below will suggest the obvious ideas do not work.
Compromising the mask is also hard.
As previously discussed, the pixel-wise mask ( Def. 3.1) in InstaHide is kept private by each client, which is analogous to a private key (assuming the client never shares its own with others, and the generation of is statistically random). Brute-force algorithm consumes time to figure out , where can be several thousands in vision tasks.
Experiments
We have conducted experiments to answer three questions:
How much accuracy loss does InstaHide suffer (Section 5.1)?
How is the accuracy loss of InstaHide compared to differential privacy approaches (Section 5.2)?
Can InstaHide defend against known attacks (Section 5.3)?
We are particularly interested in the cases where .
Our main experiments are image classification tasks on four datasets MNIST [LCB10], CIFAR-10, CIFAR-100 [Kri09], and ImageNet [DDS+09]. We use ResNet-18 [HZRS16] architecture for MNIST and CIFAR-10, NasNet [ZVSL18] for CIFAR-100, and ResNeXt-50 [XGD+17] for ImageNet. The implementation uses the Pytorch [PGM+19] framework. Note that we convert greyscale MNIST images to be 3-channel RGB images in our experiments. Hyper-parameters are provided in Appendix E.
1 Accuracy Results of InstaHide
We evaluate the following InstaHide variants (with ):
Inside-dataset InstaHide with different ’s, where is chosen from .
Cross-dataset InstaHide with . For MNIST, we use CIFAR-10 as the public dataset; for CIFAR-10 and CIFAR-100, we use the preprocessed ImageNet as the public dataset. We do not test Cross-dataset InstaHide on ImageNet since its sample size is already large enough for good security.
The computation overhead of InstaHide in terms of extra training time in our experiments is smaller than .
Figure 3 shows the test accuracy of vanilla training, and inside-dataset InstaHide with different ’s on MNIST, CIFAR-10 and CIFAR-100 benchmarks. Compared with vanilla training, InstaHide with only suffers small accuracy loss of , , and respectively. Also, increasing from 1 (i.e., apply mask on original images, no Mixup) to 2 (i.e., apply mask on pairwise mixed images) improves the test accuracy for CIFAR datasets, suggesting that Mixup data augmentation also helps for encrypted InstaHide data points.
Inside-dataset v.s. Cross-dataset.
We also evaluate the performance of Cross-dataset InstaHide, which does encryption using random images from both the private dataset and a large public dataset. As shown in Table 2, Cross-dataset InstaHide incurs an additional small accuracy loss comparing with inside-dataset InstaHide. The total accuracy losses for MNIST, CIFAR-10 and CIFAR-100 are , , and respectively. As previously suggested, a large public dataset provides a stronger notion of security.
Inference with and without InstaHide.
As mentioned in Sec 3.3, by default, InstaHide is applied during inference. In our experiments, we average predictions of 10 encryptions of a test image. We found that for high-resolution images, applying InstaHide during inference is important: the results of using Inside-dataset InstaHide on ImageNet in Table 2 show that the accuracy of inference with InstaHide is , whereas that without InstaHide is only .
2 InstaHide vs. Differential Privacy approaches
Although InstaHide is qualitatively different from differential privacy in terms of privacy guarantee, we would like to provide hints for their relative accuracy (Question 2).
DPSGD [ACG+16] injects noise to gradients to control private leakage. Table 2 shows that DPSGD leads to an accuracy drop of about on CIFAR-10 dataset. By contrast, InstaHide gives models almost as good as vanilla training in terms of test accuracy.
Comparison with adding random noise to images.
As shown in Figure 4, by increasing from 0.1 to 0.9, the test accuracy of adding random noise drops from to , while the accuracy of InstaHide is above .
3 Robustness Against Attacks
To answer the question how well InstaHide can defend known attacks, here we report our findings with a sequence of attacks on InstaHide encryption to recover original image , including gradient-matching attack [ZLH19], demasking using GAN (Generative Adversarial Network), averaging multiple encryptions, and uncovering public images with similarity search.
Here attacker observes gradients of the loss generated using a user’s private image while training a deep net (attacker knows the deep net, e.g., as a participant in Federated Learning) and tries to recover by computing an image that has similar gradients to those of (see algorithm in Appendix E). Figure 5 shows results of this attack on Mixup and InstaHide schemes on CIFAR-10. If Mixup with is used, the attacker can still extract fair bit of information about the original image. However, if InstaHide is used the attack isn’t successful.
Demask using GAN.
InstaHide does pixel-wise random sign-flip after applying Mixup (with public images, in the most secure version). This flips the signs of half the pixels in the mixed image. An alternative way to think about it is that the adversary sees the intensity information (i.e. absolute value) but not the sign of the pixel. Attackers could use computer vision ideas to recover the sign. One attack consists of training a GAN on this sign-recovery taskWe thank Florian Tramèr for suggesting this attack., using a large training set of where is a mixed image and is a random mask. If this GAN recovers the signs reliably, this effectively removes the mask, after which one could use the attacks against Mixup described in Section 2.
In experiments this only succeeded in recovering half the flipped signs, which means of the coordinates continued to have the wrong sign; see Figure 6. GAN trainingWe use this GAN architecture (designed for image colorization): https://github.com/zeruniverse/neural-colorization. used 50,000 cross-dataset InstaHide examples generated with CIFAR-10 and ImageNet (). This level of sign recovery seems insufficient to allow the attack against Mixup (Section 2) to succeed, nor the other attacks discussed below. Nevertheless, researchers trying to break InstaHide may want to use such a demasking GAN as a starting point.
Average multiple encryptions of the same image.
We further test if different encryptions of the same image (after demasking) can be used to recover that hidden image by running the attack in Section 2.1.
Assuming a public history of encryptions, where is the size of the private training set, and is the number of epochs. We consider a stronger and a weaker version of this attack.
Stronger attack: the attacker already knows the set of multiple encryptions of the same image . He uses GAN to demask all encryptions in the set, and averages images in the demasked set to estimate .
Weaker attack: the attacker does not know which subset of the encryption history correspond to the same original image. To identify that subset, he firstly demasks all encrytions in the history using GAN. With an arbitrary demasked encryption (from the history) for some unknown original image , he runs similarity search to find top- closest images in other demasked encryptions (which may also contain ), and averages these images to estimate .
The stronger attack is conceivable if is very small (say a hospital only has 100 images), so via brute force the attacker can effectively have a small set of encryptions of the same image. However, in practice, is usually at least a few thousand.
For simplicity, we test with and (a larger will make the attack harder). We use the structural similarity index measure (SSIM) [WBSS04] as the similarity metric, and set to 5 after tuning.
We also run this attack directly on Mixup for comparison. As shown in Figure 7, if the original image is not flat (e.g. the “deer”), the stronger attack may not work. For flat images (e.g. the “truck”) or images with strong contrast (e.g. the “automobile” and the “frog”), the stronger attack is able to vaguely recover the original image. However, as previously suggested, the stronger attack is feasible only for a very small .
Note that results here is an upper bound on privacy leakage since we assume a perfect recovery of from the gradients. In real-life scenarios this may not hold.
Uncover public images by similarity search.
We also run the attack in Section 2.2 after demasking InstaHide encryptions using GAN, which tries to uncover the public images for mixing by running similarity search in the public dataset using the demasked encryption as the query.
We test with : mix 2 private images from CIFAR-10 with 4 public images from a set of 10,000 ImageNet images (i.e. ). We consider the attack a ‘hit’ if at least one public image for mixing is among the top- answers of the similarity search. The attacker uses SSIM as the default similarity metric for search. However, a traditional alignment-based similarity metric (e.g SSIM) would fail in InstaHide schemes which use randomly cropped patches of public images for mixing (see Figure 8), so in that case, the attacker trains a deep model (VGG [SZ15] in our experiments) to predict the similarity score.
Note that to find the 4 correct public images for mixing, the attack has to try all combinations of the top- answers with different coefficients, and subtract the combined image from the demasked InstaHide encryption to verify. Figure 8 reports the averaged hit rate of this attack on 50 different InstaHide images. As shown, even with a relatively small public dataset () and a large , the hit rate of this attack on InstaHide (enhanced with random cropping) is around 0.05 (i.e. the attacker still has to try combinations to succeed with probability 0.05). Also, this attack appears to become much more expensive with the public dataset being the whole ImageNet dataset () or random images on the Internet.
InstaHide Deployment: Best practice
Based on our security analysis (sec 4 and sec 5.3), we suggest the following:
Consider Inside-dataset InstaHide only if the private dataset is very large and images have varied, complex patterns. If the images in the private dataset have simple signal patterns or the dataset size is relatively small, consider using Cross-dataset InstaHide.
For Cross-dataset InstaHide, use a very large public dataset. Follow the preprocessing steps advocated in Sec 3.2 to randomly crop patches from each image in the public dataset and filter out “flat” patches.
Re-encrypt images in each epoch. This allows the benefits of greater data augmentation for deep learning and hinders attacks (as suggested in Sec 5.3).
Since images are re-encrypted in each epoch, for best security (e.g, against gradient-matching attacks), each participant should perform a random re-batching so that batch gradients do not correspond to the same subset of underlying images.
Choose for a good trade-off between accuracy and security.
Set a conservative upper threshold for the coefficients in mixing (e.g. in our experiments).
A Challenge Dataset
To encourage readers to design stronger attacks, we release a challenge dataset https://github.com/Hazelsuko07/InstaHide_Challenge. of encrypted images generated by applying Cross-dataset InstaHide with on some private image dataset and a preprocessed ImageNet as the public dataset. An attack is considered to succeed if it substantially recovers a significant fraction of original images.
Related Work
See Section 2. Mixup can improve both generalization and adversarial robustness [VLB+19]. It has also been adapted to various learning tasks, including semi-supervised data augmentation [BCG+19], unsupervised image synthesis [BHV+19], and adversarial defense at the inference stage [PXZ19]. Recently, [FWX+19] combined Mixup with model aggregation to defend against inversion attack, and [LWZ+19] proposed a novel method using Mixup for on-cloud privacy-preserving inference.
Differential privacy.
Differential privacy for deep learning involves controlling privacy leakage by adding noise to the learning pipeline. If the noise is drawn from certain distributions, say Gaussian or Laplace, it is possible to provide guarantees of privacy [DKM+06, DR14]. Applying differential privacy techniques to distributed deep learning is non-trivial. Shokri and Shmatikov [SS15] proposed a distributed learning scheme by directly adding noise to the shared gradients. However, the amount of privacy guaranteed drops with the number of training epochs and the size of shared parameters. DPSGD [ACG+16] was proposed to dynamically keep track of privacy spending based on the composition theorem [Dwo09]. However, it still leads to an accuracy drop of about on CIFAR-10 dataset. Also, to control privacy leakage, DPSGD has to start with a model pre-trained using nonprivate labeled data, and then carefully fine-tunes a few layers using private data.
Privacy using cryptographic protocols.
In distributed learning setting with multiple data participants, it is possible for the participants to jointly train a model over their private inputs by employing techniques like homomorphic encryption [Gen09, GLN12, LLH+17] or secure multi-party computation (MPC) [Yao82, Bei11, MZ17, DGL+19]. Recent work proposed to use cryptographic methods to secure federated learning by designing a secure gradients aggregation protocol [BIK+16] or encrypting gradients [AHWM17]. These approaches slow down the computation by orders of magnitude, and may also require special security environment setups.
Instance Hiding.
Discussions of Potential Attacks
We have received proposals of attacks since the release of early versions of this manuscript. We would like to thank these comments, which helped enhance the security of InstaHide. We hereby summarize some of them and explain why InstaHide in its current design is not vulnerable to them.
Florian Tramèr [Tra20] suggested an attack pipeline which 1) firstly uses GANs to undo the random one-time sign flips of encrypted images, and 2) then runs standard image-similarity search between the recovered image and images in the public dataset.
We have evaluated this attack scenario in Section 5.3 (see ‘Demask using GAN’ for the first step, and ‘Uncover public images by similarity search’ for the second step). As shown, the GAN demasking step corrects about 1/4 of the flipped signs (see Figure 6), however this doesn’t appear enough to allow further attacks (see Figure 8).
Several designs of InstaHide could provide better practice of privacy under this attack: 1) setting a conservative upper threshold for the coefficients in mixing (e.g. 0.65 in our experiments) makes it harder to train the demasking GAN. 2) To alleviate the threat of image-similarity search for public image retrieval, we use randomly cropped patches from public images. This could enlarge the search space of pubic images by some large constant factor. We also suggest using a very large public dataset (e.g. ImageNet) if possible.
Braverman’s attack.
Braverman’s attack can be seen as similar in spirit to the attack on vanilla Mixup in Section 2.2, with the difference that it needs images to behave like Gaussian vectors for higher moments, and not just inner products. In the empirical study, we find 1) the gaussianity assumption is not so good for real images 2) the shrinkage of candidate search space by Braverman’s attack is small for and almost disappears for .
To alleviate the risk of Bravermen’s attack, we reemphasize our suggestions in Section 6: 1) use a large public dataset and use random cropping as the preprocessing step. This will increase the original search space of public images; 2) use a larger (e.g. 6) if possible (3) maybe use a high quality GAN instead of the public dataset for mixing.
Carlini et al.’s attack.
Carlini et al. [CDG+20] gave an attack to recover private images in the most vulnerable application of InstaHide - when the InstaHide encryptions are revealed to the attacker. The first step is to train a neural network on a public dataset for similarity annotation to infer whether a pair of InstaHide encryptions contain the same private image. With the inferred similarities of all pairs of encryptions, the attacker then runs a combinatorial algorithm (cubic time in size of private dataset) to cluster all encryptions based on their original private images, and finally uses a regression algorithm to recover the private images.
Carlini et al.’s attack is able to give high-fidelity recoveries on our challenge dataset of 100 private images, but several limitations may prevent the current attack from working in a more realistic setting:
The current attack runs in time cubic in the dataset size, and it can’t directly attack an individual encryption. Running time was not an issue for attacking our challenge set, which consisted of 5,000 encrypted images derived from 100 images. But feasibility on larger datasets becomes challenging.
The challenge dataset corresponded to an ambitious form of security, where the encrypted images themselves are released to the world. The more typical application is a Federated Learning scenario where the attacker observes gradients computed using the inputs. When InstaHide is adopted in Federated Learning, the attacker only observes gradients computed on encrypted images. The attacks in this paper do not currently apply to that scenario. A possible attack to recover the original images may require recovering encrypted images from the gradients [ZLH19, GBDM20] as the first step.
Conclusion
InstaHide is a practical instance-hiding method for image data for private distributed deep learning.
InstaHide uses the Mixup method with a one-time secret key consisting of a pixel-wise random sign-flipping mask and samples from the same training dataset (Inside-dataset InstaHide) or a large public dataset (Cross-dataset InstaHide). The proposed method can be easily plugged into any existing distributed learning pipeline. It is very efficient and incurs minor reduction in accuracy. Maybe modifications of this idea can further alleviate the loss in accuracy that we observe, especially as increases.
We hope our analysis of InstaHide’s security on worst-case vectors will motivate further theoretical study, including for average-case settings and for adversarial robustness. In Appendix D, we suggest that although InstaHide can be formulated as a phase retrieval problem, classical techniques have failed as attacks.
We have tried statistical and computational attacks against InstaHide without success. To encourage other researchers to try new attacks, we release a challenge dataset of encrypted images.
Acknowledgments
This project is supported in part by Princeton University fellowship, Ma Huateng Foundation, Schmidt Foundation, Simons Foundation, NSF, DARPA/SRC, Google and Amazon AWS. Arora and Song were at the Institute for Advanced Study during this research.
We would like to thank Amir Abboud, Josh Alman, Boaz Barak, and Hongyi Zhang for helpful discussions, and Mark Braverman, Matthew Jagielski, Florian Tramèr, Nicholas Carlini and his team for suggesting attacks.
References
Appendix
The appendix is organized as follows: Appendix A reviews Instance hiding. Appendix B provides more details for two attacks on Mixup schemes in Section 2. Appendix C discusses -SUM, a well-known fine-grained complexity problem that is related to the worst-case security argument of InstaHide. Appendix D shows the connection between InstaHide and phase retrieval. Finally, Appendix E provides experimental details.
Appendix A Instance Hiding
In the classical setting of instance hiding [AFK87] in cryptography, a computationally-limited Alice is trying to get more powerful computing services Bob1 and Bob2 to help her compute a function on input , without revealing . The simplest case is that is a linear function over a finite field (e.g., integers modulo a prime number). Then Alice can pick a random number and “hide” the input by asking Bob1 for and Bob2 for , and then infer from the two answers. When all arithmetic is done modulo a prime, it can be shown that neither Bob1 nor Bob2 individually learns anything (information-theoretically speaking) about . This scheme can also be applied to compute polynomials instead of linear functions.
InstaHide is inspired by the special case where there is a single computational agent Bob1. Alice has to use random values such that she knows , and simply ask Bob1 to supply . Note that such a random value would be use-once (also called nonce in cryptography); it would not be reused when trying to evaluate a different input.
Appendix B Attacks on Mixup
Here we provide more details for the attacks discussed in Section 2.
B.1 Don’t mix up the same image multiple times
Let us continue with the vision task. This attack argues that given a pair of Mixup images and , by simply checking , the attacker can determine with high probability whether and are derived from the same image. We show this by a simple case with in Theorem B.1, where is the number of images used to generate a Mixup sample.
Part 1. First, we can expand ,
For each fixed and each fixed , using Lemma B.8, we have
where is some sufficiently large constant.
Since are independent random Gaussian vectors, taking a union bound over all pairs of and , we have Lemma B.8, we have
We can lower bound in the following sense,
For a fixed , we can lower bound with Lemma B.5,
Since are independent random Gaussian vectors, using Lemma B.8, we have
where is some sufficiently large constant.
holds with probability . ∎
With Theorem B.1, we have with probability , we have :
where the forth step follows from choice and , the fifth step follows from assumption in Lemma statement, and the last step follows from .
B.2 Attacks that run in |𝒳|𝒳|\mathcal{X}| time
This attack says that, if a cross-dataset Mixup sample is generated by mixing 1 sample from a privacy-sensitive original dataset and samples from a public dataset (say ImageNet [DDS+09]), then the attacker can crack the samples from the public dataset by simply checking the inner product between and all images in the public dataset. We show this formally in Theorem B.3.
We remark that the proof of Theorem B.3 is similar to the proof of Theorem B.1.
Part 1. We can rewrite as follows:
For each fixed and each fixed , using Lemma B.8, we have
where is some sufficiently large constant.
Since are independent random Gaussian vectors, taking a union over all , we have
Taking a union bound over all , we have
We can lower bound as follows:
First, we can bound with Lemma B.5,
For each , using Lemma B.8, we have
where is some sufficiently large constant.
Taking a union bound over all , we have
holds with probability .
Taking a union bound over all , we complete the proof. ∎
With Theorem B.3, we have with probability , we have : for all and ,
where the forth step follows from the choice of and , the fifth step follows from the assumption in the Lemma statement, and the last step follows from .
B.3 Chi-square concentration and Bernstein inequality
We state two well-known probability tools in this section.The major of idea of the provable results in this section is -th moment concentration inequality (see Lemma 3.1 in [CLS20] as an example). The inner product “attack” for Mixup is based on . The inner product “attack” for InstaHide is based on (suggested by [Bra20]). One is the concentration inequality for Chi-square and the other is Bernstein inequality.
First, we state a concentration inequality for Chi-square:
Let be a chi-squared distributed random variable with degrees of freedom. Each one has zero mean and variance. Then
We state the Bernstein inequality as follows:
Let be independent zero-mean random variables. Suppose that almost surely, for all . Then, for all ,
B.4 Inner product between a random Gaussian vector a fixed vector
The goal of this section is to prove Lemma B.7. It provides a high probability bound for the absolute value of inner product between one random Gaussian vector with a fixed vector.
Let denote i.i.d. random Gaussian variables where .
Next, we can upper bound and .
Take , then for each fixed , we have, holds with probability .
Taking a union bound over coordinates, with probability , we have : for all , .
Let denote the event that, is upper bounded by . .
Using Bernstein inequality (Lemma B.6), we have
Taking a union bound with event , we have . Finally, rescaling finishes the proof. ∎
B.5 Inner product between two random Gaussian vectors
The goal of this section is to prove Lemma B.8. It provides a high probability bound for the absolute value of inner product between two random (independent) Gaussian vectors.
Let denote i.i.d. random Gaussian variables where and denote i.i.d. random Gaussian variables where .
Then, for any failure probability , we have
First, using Lemma B.5, we compute the upper bound for
Take , then with probability ,
Second, we compute the upper bound for (the proof is similar to Lemma B.7)
We define and as follows
Therefore, rescaling completes the proof. ∎
Appendix C Computational hardness results of d𝑑d-dimensional k𝑘k-SUM
The basic components in InstaHide schemes are inspired by computationally hard problems derived from the classic SUBSET-SUM problem: given a set of integers, decide if there is a non-empty subset of integers whose integers sum to . It is a version of knapsack, one of the Karp’s 21 NP-complete problems [Kar72]. The -SUM [Eri95] is the parametrized version of the SUBSET-SUM. Given a set of integers, one wants to ask if there is a subset of integers sum to . The -SUM problem can be solved in time. For any integer and constant , whether -SUM can be solved in time has been a long-standing open problem. Patrascu [Pat10], Abboud and Lewi [AL13] conjectured that such algorithm doesn’t exist.
It is natural to extend definition from one-dimensional scalar/number case to the high-dimensional vector case. For -dimensional -sum over finite field, Bhattacharyya, Indyk, Woodruff and Xie [BIWX11] have shown that any algorithm that solves this problem has to take time unless Exponential Time Hypothesis is false. Here, Exponential Time Hypothesis is believed to be true, it states that there is no time to solve 3SAT with variables.
In this work, we observe that privacy of InstaHide can be interpreted as -dimensional -SUM problem and thus could be intractable and safe. For real field, -dimensional is equivalent to -dimensional due to [ALW14]. Therefore, Patrascu [Pat10], Abboud and Lewi [AL13]’s conjecture also suitable for -dimensional -SUM problem, and several hardness results in also can be applied to general directly.
We hereby provide a detailed explanation for the -dimensional -SUM problem. Let us start with the special case of and all values are integers.
Given a set of integers, if there is a subset of integers whose integers sum to .
SUBSET-SUM is a well-known NP-complete problem.
The -SUM is the parameterized version of the SUBSET-SUM,
Given a set of integers, if there is a subset of integers whose integers sum to .
The -SUM problem can be solved in time. For , Baran, Demaine and Patrascu [BDP08] introduced algorithm that takes time. It has been a longstanding open problem to solve -SUM for some in time . Therefore, complexity communities made the following conjecture,
There does not exist a , an , and a randomized algorithm that succeeds (with high probability) in solving -SUM in time .
Although the hardness for -SUM is not based on anything else at the moment, an lower bound under ETH is already known due to Abboud and Lewi [AL13]. Recently, Abboud [Abb19] also shows a weaker lower bound under the Set Cover Conjecture, but it has the advantage that it holds for any fixed .
C.2 k𝑘k Vector Sum over Finite Field
Now we move onto the -dimensional vector sum problem.
A more general definition that fits the InstaHide setting is called -VEC-T-SUM (where denotes the “target”),
-dimensional -VEC-T-SUM and -dimensional -VEC-SUM are considered to have the same hardness. Bhattacharyya, Indyk, Woodruff and Xie [BIWX11] proved hardness result for the problem defined in Definition C.4 and Definition C.5. Before stating the hardness result, we need to define several basic concepts in complexity. We introduce the definition of 3SAT and Exponential Time Hypothesis(ETH). For the details and background of 3SAT problem, we refer the readers to [AB09].
Given variables and clauses conjunctive normal form CNF formula with size of each clause at most , the goal is to decide whether there exits an assignment for the boolean variables to make the CNF formula be satisfied.
We state the definition of Exponential Time Hypotheis, which can be thought of as a stronger assumption than PNP.
There is a such that 3SAT problem defined in Definition C.6 cannot be solved in running time.
Now, we are ready to state the hardness result.
Assuming Exponential Time Hypothesis (ETH), any algorithm solves -VEC-SUM or -T-VEC-SUM requires time.
C.3 k𝑘k Vector Sum over Bounded Integers
For the bounded integer case, we can also define the -VEC-SUM problem,
For integers , , , , the -VEC-SUM problem is to determine, given vectors , if there is a size- subset such that .
Abboud, Lewi, and Williams proved that the 1-dimensional -VEC-SUM and -dimensional -VEC-SUM are equivalent in bounded integer setting,
Due to the above result, as long as we know a hardness result for classical -SUM, then it automatically implies a hardness result for -dimensional -VEC-SUM.
Appendix D Phase Retrieval
We primarily want to minimize (which is the number of measurements), the running time of (which is the decoding time) and column sparsity of .
D.2 Phase Retrieval
We primarily want to minimize (which is the number of measurements), the running time of (which is the decoding time) and column sparsity of .
The state-of-the-art result is due to [LN18].
The problem formulation of compressive sensing and phase retrieval have many variations, for more details we refer the readers to several surveys [Pri13, Has16, Nak19, Son19].
D.3 Comments on Phase Retrieval
We would like to point out that although InstaHide can be formulated as a phase retrieval problem, classical techniques will fail as an attack.
To show the phase retrieval formulation of InstaHide, we first argue applying the random pixel-wise sign is equivalent to taking the absolute value, namely (A): is equivalent to (B): , where denote the mixing function. This is because, to reduce from B to A, we can just take absolute value in each coordinate; and to reduce from A to B, we can just select a random mask (i.e., ) and apply it.
Appendix E Experiments
Table 3 provides Implementation details of the deep models. All experiments are conducted on 24 NVIDIA RTX 2080 Ti GPUs.
E.2 Details of attacks
We hereby provide more details for the attacks in Section 5.3.
Algorithm 3 describes the gradients matching attack [ZLH19]. This attack aims to recover the original image from model gradients computed on it. In the InstaHide setting, the goal becomes to recover , the image after InstaHside. As we have shown in Section 4, the upper bound on the privacy loss in gradients matching attack is the loss when attacker is given .
E.3 Results of the Kolmogorov–Smirnov Test
In order to further understand whether there is significant difference among distributions of InstaHide encryptions of different ’, we run the Kolmogorov-Smirnov (KS) test [Kol33, Smi48].
Specifically, we randomly pick 10 different private ’s, , and generate 400 encryptions for each (4,000 in total). We sample , the encryption of a given , and run KS-test under two different settings:
v.s. all encryptions (All): KS-test(statistics of , statistics of all ’s for )
v.s. encryptions of other ’s, (Other): KS-test(statistics of , statistics of all ’s for )
For each , we run the Kolmogorov–Smirnov test for 50 independent ’s, and report the averaged p-value as below (a higher p-value indicates a higher probability that comes from the tested distribution). We test 7 different statistics: pixel-wise mean, pixel-wise standard deviation, total variation, and the pixel values of 4 random locations. KS-test results suggest that, there is no significant differences among distribution of encryptions of different images.