(Also see A few notes on technology, WikiLeaks, data mining, and privacy)
WikiLeaks recently published a mysterious 1.4GB file entitled “insurance.aes256″ on their Afghan War Logs page, with no explanation. While much speculation has been going on as to the origins and purpose of the file, I have not been able to find any evidence for any of these theories. Many sources are saying that it is an encrypted file. Some are saying that the file could be garbage or some kind of hoax. Others are saying that it is ‘insurance’ against WikiLeaks being taken down by the United States government.
You can download the insurance.aes256 file yourself using a BitTorrent client via this magnet link. If you don’t have a BitTorrent client, or can’t/don’t want to install one, you can use this BitLet link (requires Java.)
Because of the file’s name, many media sources such as Wired that are picking up this story are saying that the file is encrypted with the AES256 algorithm. This may not be true, as Wikileaks has not said anything about the file itself. Even if it really is an encrypted file, there would be no way to tell if it really is AES256 or some other algorithm.
Most good encryption algorithms produce output that is statistically random, meaning that the output of the encryption algorithm is indistinguishable from true random number sources (such as white noise, quantum effects, or nuclear radiation). This also means that output from one encryption algorithm is indistinguishable from another algorithm.
What this means for WikiLeaks is that the file could be just random numbers designed to fool everyone into thinking that it is something big, or it could be encrypted with a different algorithm than the file says (plausible deniability.)
The AES algorithm is used by some United States military intelligence systems. It is believed by some that AES has a secret backdoor put in place by the NSA. See this, this, this, and especially this, for starters! Several attacks have been discovered in the past on AES, such as the related-key and XSL attacks, that lower the number of operations it would require to brute-force an encrypted piece of information. If the NSA really does have a backdoor, and the file is what everyone is saying it is, someone in the government with sufficient security clearance may already know what is in the file without even having the encryption key. But enough with speculation, let’s move on to the analysis…
Using a small program written by John Walker, I ran a simple probability analysis to see if there were any statistical anomalies in the file. I wanted to see whether or not the file was statistically random. This might give us clues about the file.
The chart below shows the probability of each 8-bit byte, and some general statistics at the end.
Click here to open the Probability Analysis chart»
According to the results, the file is almost completely random. There is a very tiny bias towards 0 bits showing up more than 1 bits, but this is insignificant. Again, it could just be 1.4GB of random garbage designed as disinformation intended to throw us off, or it could be some big secrets that WikiLeaks is blackmailing the government with.
I’m working on getting some N-gram charts and maybe some more autocorrelation data on this file eventually. If anyone has any information, feel free to leave a comment in the section below.
EDIT: openssl enc -d -aes256 -in insurance.aes256 > output.bin
Value Char Occurrences Fraction
0 5831133 0.003909
1 5821896 0.003903
2 5829493 0.003908
3 5825654 0.003905
4 5826771 0.003906
5 5828268 0.003907
6 5824812 0.003904
7 5825516 0.003905
8 5829742 0.003908
9 5827343 0.003906
10 5832027 0.003909
11 5829195 0.003907
12 5827384 0.003906
13 5828728 0.003907
14 5830264 0.003908
15 5827702 0.003906
16 5826254 0.003905
17 5826796 0.003906
18 5827655 0.003906
19 5829898 0.003908
20 5823791 0.003904
21 5826721 0.003906
22 5830325 0.003908
23 5827184 0.003906
24 5827418 0.003906
25 5826649 0.003906
26 5829073 0.003907
27 5830903 0.003909
28 5829320 0.003907
29 5822054 0.003903
30 5830935 0.003909
31 5825495 0.003905
32 5826277 0.003905
33 ! 5825157 0.003905
34 " 5828451 0.003907
35 # 5832609 0.003910
36 $ 5826940 0.003906
37 % 5824398 0.003904
38 & 5832584 0.003910
39 ' 5827261 0.003906
40 ( 5829910 0.003908
41 ) 5824543 0.003904
42 * 5826074 0.003905
43 + 5830256 0.003908
44 , 5829193 0.003907
45 - 5824406 0.003904
46 . 5826575 0.003906
47 / 5829038 0.003907
48 0 5821723 0.003902
49 1 5825675 0.003905
50 2 5828370 0.003907
51 3 5825673 0.003905
52 4 5829694 0.003908
53 5 5829471 0.003908
54 6 5827969 0.003907
55 7 5827824 0.003906
56 8 5830805 0.003908
57 9 5823738 0.003904
58 : 5831109 0.003909
59 ; 5829838 0.003908
60 < 5829588 0.003908
61 = 5831567 0.003909
62 > 5828582 0.003907
63 ? 5827448 0.003906
64 @ 5825238 0.003905
65 A 5828482 0.003907
66 B 5830997 0.003909
67 C 5825871 0.003905
68 D 5824193 0.003904
69 E 5826975 0.003906
70 F 5828318 0.003907
71 G 5823672 0.003904
72 H 5826967 0.003906
73 I 5831510 0.003909
74 J 5824043 0.003904
75 K 5825664 0.003905
76 L 5825418 0.003905
77 M 5825536 0.003905
78 N 5830349 0.003908
79 O 5831757 0.003909
80 P 5831266 0.003909
81 Q 5826086 0.003905
82 R 5828675 0.003907
83 S 5825970 0.003905
84 T 5829911 0.003908
85 U 5825395 0.003905
86 V 5829711 0.003908
87 W 5831360 0.003909
88 X 5824735 0.003904
89 Y 5825407 0.003905
90 Z 5829758 0.003908
91 [ 5819914 0.003901
92 \ 5823519 0.003904
93 ] 5826185 0.003905
94 ^ 5828524 0.003907
95 _ 5832354 0.003910
96 ` 5825820 0.003905
97 a 5828110 0.003907
98 b 5826906 0.003906
99 c 5824343 0.003904
100 d 5822172 0.003903
101 e 5827340 0.003906
102 f 5827127 0.003906
103 g 5825124 0.003905
104 h 5832981 0.003910
105 i 5826975 0.003906
106 j 5825581 0.003905
107 k 5825491 0.003905
108 l 5825104 0.003905
109 m 5826918 0.003906
110 n 5823465 0.003904
111 o 5828650 0.003907
112 p 5828446 0.003907
113 q 5829390 0.003908
114 r 5827485 0.003906
115 s 5823606 0.003904
116 t 5828506 0.003907
117 u 5826148 0.003905
118 v 5826219 0.003905
119 w 5828943 0.003907
120 x 5829263 0.003907
121 y 5826001 0.003905
122 z 5829743 0.003908
123 { 5829260 0.003907
124 | 5822397 0.003903
125 } 5828862 0.003907
126 ~ 5823484 0.003904
127 5823496 0.003904
128 5826185 0.003905
129 5829053 0.003907
130 5824485 0.003904
131 5827967 0.003907
132 5826922 0.003906
133 5826153 0.003905
134 5828158 0.003907
135 5827341 0.003906
136 5828230 0.003907
137 5826507 0.003906
138 5829568 0.003908
139 5828237 0.003907
140 5826541 0.003906
141 5827883 0.003907
142 5827333 0.003906
143 5826359 0.003905
144 5829751 0.003908
145 5829125 0.003907
146 5825086 0.003905
147 5826675 0.003906
148 5823525 0.003904
149 5832068 0.003909
150 5825977 0.003905
151 5829231 0.003907
152 5828683 0.003907
153 5830115 0.003908
154 5830568 0.003908
155 5829353 0.003908
156 5829319 0.003907
157 5823290 0.003903
158 5826116 0.003905
159 5826230 0.003905
160 5823560 0.003904
161 Ã 5827576 0.003906
162 ó 5827266 0.003906
163 ú 5831967 0.003909
164 ñ 5827865 0.003907
165 Ñ 5827662 0.003906
166 ª 5823918 0.003904
167 º 5823846 0.003904
168 ¿ 5829778 0.003908
169 ? 5824655 0.003904
170 ¬ 5828859 0.003907
171 ½ 5829188 0.003907
172 ¼ 5824222 0.003904
173 ¡ 5829270 0.003907
174 « 5823372 0.003903
175 » 5824438 0.003904
176 ? 5827143 0.003906
177 ? 5824586 0.003904
178 ? 5831909 0.003909
179 ? 5827259 0.003906
180 ? 5830235 0.003908
181 ? 5831856 0.003909
182 ? 5828774 0.003907
183 ? 5830828 0.003908
184 ? 5829501 0.003908
185 ? 5827530 0.003906
186 ? 5825374 0.003905
187 ? 5827948 0.003907
188 ? 5827309 0.003906
189 ? 5823734 0.003904
190 ? 5832416 0.003910
191 ? 5832396 0.003910
192 ? 5827631 0.003906
193 ? 5826624 0.003906
194 ? 5828155 0.003907
195 ? 5825351 0.003905
196 ? 5828894 0.003907
197 ? 5833022 0.003910
198 ? 5827565 0.003906
199 ? 5825051 0.003905
200 ? 5825892 0.003905
201 ? 5827507 0.003906
202 ? 5826458 0.003906
203 ? 5825486 0.003905
204 ? 5828733 0.003907
205 ? 5828540 0.003907
206 ? 5830445 0.003908
207 ? 5825805 0.003905
208 ? 5825267 0.003905
209 ? 5823457 0.003904
210 ? 5830062 0.003908
211 ? 5822106 0.003903
212 ? 5832123 0.003909
213 ? 5828281 0.003907
214 ? 5826942 0.003906
215 ? 5826355 0.003905
216 ? 5829180 0.003907
217 ? 5828365 0.003907
218 ? 5829759 0.003908
219 ? 5826086 0.003905
220 ? 5830598 0.003908
221 ? 5831230 0.003909
222 ? 5828050 0.003907
223 ? 5823466 0.003904
224 ? 5828778 0.003907
225 ß 5829330 0.003907
226 ? 5830131 0.003908
227 ? 5826472 0.003906
228 ? 5828401 0.003907
229 ? 5826891 0.003906
230 µ 5827650 0.003906
231 ? 5825816 0.003905
232 ? 5829096 0.003907
233 ? 5827508 0.003906
234 ? 5831141 0.003909
235 ? 5824228 0.003904
236 ? 5827457 0.003906
237 ? 5822154 0.003903
238 ? 5827440 0.003906
239 ? 5821770 0.003902
240 ? 5826786 0.003906
241 ± 5830915 0.003909
242 ? 5829086 0.003907
243 ? 5822656 0.003903
244 ? 5828582 0.003907
245 ? 5829998 0.003908
246 ÷ 5827474 0.003906
247 ? 5826453 0.003906
248 ° 5828926 0.003907
249 ? 5824695 0.003904
250 · 5827524 0.003906
251 ? 5827312 0.003906
252 ? 5829973 0.003908
253 ² 5826288 0.003905
254 ? 5827450 0.003906
255 Â 5829174 0.003907
Total: 1491834576 1.000000
Entropy = 8.000000 bits per byte.
Optimum compression would reduce the size
of this 1491834576 byte file by 0 percent.
Chi square distribution for 1491834576 samples is 285.70, and randomly
would exceed this value 9.05 percent of the times.
Arithmetic mean value of data bytes is 127.4998 (127.5 = random).
Monte Carlo value for Pi is 3.141583671 (error 0.00 percent).
Serial correlation coefficient is -0.000029 (totally uncorrelated = 0.0).
July 31st, 2010 | 
Written by 
Category: Uncategorized |
Let’s say we know the password. What program would we use to decrypt the file?
That is not actually known, because it is impossible to determine the real encryption algorithm used from the data, but a clue exists: the “Salted__” prefix found in the first bytes of the file indicates that OpenSSL was used to encrypt the file.
At a shell you would probably go with something like:
openssl enc -d -aes256 -in insurance.aes256 > output.bin
It’s possible that the “Salted__” tag was planted there, as well.
If insurance.aes256 is real, then inside would probably be an archive or mountable filesystem containing many smaller files.
Anyone already find a password or know how to open that file?
If anyone has, I haven’t heard about it…
As for opening it, see the above comment about openssl… it’s the most likely program used to create the file.
I was talking with wikileaks staff and they said, the insurance.aes256 file can’t be open by any PC because *.aes256 is use by US Military goverment. They said the key and decoder program will be revelated “if something unforeseen happens”. Thats mind they have a key but they can never revelate the key to open a file. They won’t say anything else about *.aes256 file. Very strange….
You must be mistaken… a PC can decrypt AES as long as the key is known. It doesn’t matter whether the US military uses the AES standard or not. In fact, the AES standard is open and plenty of implementations exist. Many processors even have special AES opcodes to boost the speed of such implementations – see here.
The question is, is the insurance.aes256 file noise, or is it actual data? If it’s actual data, is it really encrypted with AES? There is no way to determine the answer to either of these questions.
Due to the nearly perfect randomness of the data, it’s probably an OTP for other files not yet published?
I forgot to mention that… thanks for pointing it out. It’s possible, but it’s also plausible that it’s encrypted data due to the indistinguishability between encrypted data and noise.
In a classic OTP scheme, the key needs to be exactly as large as the plaintext in order for it to be secure. This could explain the massive filesize, but then again it could just be a lot of encrypted documents as well – there isn’t a way to tell.
If it really is a one-time password for something else, then the “Salted__” prefix would almost certainly have to have been planted, indicating some kind of deception as to the encryption method.
btw, i am not the guy on the pic. sorry man.
RT @minousoft: Probability analysis of the insurance.aes256 file posted by WikiLeaks #conspiracy #encryption http://bit.ly/e4CZ9M
http://www.minousoft.com/2010/07/probability-analysis-of-the-insurance-aes256-file-posted-by-wikileaks/ … BTW
the US are saying they don't know the contents of wikileaks documents but the NSA must be able to crack AES256 http://bit.ly/aXXAKz
Probability analysis of the insurance.aes256 file posted by WikiLeaks #conspiracy #encryption http://bit.ly/e4CZ9M
I think it really is an insurance for wikileaks. I think it contains some highly confidential data, that would be released only if the US gov tries to shut down wikipedia, or do something against Julien Assange (it’s founder)
The US government is going to shut down Wikipedia?
RT @minousoft: Probability analysis of the insurance.aes256 file posted by WikiLeaks #conspiracy #encryption http://bit.ly/e4CZ9M
Probability analysis of the insurance.aes256 file posted by WikiLeaks #conspiracy #encryption http://bit.ly/e4CZ9M
It’s possible this file is a friar offering indulgences for the sin of beakwith bankson. What kind of Hail Mary can we chant when it gets revealed? The sackcloth of the friar’s habit is probably an irritant to the skin, but a layer of goosefat rubbed gently over the inner Hessian should help to alleviate his suffering, even if he neither knows nor cares for Beeny, and will laugh there nevermore.
…what?
I don’t think Wikileaks is even remotely related to whatever you’re talking about…
#Wikileaks'in insurance.aes256 dosyas?n?n teknik incelemesi: http://bit.ly/aXXAKz "Rastgele olu?turulmu? içeriksiz dosya olabilir" diyorlar.
one argument against waisted 1,4GB of random signs is the technique of steganography. I had something to do with dataencryption and by restriction of computing power to use long keys it was a good idea to put certain bytes into (netto) datastrings to make (brutto) strings randomized.
Then encrypt datas. The best protection is to led enemies think there is no worthful thing, otherwise the to be protected thing could be too easily completly destroyed:= lost of that information.
And, if important and may be dangerous information has to be protected, there is no act by wich one has to offer all details of decryption. So, tell without heardache that encryption method is AES or RSA or so. But there is no reason to explain internal data structures /patterns / odd insertions before its nessesary.
Randomizing has’nt to be done only by (modern mathematical) encryption algorhythm. Hold in mind: semantic changes are a completly other way as preparation – look at voinych manuscript for example, semantic changings are the only ‘encryption’ added by use of ligatures (one sign for a certain combination of letters – generally used in the 19th centuary).
If you encrypt a rather large file in i.e. WinRAR with a password and analyze it you’ll see that every hex value is present for about 0.39% with small variations. There is no difference with this insurance file. Test yourself with HxD (freeware Hex editor/analyzer).
That’s because the purpose of compression is orthogonal to the purpose of encryption: The goal of both is to end up with high entropy information. However, compression is designed to find the lowest filesize, while encryption is designed to prevent recovery of the original plaintext.
Also, HxD doesn’t do autocorrelation tests.
openssl enc -d -aes256 -in insurance.aes256 > output.bin – #Wikileaks Insurance file analyzed. Salted__ #CableGate || http://bit.ly/dYb8jO
router
onion
passwords that give no errors
Probability analysis of the insurance.aes256 file posted by WikiLeaks http://t.co/3sKm026
http://bit.ly/aXXAKz weird'o
interesgarria, insurance.aes256 fitxategiari buruz http://bit.ly/i2XDmB
Has anyone considered that it could be both simultaneously random data AND useless junk? This could be a 1.4gb 1TP XOR seed.
Pretend like i said “useful data” and “random junk”.
LOL…
I’m pretty sure you meant “OTP” instead of “1TP.”
Commenter “Nobody” above mentioned the possibility of insurance.aes256 being part of an OTP scheme.
AES? –> Intel, the processors of Intel works with AES..
Ok so far this works …
AES PASSWORD == ONION
$ openssl enc -d -aes256 -in insurance.aes256 > outONIONAES.dec
BF PASSWORD == ROUTER
$ openssl enc -d -bf -in insurance.aes256 > outROUTERBF.dec
BF PASSWORD == ONION
$ openssl enc -d -bf -in insurance.aes256 > outONIONBF.dec
@000001110001110 http://www.minousoft.com/2010/07/probability-analysis-of-the-insurance-aes256-file-posted-by-wikileaks/