> It's seems important to me that the decrypted composition resides in memory 
> not written, even temporarily, to HD in plain-text. A force quit of hosting 
> app like Keynote or QC Editor then search ".qtz" & sort by date will turn up 
> the secret composition in plain text form otherwise (as pointed out by 
> Christopher on the Kineme thread). 

In memory isn't much better than on-disk to a determined adversary.  And to be 
honest this doesn't require a particularly determined adversary at all (more 
than a casual finder-only attacker, but if that's all you're trying to thwart 
then vade's "use an encrypted NSData" is more than sufficient - in fact, that's 
what the NSData API was added for.  If you're wanting to prevent even less 
casual attackers, you'll need to do some leg work to find out how they do what 
they do, and then how to prevent that where possible and how to make it 
inconvenient where not possible.  There's a cost/benefit curve between 
complexity and breakability, and you'll need to find where you're comfortable 
on that curve based on your constraints (how much complexity are you willing to 
write/purchase from a developer, how much illicit activity do you intent to 
prevent, etc.)


> Are you talking about writing a QC composition in Xcode that can load and 
> decrypted the NSData blob from another file?  Or are we talking about a 
> writing a QC plugin that loads the NSData and decodes it and somehow creates 
> a QCComposition object that can bind to the plugin patch's ports in QC.

QCComposition has documented API initializers, including +compositionWithFile:  
 and +compositionWithData:.  you can create a mutable data from a file on disk, 
decrypt it (using any one of a variety of algorithms), and then feed it to 
+compositionWithData:.


Your requirements aren't particularly well-defined:

> The encryption key remains secret from a inquisitive competitor! Where would 
> it be stored or would it auto-generated at runtime and stay secret somehow? 
> Or would it be stored in the Keychain at installation time thereby becoming 
> safe.

how inquisitive?  Also, you're totally missing out on numerous attack vectors 
that happen _after_ decryption in memory, regardless of how locked down the key 
is.  Stuff in the keychain is user-visible (via the "show password" check box + 
enter their keychain password).
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to