dispatch_once does effectively the following:

lock(token);
if (! token) {
  ... do the block ...
  token = <something not 0>;
}
unlock(token);

Logically it works like the above, but the actual implementations of “lock()” and “unlock()” are insanely fast if token has already been set and there’s no actual blocking. See Jim Dovey’s discussion on how this can be implemented using OSAtomicCompareAndSwapPtrBarrier(), which is probably similar to how dispatch_once is actually implemented, but I haven’t gone and looked.

Would I be right in assuming that multiple instances of CALayer can share the same content? In the sense that when you set

layer1.content = aCGImage;
layer2.content = aCGImage;

they’re pointing to the same CGImage in memory, as opposed to each layer making its own copy of the image?

I had an app in mind that would make extensive use of “stamping”, as you call it.

Does it make sense?

The part:


if ([recentlyAccessedKeys count] > kCacheMemoryLimit) {
NSString *leastRecentlyUsedDataFilename = [recentlyAccessedKeys lastObject];
NSData *leastRecentlyUsedCacheData = [memoryCache objectForKey:leastRecentlyUsedDataFilename];
NSString *archivePath = [[AppCache cacheDirectory] stringByAppendingPathComponent:fileName];
[leastRecentlyUsedCacheData writeToFile:archivePath atomically:YES];

[recentlyAccessedKeys removeLastObject];
[memoryCache removeObjectForKey:leastRecentlyUsedDataFilename];
}


Should be:


if ([recentlyAccessedKeys count] > kCacheMemoryLimit) {
NSString *leastRecentlyUsedDataFilename = [recentlyAccessedKeys lastObject];
NSData *leastRecentlyUsedCacheData = [memoryCache objectForKey:leastRecentlyUsedDataFilename];
// Changes: path yo save in disk the last object in memory
NSString *archivePath = [[AppCache cacheDirectory] stringByAppendingPathComponent:leastRecentlyUsedDataFilename];
// End changes.
[leastRecentlyUsedCacheData writeToFile:archivePath atomically:YES];

[recentlyAccessedKeys removeLastObject];
[memoryCache removeObjectForKey:leastRecentlyUsedDataFilename];
}


Thanks!
Jose.

I’m aware of no security risks in using SHA-1 in the HMAC of PBKDF2 that are mitigated by using SHA-2. I am eager for links to known or theorized vulnerabilities from knowledgeable writers. It’s not just that it’s “not that bad.” It is currently equivalent to SHA-2 in security terms for use within the HMAC of PBKDF2. PBKDF2 simply does not require a collision-resistant hash in its HMAC in order to maintain its security (hooray!). This is why Schneier said “it doesn’t affect applications such as HMAC where collisions aren’t important.” There are some concerns about PBKDF2 because its may be too easy to implement in hardware, but that’s unrelated to collisions in the hash function and is not improved with SHA-2.

I developed RNCryptor specifically because so many iOS developers were using AES wrong. They’d heard the simple rule “AES good,” and then proceeded to implement it completely insecurely thinking that its AESness would cover all sins. We need to educate our engineers better in how crypto systems work and how to reason about them. There is too much “I heard this was good and this was bad” and it leads to bad security implementations. Someone in the org needs to know how to evaluate issues with more than just rules of thumb, and developers need know when to go to the expert for advice.

Of course you shouldn’t design your own KDF. No argument. Nor your own hash or cipher. You shouldn’t even implement them yourself if you can possibly help it. That’s why RNCryptor relies entirely on the OS for security code.

As I said, we should move to SHA-2 in PBKDF2 as a matter of housekeeping. We should move to SHA-2 for digests as a matter of security. Security people should be clear on the difference, and push much harder on the ones that matter so we don’t use too much political capital fixing things that aren’t broken.

I apologize for the length. I’ve tried to trim it down a bit. This is a passion for me, as I suspect it is for you. And I still highly recommend the Stanford course. It’s free and excellent. I think every senior security professional should at least attempt it.

Thanks for reading. I do appreciate the comments. As you say, this stuff is very real-world for you. I hope my writing can help your iOS developers write more secure code.