Comments for Cocoaphony http://robnapier.net/blog Mac and iPhone, on the brain Thu, 02 Feb 2012 16:51:07 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Comment on Properly encrypting with AES with CommonCrypto by Rob Napier http://robnapier.net/blog/aes-commoncrypto-564/comment-page-1#comment-15188 Rob Napier Thu, 02 Feb 2012 16:51:07 +0000 http://robnapier.net/blog/?p=564#comment-15188 <p>The salt and IV that are generated during encryption should be stored with the ciphertext and sent to the decryptor (you will notice that these are returned by reference). The decryptor then uses the same salt and IV.</p> The salt and IV that are generated during encryption should be stored with the ciphertext and sent to the decryptor (you will notice that these are returned by reference). The decryptor then uses the same salt and IV.

]]> Comment on Properly encrypting with AES with CommonCrypto by Ranjit http://robnapier.net/blog/aes-commoncrypto-564/comment-page-1#comment-15186 Ranjit Thu, 02 Feb 2012 14:02:26 +0000 http://robnapier.net/blog/?p=564#comment-15186 <p>Hey rob,your article is very informative , and I am using your code,but I have a doubt, according to your code snippet above, you said to pass the IV and salt while encryption, but in the function encrypteddatafordata ,it uses random salt and IV.so if it uses random generator to produce salt and IV ,then how it can be decrypted on server side,also what salt and IV should be,( a number or string)..waiting for your reply</p> Hey rob,your article is very informative , and I am using your code,but I have a doubt, according to your code snippet above, you said to pass the IV and salt while encryption, but in the function encrypteddatafordata ,it uses random salt and IV.so if it uses random generator to produce salt and IV ,then how it can be decrypted on server side,also what salt and IV should be,( a number or string)..waiting for your reply

]]> Comment on Drop-in offline caching for UIWebView (and NSURLProtocol) by Seth Pollack http://robnapier.net/blog/offline-uiwebview-nsurlprotocol-588/comment-page-1#comment-15154 Seth Pollack Mon, 30 Jan 2012 21:45:00 +0000 http://robnapier.net/blog/?p=588#comment-15154 <p>Thanks for sharing this!</p> <p>For my app, I have some resources in group A that i want to always cache, for which this works great; and other resources in group B i'd like to cache as space allows, but not without bound, and don't want to let the growth of the group B cache force a purge of group A. I may end up writing those two groups of resources to two different storage locations, one that is non-purgable, one that is purgable.</p> <p>Anyhow, if anyone ends up merging this concept of Rob's with one of the LRU/size managed persistent cache implementations out there, such as steipete's SDURLCache fork, AFCache, or one of the others, please post a link here. Thanks!</p> Thanks for sharing this!

For my app, I have some resources in group A that i want to always cache, for which this works great; and other resources in group B i’d like to cache as space allows, but not without bound, and don’t want to let the growth of the group B cache force a purge of group A. I may end up writing those two groups of resources to two different storage locations, one that is non-purgable, one that is purgable.

Anyhow, if anyone ends up merging this concept of Rob’s with one of the LRU/size managed persistent cache implementations out there, such as steipete’s SDURLCache fork, AFCache, or one of the others, please post a link here. Thanks!

]]> Comment on Drop-in offline caching for UIWebView (and NSURLProtocol) by Rob Napier http://robnapier.net/blog/offline-uiwebview-nsurlprotocol-588/comment-page-1#comment-15147 Rob Napier Sun, 29 Jan 2012 23:53:30 +0000 http://robnapier.net/blog/?p=588#comment-15147 <p>This is an excellent point. It shouldn't come up very often in the kinds of uses I am discussing here (since my goal is offline access to smallish things), but it is a general issue with streaming media. I'm surprised about SVG, though; I didn't know about that. Why is that a problem?</p> This is an excellent point. It shouldn’t come up very often in the kinds of uses I am discussing here (since my goal is offline access to smallish things), but it is a general issue with streaming media. I’m surprised about SVG, though; I didn’t know about that. Why is that a problem?

]]> Comment on Drop-in offline caching for UIWebView (and NSURLProtocol) by Rob Napier http://robnapier.net/blog/offline-uiwebview-nsurlprotocol-588/comment-page-1#comment-15146 Rob Napier Sun, 29 Jan 2012 23:50:23 +0000 http://robnapier.net/blog/?p=588#comment-15146 <p>Absolutely. I haven't generally put formal licenses on my example code, but it should be considered in the spirit of the BSD license. If a legal department needs me to post a license, I will.</p> Absolutely. I haven’t generally put formal licenses on my example code, but it should be considered in the spirit of the BSD license. If a legal department needs me to post a license, I will.

]]> Comment on Drop-in offline caching for UIWebView (and NSURLProtocol) by Jonathan Wight http://robnapier.net/blog/offline-uiwebview-nsurlprotocol-588/comment-page-1#comment-15145 Jonathan Wight Sun, 29 Jan 2012 23:21:38 +0000 http://robnapier.net/blog/?p=588#comment-15145 <p>One big problem with this technique - and NSURLProtocols in general - is that various media types cannot and will not be forced to load via protocols.</p> <p>Off the top of my head video and audio won't work, neither will SVG. This <em>really</em> limits its usefulness as a general purpose loader for web views.</p> <p>It's very frustrating. Bugs have been filed. Teeth have been gnashed.</p> <p>Also you want to be really careful with concurrency. URL loading should never block the main thread - try loading a web page with a lot of images though a non-concurrent URL protocol - it's quite a painful experience.</p> One big problem with this technique – and NSURLProtocols in general – is that various media types cannot and will not be forced to load via protocols.

Off the top of my head video and audio won’t work, neither will SVG. This really limits its usefulness as a general purpose loader for web views.

It’s very frustrating. Bugs have been filed. Teeth have been gnashed.

Also you want to be really careful with concurrency. URL loading should never block the main thread – try loading a web page with a lot of images though a non-concurrent URL protocol – it’s quite a painful experience.

]]> Comment on Drop-in offline caching for UIWebView (and NSURLProtocol) by Joe http://robnapier.net/blog/offline-uiwebview-nsurlprotocol-588/comment-page-1#comment-15144 Joe Sun, 29 Jan 2012 21:05:28 +0000 http://robnapier.net/blog/?p=588#comment-15144 <p>This really awesome! By any chance are you making this open source? Can we use this in our projects?</p> This really awesome! By any chance are you making this open source? Can we use this in our projects?

]]> Comment on Properly encrypting with AES with CommonCrypto by Rob Napier http://robnapier.net/blog/aes-commoncrypto-564/comment-page-1#comment-15056 Rob Napier Sat, 14 Jan 2012 22:23:21 +0000 http://robnapier.net/blog/?p=564#comment-15056 <p><a href="#comment-15055" rel="nofollow">@Richard Fink </a> If it's 7-bit ASCII (real ASCII, not just "text"), then yes, that is a subset of the UTF-8 (8-bit) encoding space. What does the decoded data look like? Does it look like a string of characters?</p> @Richard Fink If it’s 7-bit ASCII (real ASCII, not just “text”), then yes, that is a subset of the UTF-8 (8-bit) encoding space. What does the decoded data look like? Does it look like a string of characters?

]]> Comment on Properly encrypting with AES with CommonCrypto by Richard Fink http://robnapier.net/blog/aes-commoncrypto-564/comment-page-1#comment-15055 Richard Fink Sat, 14 Jan 2012 22:08:17 +0000 http://robnapier.net/blog/?p=564#comment-15055 <p><a href="#comment-15020" rel="nofollow">@Rob Napier </a> Well, the original data that was encrypted was simple ASCII character data. So I think that qualifies as UTF-8 encoding, am I wrong there ?</p> @Rob Napier Well, the original data that was encrypted was simple ASCII character data. So I think that qualifies as UTF-8 encoding, am I wrong there ?

]]> Comment on Properly encrypting with AES with CommonCrypto by Rob Napier http://robnapier.net/blog/aes-commoncrypto-564/comment-page-1#comment-15020 Rob Napier Wed, 11 Jan 2012 17:40:32 +0000 http://robnapier.net/blog/?p=564#comment-15020 <p><a href="#comment-15015" rel="nofollow">@Richard Fink </a> Was the original input a UTF-8 encoded string (versus some other encoding such as a Windows CP encoding or UTF-16 encoding)? Make sure that the <code>NSData</code> itself is not <code>nil</code>. If it is, that suggests you have a decryption error. If not, take a look at the data directly. Does it appear to be a UTF-8 string? (In the debugger, use <code>p (char*)[data bytes]</code>.)</p> @Richard Fink Was the original input a UTF-8 encoded string (versus some other encoding such as a Windows CP encoding or UTF-16 encoding)? Make sure that the NSData itself is not nil. If it is, that suggests you have a decryption error. If not, take a look at the data directly. Does it appear to be a UTF-8 string? (In the debugger, use p (char*)[data bytes].)

]]>