Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

CryptoJS error.

Mobile Safari in iOS 6.1.3 produces Error: Malformed UTF-8 data

Problem with the following combination:

JavaScript aes.js

iOS 6.1.3

an aes encrypted file 3MB in size or larger.



Since iOS 6.1.3 Mobile Safari regularly fails to decrypt files of significant size (3MB+) when running on just the iOS device itself.

File sizes < 300KB decrypt with no issues.


Here's the kicker:

If I connect the the iOS device and show web inspector for the iOS device, it successfully decrypts every single time.


There is a listed patch at Google:

https://code.google.com/p/crypto-js/issues/detail?id=80


However, it does not resolve this problem. I recompiled with closure-compiler all the way back to white space only and pretty print and the problem persists.


Chrome successfully decrypts the same files Mobile Safari fails on.


Any ideas?

Posted on May 7, 2013 4:45 PM

Reply
12 replies

May 7, 2013 5:52 PM in response to naf-101

naf-101 wrote:


Any ideas?

Don't download 3 MB files in Javascript on an iPhone?


Really, if you look hard enough you are going to find bugs in anything. You can always report said bugs, but I don't know why Apple, or anyone, for that matter, would even care. There was a day when 70% of the world's browsers couldn't parse standard HTML. And that was OK. Now, a cell phone can't properly decrypt a 3 MB file in Javascript and that's a problem. Sorry. I don't get it.

May 7, 2013 10:02 PM in response to etresoft

Thanks for the link etresoft.


I guess the take home point for me is the software works flawlessly using a Google product on an Apple device, but the Apple product doesn't. I hate having to write an FAQ telling my clients to NOT use Apple software on an Apple product. I'm a bit of a fanboi I'm afraid, and it just feels rude. (The software worked fine until clients updated to iOS 6.1.3)


Hopefully someone has found a cause/work-around for what appears to be a JavaScript engine parsing error in Mobile Safari that is only present when not connected to the debugging console. With luck they can shed some light on the actual issue so folks like me can fix the problem and keep our clients happy using Apple software on Apple devices.

May 8, 2013 6:29 AM in response to naf-101

Well, there is another option - don't download 3 MB AES encrypted files on a cell phone and decrypt them with Javascript. I mean, really? Come on! My first thought is not that this is an obscure bug but yet another post by a paid anti-Apple shill. Sure, it's neat trick. But I have a hard time believing anyone would be foolish enough to attempt to sell something like this to "clients". It's a phone. It's an interpreted scripting language. This is not what Javascript is for.

May 8, 2013 7:36 AM in response to naf-101

Summary:

Since iOS 6.1.3 Mobile Safari regularly fails to decrypt files of significant size (400KB+) when running on just the iOS device itself. The issue did not appear to be present in mobile Safari in the previous version of iOS.


If the iOS device is connected to a Mac and web inspector is open for the iOS device's web page, it successfully decrypts the file every single time.



Steps to Reproduce:

Use Javascript aes.js

In Mobile Safari with iOS 6.1.3 (iPhone 5 and iPad 2 tested) attempt to decrypt aes encrypted file 400 KB in size or larger.



Expected Results:

unencrypted string.



Actual Results:

Error is thrown when command .toString(CryptoJS.enc.Utf8) is executed. Error message is: Malformed UTF-8 data


Notes:

Files 40K or less decrypt 100% reliably.

When connected to debug console, decrypting files up to 1MB with mobile Safari is 100% reliable.

When disconnected from debug console, decrypting files 400KB and larger in mobile Safari fails 100% of the time.

Decryption of files up to 1 MB works flawlessly using Google Chrome on iPhone 5 and iPad 2 hardware.

Issue is not present in Safari 6.0.4, Chrome Version 26.0.1410.65, Firefox 20.0, Internet Explorer 7, 8, 9, and 10, default browsers on Android devices (phones, Kindle Fire etc.), and Windows 8 mobile.

May 8, 2013 8:59 AM in response to naf-101

If a large file is correctly decrypted (while mobile Safari is connected to debugger) and the encrypted file is written to local, mobile safari can read and decrypt variable from localStorage.


mobile Safari using aes.js will successfully encrypt and decrypt 1MB files if file is read from and written to localStorage.


Writing web content to localStorage before decrypting from localStorage variable does not resolve the issue. Byte count of file to be decrypted is identical when iOS device is stand alone or has a developers console open. Both before and after writing to localStorage.

May 8, 2013 11:41 AM in response to etresoft

Community etiquette

Apple Support Communities exists to enable community members to help each other get the most out of their Apple products and services. To keep this community useful to everyone, follow these guidelines:

  • Post only technical support questions and answers, unless otherwise noted.
  • Be polite, constructive and stay on topic.
  • Search for questions similar to your own before submitting a new question to the community.
  • Reward helpful community members by marking answers to your questions as helpful and correct.
  • Avoid speculation and rumors.

For full details, see the Apple Support Communities Terms of Use.

May 8, 2013 12:27 PM in response to naf-101

OK. What do you want me to do then? Post a link to Apple's bug reporter? Suggest another, better way to decrypt files on an iPhone? I can, and have, done all of that.


Yet you keep posting the same description of the same obscure Javascript bug. You are the one using boldface to ramp up the anti-Apple rant-o-meter. How did you think I would respond to that? How would people at code.google.com respond to me if I went over there complaining about Chrome?


While Apple uses a lot of open source software, it is not an open source company like Google is. There is not going to be another build of Mobile Safari next week that fixes this bug. If you find a bug in a vendor library, you just have to work around it. If you want to transfer encrypted files, use an encrypted protocol. If you don't want to do that, write your own app. If a system library isn't working, file a bug report. If you do file a bug report, make sure to follow Apple bug reporting best practices, which specficially ask for:


Steps to Reproduce:

Describe the step-by-step process to reproduce the bug, including any non-default preferences/installation and the system configuration information. Note: It is better to include too much information than not enough, as this minimizes the amount of back-and-forth communications. Be very specific and be sure to provide details, opposed to high-level actions.

May 8, 2013 2:27 PM in response to etresoft

The bug report link was helpful etresoft. A bug report has been filed.


You do not seem to have any other light to shed on this topic other than what you have shared to date. You do not seem to have any interested in digging into this issue. I respect that. You're suggestions have been duly noted. (In point on fact: I am currently digging into a rather critical and obscure edge case bug regarding chrome. They view this as an opportunity to make the product better, not a threat to their brand or an attempt to sully their company name.)


I am providing additional information here for other developers who may have insight or wish to participate in finding a cause to an edge case problem like this one. The end goal being to keep another amazing product running in Apple's entire and awesome ecosystem.


If there is no interest, then I don't expect I'll see any posts.


Thank you again for the bug report link.

May 9, 2013 10:32 AM in response to naf-101

While writing a hunk of sample code to demonstrate the issue, I found a work around (a bit clumsy, but it works).

The concise issue:

Using CryptoJS JavaScript as encryption library.

If mobile Safari in iOS 6.1.3 downloads an AES encrypted file of more than roughly 200KB-300KB, the decryption fails 100% of the time.

(Decryption is 100% successful if using a locally stored AES encrypted files, or if the iOS device is connected to the Web Inspector for debugging.)


The work-around:

download aes file.

Attempt to decrypt.

On failure to decrypt:

repeat above until successful.


Just re-sending the original downloaded file back for decryption does not work. The file must be re-downloaded.


This has proven 100% successful on iPhone 4, iPhone 5, iPad 2, The New iPad.

Will test on iPhone 4S as soon as I upgrade to 6.1.3.


Once mobile Safari has successfully decrypted a file of this size, all following files will decrypt first time through.


My iPad 2 requires 2 downloads, the second successfully decrypting.

My iPhone 5 requires 3 downloads, the third successfully decrypting.


sample code below:


<!DOCTYPE html>

<html>

<head>

<title>CryptoJS Large File Workaround</title>

<meta name="viewport"content="initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

<meta charset="UTF-8">

<meta name="apple-mobile-web-app-capable"content="yes" />

<meta name="apple-touch-fullscreen"content="yes" />

<script type="text/javascript"src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>

<script type="text/javascript"src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.9.1/jquery-ui.min.js"></script>

<script type="text/javascript"src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/aes.js"></script>

</head>

<body style="margin:0px; padding:0px;"link="black">

<div id="data">Loading

<br>

</div>

<div></div>

<script>

function parseData(response) {

var offset;

var dec;

var data = null;


dec = CryptoJS.AES.decrypt(response, "Not a really super secret password.");


try {

data = dec.toString(CryptoJS.enc.Utf8);

$("div").append(data);

alert("Successful decryption of file. " + data.length + " bytes long.");

} catch (err) {

alert("Failure in toString(CryptoJS.enc.Utf8): " + err.message);

}


return data;

}


function loadInitDoc(baseUrl, fName, async) {

var result = null;

jQuery.ajax({

url: baseUrl + fName,

method: 'GET',

dataType: 'text',

cache: false,

async: async

}).done(function (response) {

result = parseData(response);

});

return result;

}


function tryData() {

var decData = null;

var baseUrl = "http://www.mydomain.com/";

var eName = "sampleenc.txt";

while (decData === null) {

alert("Click OK to try getting " + baseUrl + eName);

decData = loadInitDoc(baseUrl, eName, false);

}

}

tryData();

</script>

</body>


</html>

Jun 25, 2014 5:56 AM in response to etresoft

Absolutely appalled by the attitude shown by etresoft.


For what it is worth, I am experiencing this issue periodically for much smaller amounts of data.


Additionally the problem occurs on iPad as well as iPhone, so not just a "cell phone".


There are 6 people currently following the issue on cryptojs: https://code.google.com/p/crypto-js/issues/detail?id=80


Chrome on iOS6 works.

Safari on iOS7 works.

Perfectly reasonable to enquire if anyone has any ideas as to how it could be worked around or fixed in iOS6.


As the problem only occurs in an Apple product, it is perfectly reasonable to enquire on Apple developer forums.


I personally believe the original poster is entitled to request help without this kind of response. It is not like he said was critical of Apple in any way, in fact he has been the complete opposite.


If anyone else has any suggestions then please do reply, as I do care.

CryptoJS error.

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.