Re: file encription/decriptoin iOS
Re: file encription/decriptoin iOS
- Subject: Re: file encription/decriptoin iOS
- From: Alastair Houghton <email@hidden>
- Date: Tue, 27 Jun 2017 08:51:35 +0100
On 27 Jun 2017, at 03:25, Sandor Szatmari <email@hidden> wrote:
>
> This is an interesting thread. The OP's original question made me think of
> the functionality Apple recently (how recently I'm not sure) added to the iOS
> Notes app. It allows you to selectively 'encrypt' (password protect) a note.
> This functionality allows you to pass your phone to someone to let them read
> a note and not worry about them skipping to your note with all your 'secret
> info’.
There’s no need to encrypt the note for that, though - just storing a password
hash would be sufficient.
> Also, if someone got your phone in an unlocked state, (it could happen I
> guess) they couldn't trust a Mac and browse to plain text files.
That’s a risk, albeit a small one, and you have control over that risk (you can
set both the passcode and also the time the phone remains unlocked for). Yes,
cryptography could mitigate that risk, though as I said in my previous post,
you’d need to use a KDF, so effectively you’d have a separate passphrase for
your data. If someone can force you to unlock your phone, they can also force
you to unlock your cryptographic store.
> I must say at this point I whole heartedly agree with all the warnings for
> implementing encryption schemes. But is there not also a valid use case
> here? Unless I'm misunderstanding things, Apple seemed to think so.
There are certainly reasonable use-cases (apps like 1Password spring to mind)
where doing your own crypto might make sense.
My guess, though, is that the OP was asked to implement a system for
distributing paid-for PDFs such that the user couldn’t extract them from the
device - essentially a DRM system for PDFs from a particular source. I’d
generally try to dissuade people from such a scheme - it makes little sense
displaying the information to a user and then refusing to allow them to copy it
(except via screenshots or possibly copy and paste), but the fact remains that
the first step in implementing such a system is to carefully define what the
system is, who the trusted and untrusted parties are, and what kind of attacks
you’re trying to protect against. *If* cryptography is required at that point,
it needs to be done by someone who is sufficiently competent that they aren’t
going to render the exercise pointless. You can certainly learn what you need
to be competent in this area; it isn’t, contrary to what some might claim, some
kind of high voodoo only available to carefully selected initiates. But it
*is* complicated *and* generally speaking, poorly documented, so the risk of
mistakes is high - you probably shouldn’t learn on a shipping product.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden