Re: Is cloning the same as copying in APFS?

[Jens Alfke]

> On Jun 26, 2017, at 7:38 PM, Rick Mann  wrote:
> 
> But there's actually a POSIX "clone" API, and so I wonder if a copy is 
> different from a clone.

The low level file copying API that I’m aware of is , which is 
Apple specific. It has options for doing copy-on-write.
I don’t know if NSFileManager’s copy method clones files. I would assume that 
it does, on APFS.

—Jens

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: file encription/decriptoin iOS

[Jens Alfke]

> On Jun 26, 2017, at 7:25 PM, Sandor Szatmari  
> 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'.  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.  

I hadn’t heard of that feature. It seems a bit odd, but I suppose people do 
share devices.
Does Apple explicitly refer to this as “encryption"? If not, I suspect that 
they’re simply storing a password with the note, and the GUI won’t display the 
note until you enter the password.

> 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’s some use in a scenario like this, and it could be a nice feature to add 
to apps … if there were a convenient and trustworthy file encryption API 
available. But there doesn’t seem to be. (I don’t know what it is about Apple 
and crypto APIs, but there appears to be zero interest in or competence at 
improving them. If anything, they appear to get worse over time.)

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is cloning the same as copying in APFS?

[Sandor Szatmari]

> On Jun 26, 2017, at 22:45, Quincey Morris 
>  wrote:
> 
>> On Jun 26, 2017, at 19:17 , Sandor Szatmari  
>> wrote:
>> 
>> Are you talking about just a regular old copy or a copy in the sense of a 
>> time machine backup?  Are these behaviors different on APFS?
> 
> Yes and no. A regular old copy will create metadata for a new file, and point 
> back to the data blocks of the copied file. A time machine backup will create 
> a snapshot, which is effect a copy of all the metadata in the volume, with 
> the same shared pointers to the data blocks.

Yes, I felt the description of the copy on write behavior was intended to be 
universal to all copy operations not just a special operation reserved for time 
machine.  But, my even more admittedly vague understanding did not allow me to 
confidently draw a distinction be tween the two.  Thank you for tipping the 
scales.

> 
> In both cases, the functionality relies on the copy-on-write behavior, which 
> works at the data block level, not the file level.
Yes, this is very nice...
> (The latter point is worth keeping in mind, because it means that deleting 
> files in APFS may not recover all of the file’s size into free space.)
The ADC video stresses this point several times.

> 
>> On Jun 26, 2017, at 19:38 , Rick Mann  wrote:
>> 
>> But there's actually a POSIX "clone" API, and so I wonder if a copy is 
>> different from a clone.
> 
> My (admittedly vague) understanding is that all file system copy operations 
> are expected to be clones. I would imagine the difference between the APIs to 
> be that a “copy" will do a traditional duplication if the source file is 
> uncloneable (e.g. on a non-APFS volume), but the “clone” would fail.
> 
> But it would be a big hole if existing apps that copy items didn’t get the 
> cloning behavior by default.
> 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is cloning the same as copying in APFS?

[Quincey Morris]

On Jun 26, 2017, at 19:17 , Sandor Szatmari  
wrote:
> 
> Are you talking about just a regular old copy or a copy in the sense of a 
> time machine backup?  Are these behaviors different on APFS?

Yes and no. A regular old copy will create metadata for a new file, and point 
back to the data blocks of the copied file. A time machine backup will create a 
snapshot, which is effect a copy of all the metadata in the volume, with the 
same shared pointers to the data blocks.

In both cases, the functionality relies on the copy-on-write behavior, which 
works at the data block level, not the file level. (The latter point is worth 
keeping in mind, because it means that deleting files in APFS may not recover 
all of the file’s size into free space.)

On Jun 26, 2017, at 19:38 , Rick Mann  wrote:
> 
> But there's actually a POSIX "clone" API, and so I wonder if a copy is 
> different from a clone.

My (admittedly vague) understanding is that all file system copy operations are 
expected to be clones. I would imagine the difference between the APIs to be 
that a “copy" will do a traditional duplication if the source file is 
uncloneable (e.g. on a non-APFS volume), but the “clone” would fail.

But it would be a big hole if existing apps that copy items didn’t get the 
cloning behavior by default.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is cloning the same as copying in APFS?

[Rick Mann]

I'm not talking about Time Machine. My code allows the user to duplicate data, 
and thus it duplicates the files o the disk. A lot of the files referenced by 
the model are immutable, and so a clone/lazy copy is ideal.

But there's actually a POSIX "clone" API, and so I wonder if a copy is 
different from a clone.

> On Jun 26, 2017, at 19:17 , Sandor Szatmari  
> wrote:
> 
> Are you talking about just a regular old copy or a copy in the sense of a 
> time machine backup?  Are these behaviors different on APFS?
> 
> The ADC video Quincey referred to a couple of weeks ago talked about 
> references to files being created (lazy copies).  Only when the blocks 
> associated with the newest reference are altered would any actual copying of 
> actual data be done.
> 
> Is this the behavior your referring to?
> 
> Sandor
> 
>> On Jun 26, 2017, at 21:34, Rick Mann  wrote:
>> 
>> If I use NSFileManager to make a copy on an APFS volume, will it make a 
>> clone underneath?
>> 
>> Is there a Cocoa API for cloning?
>> 
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> 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:
>> https://lists.apple.com/mailman/options/cocoa-dev/admin.szatmari.net%40gmail.com
>> 
>> This email sent to admin.szatmari@gmail.com


-- 
Rick Mann
rm...@latencyzero.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: file encription/decriptoin iOS

[Sandor Szatmari]

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'.  
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.  

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.

Sandor

> On Jun 26, 2017, at 13:59, Jens Alfke  wrote:
> 
> 
>> On Jun 26, 2017, at 9:50 AM, Alex Zavatone  wrote:
>> 
>> You can use the iExplore app to look in the Documents folder of any device 
>> you attach to your Mac. 
> 
> But you can only attach a device to your Mac if the device is unlocked, since 
> you have to OK the “Do you trust this computer?” alert.
> As recent court cases have shown, unlocking an iOS device against the owner’s 
> will is nearly impossible.
> 
>> Also, data protection SUCKS because it locks the files if the app goes in to 
>> the background, basically suspending any file based background operations 
>> like sql db updates. 
> 
> It does this by default, but you can alter those settings if you need 
> background access to certain files, basically trading some security for 
> greater access.
> 
>> Thanks to the help of Chris Thorman, I was able to update an AES256 hmac 
>> method to work with UTF-8 char sets.  We use this for data security over 
>> http.
> 
> It’s much easier to just enable SSL/TLS on the HTTP server. (Though I realize 
> there are cases where you don’t have control over the server, or 
> circumstances prevent deploying HTTPS.)
> 
>> Now, it might be overkill or just bad design, but we use a CoreData db with 
>> transformable property and encrypt the data stored. 
> 
> How do you store the encryption key? That’s often the downfall; even if you 
> put it in the Keychain, it can be accessed by an attacker if your app’s files 
> are accessible (unless you add TouchID authentication to it.)
> 
> (Also, I hope you’re using a different IV for each record you encrypt. Sorry 
> to be a broken record about this, but it’s important.)
> 
> —Jens
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/admin.szatmari.net%40gmail.com
> 
> This email sent to admin.szatmari@gmail.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is cloning the same as copying in APFS?

[Sandor Szatmari]

Are you talking about just a regular old copy or a copy in the sense of a time 
machine backup?  Are these behaviors different on APFS?

The ADC video Quincey referred to a couple of weeks ago talked about references 
to files being created (lazy copies).  Only when the blocks associated with the 
newest reference are altered would any actual copying of actual data be done.

Is this the behavior your referring to?

Sandor

> On Jun 26, 2017, at 21:34, Rick Mann  wrote:
> 
> If I use NSFileManager to make a copy on an APFS volume, will it make a clone 
> underneath?
> 
> Is there a Cocoa API for cloning?
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/admin.szatmari.net%40gmail.com
> 
> This email sent to admin.szatmari@gmail.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Is cloning the same as copying in APFS?

[Rick Mann]

If I use NSFileManager to make a copy on an APFS volume, will it make a clone 
underneath?

Is there a Cocoa API for cloning?


-- 
Rick Mann
rm...@latencyzero.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Embedded Collection View Controller scrolling issue

[Doug Hill]

Following up…

I had some people mention the inherent difficulties of 
scroller-within-a-scroller implementations. After some more testing I notice 
that all taps are being ignored by subviews in the scroller as I scroll content 
up. That is, the newly displayed content will now not respond to any taps.

A long shot I know, but any ideas on how to debug this before going through the 
TSI route? I'm sure that has to be some techniques for figuring this out.

Doug Hill
https://github.com/djfitz/SFFontFeatures 



> On Jun 19, 2017, at 11:45 PM, Doug Hill  wrote:
> 
> Hello Quincey,
> 
> First, I should have originally made clear this is iOS, apologies. Also, to 
> clarify, I am talking about the drag-scroll gesture, which would be the Pan 
> gesture. 
> 
> The scroller-within-a-scroller is definitely more complex but I've usually 
> made them work in previous view controllers I've developed. Like you, I don't 
> really have a great idea of what is happening under the hood in these various 
> UIScrollviews. Or even a good idea how to debug what seems like lower-level 
> stuff.
> Thinking about it more, I might look into priorities of the gesture 
> recognizers, since this sounds like it could be related. Otherwise, I'm still 
> looking for other ways to track this down.
> 
> Thanks again.
> 
> Doug Hill
> 
> 
>> On Jun 19, 2017, at 11:29 PM, Quincey Morris 
>>  wrote:
>> 
>> On Jun 19, 2017, at 16:22 , Doug Hill > > wrote:
>>> 
>>> The embedded collection view will only scroll if I drag on the area of the 
>>> collection view that is originally visible.
>> 
>> Can you clarify this a bit? Are you talking about the autoscrolling that 
>> happens when you drag-select, or scrolling that happens when you use a 
>> scroll gesture on a trackpad? If you click on one of the 
>> previously-hidden-but-now-exposed rows, then try to drag it as a separate 
>> step, does the scroll happen?
>> 
>> I’d assume the problem arises because you have a scroll view within a scroll 
>> view, and each scroll has installed a pan gesture recognizer. The recognizer 
>> may be capturing the visibleRect of the scrolled view, and when you scroll 
>> the outer view, there may not be anything to tell the inner view that its 
>> visibleRect has changed.
>> 
>> This is all pretty moot, though. Even if that’s the explanation, I can’t 
>> think of anything you can do about it.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: file encription/decriptoin iOS

[Jens Alfke]

> On Jun 26, 2017, at 9:50 AM, Alex Zavatone  wrote:
> 
> You can use the iExplore app to look in the Documents folder of any device 
> you attach to your Mac. 

But you can only attach a device to your Mac if the device is unlocked, since 
you have to OK the “Do you trust this computer?” alert.
As recent court cases have shown, unlocking an iOS device against the owner’s 
will is nearly impossible.

> Also, data protection SUCKS because it locks the files if the app goes in to 
> the background, basically suspending any file based background operations 
> like sql db updates. 

It does this by default, but you can alter those settings if you need 
background access to certain files, basically trading some security for greater 
access.

> Thanks to the help of Chris Thorman, I was able to update an AES256 hmac 
> method to work with UTF-8 char sets.  We use this for data security over http.

It’s much easier to just enable SSL/TLS on the HTTP server. (Though I realize 
there are cases where you don’t have control over the server, or circumstances 
prevent deploying HTTPS.)

> Now, it might be overkill or just bad design, but we use a CoreData db with 
> transformable property and encrypt the data stored. 

How do you store the encryption key? That’s often the downfall; even if you put 
it in the Keychain, it can be accessed by an attacker if your app’s files are 
accessible (unless you add TouchID authentication to it.)

(Also, I hope you’re using a different IV for each record you encrypt. Sorry to 
be a broken record about this, but it’s important.)

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: file encription/decriptoin iOS

[Alex Zavatone]

You can use the iExplore app to look in the Documents folder of any device you 
attach to your Mac. 

Also, data protection SUCKS because it locks the files if the app goes in to 
the background, basically suspending any file based background operations like 
sql db updates. 

We got burned on that badly in the past.

Thanks to the help of Chris Thorman, I was able to update an AES256 hmac method 
to work with UTF-8 char sets.  We use this for data security over http.

Now, it might be overkill or just bad design, but we use a CoreData db with 
transformable property and encrypt the data stored. 

I can detail later if you wish.

- Alex Zavatone

Sent from my iPhone

> On Jun 26, 2017, at 3:39 AM, Alastair Houghton  
> wrote:
> 
>> On 24 Jun 2017, at 21:12, yu...@aim.com wrote:
>> 
>> I hope i am at the right place to ask for help on file encryption/decryption 
>> for iOS.
>> 
>> I need to encrypt a pdf file during download and to decrypt it for display 
>> later on.  Can i get some pointers about implementing the 
>> decryption/encryption part ?  or if there is any existing 
>> decryption/encryption package or code i can use ?
> 
> Step back a bit; what’s the use-case for this?  If you’re worried about 
> protecting data at rest, iOS already does that automatically; see
>  
> 
> 
> Applications can’t directly access other applications’ files anyway, so the 
> only remaining use-case would appear to be preventing someone else with 
> physical access to the device *and* the ability to unlock it from downloading 
> the data.  Additionally, if you use a crypto layer on top of that, you’re 
> going to have a problem, namely where to store the key.  The only way you’re 
> going to be *more* secure is if you derive the key from a passphrase using a 
> Key Derivation Function (PBKDF2, for instance) and then ask the user for that 
> every time - but it isn’t clear to me what the advantage of doing that is 
> over getting the user to use a secure passcode for their device in the first 
> place.
> 
> If you *really* must do this, well, it’s quite complicated.  You’ll want to 
> use CommonCrypto (see “apropos 3cc” or “man CC_crypto” in a Terminal window) 
> with AES, which is a block cipher, so you’ll need padding (see 
> ), which you’ll need to 
> implement carefully and check when you’re reading the file - any errors with 
> the padding should be a hard fail.  If you just want to read the entire file 
> in as one blob, you could use the default mode (CBC mode), but if you need 
> random access for any reason you’ll need to build an implementation of CTR 
> mode on top of CommonCrypto’s ECB mode (see 
> ).  You’ll also 
> need to generate an IV (Initialization Vector) or nonce using a suitable 
> random number source (/dev/random or SecRandomCopyBytes() are appropriate 
> choices here; rand() or random() are not, nor is some dodgy function you came 
> up with yourself, or *any* non-cryptographic RNG you looked up in a 
> textbook); DO NOT USE ALL ZEROES FOR YOUR IV.  You’ll need to store the IV 
> with the file (e.g. as the first chunk of data).  You’ll also need a nonce 
> for your KDF, which also needs to be secure and also needs to be stored 
> somewhere.  You’ll need to think about whether there’s a single passphrase 
> that unlocks all the data in your application (in which case you then need to 
> consider whether using a single AES key for everything is good enough, or 
> whether you want per-file AES keys, and in *that* case you need to know 
> either (a) how you’re going to derive all those keys from the one passphrase, 
> or (b) if you’re going to store them encrypted with a key derived from the 
> passphrase).  There’s a whole heap of complexity to think about here, and 
> some of the answers may depend on exactly how your application works (e.g. 
> whether an attacker could conceivably supply a PDF to it for encryption, or 
> whether you can guarantee somehow - e.g. using SSL certificate pinning - that 
> the PDFs only come from a trustworthy source).  This is tricky stuff and 
> given the question you asked, I’m honestly not certain you’re the right 
> person to be implementing it --- I’d tend to recommend that you find someone 
> with expertise in this area to help you, or at least give you some advice --- 
> and you’ll need to start by carefully examining the entire system you’re 
> building and looking to see what threats you’re trying to protect against.
> 
> Personally, I strongly suspect that all of the above is unnecessary and that 
> you can just let iOS protect your data for you.  On the plus side, you’re 
> unlikely to make your data any 

Re: file encription/decriptoin iOS

[Jens Alfke]

What Alastair said. (I’m usually not one for “me too” comments, but in this 
case since you’re being advised to not do something I thought another vote 
might be useful.)

I have about a dozen years’ experience working with crypto APIs on Apple 
platforms. Crypto is difficult to understand and difficult to do right. It’s 
all too easy to make mistakes with crypto primitives that will make the 
encryption trivially breakable.

It’s been pointed out that, unlike other types of programming where bugs in 
your code will be triggered more or less at random, in security programming you 
have to assume there are human actors working as hard as they can to find ways 
to trigger your bugs. This makes it much more likely that bugs will be found 
and exploited. And of course the consequences can be very serious.

Your app data on iOS is already encrypted pretty securely. This is described in 
Apple’s excellent iOS Security white paper, in the section “Data Protection in 
apps”:
https://www.apple.com/business/docs/iOS_Security_Guide.pdf 


—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

help! (book)

[J.E. Schotsman]

Hello,

I still cannot get my help book anchors to work programmatically (using 
NSHelpManager.shared().openHelpAnchor).
I checked the Help Book works when double-clicked in 
~/Library/Documentation/help
I’ve checked the help index file in the terminal (hiutil -A and -D). The 
anchors and the files containing them are there.
I’ve implemented the minimal info.plist as per the directions of Alastair 
Houghton:

https://alastairs-place.net/blog/2015/01/14/apple-help-in-2015/

I have trashed caches, restarted my computer, and still I get the message “The 
selected topic is currently unavailable”.
Reverting to AHGoToPage seems to be no longer possible.

If anyone can point out the error in my test project I would be much obliged.

http://jeschot.home.xs4all.nl/TestHelp.zip

Jan E.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: file encription/decriptoin iOS

[Alastair Houghton]

On 24 Jun 2017, at 21:12, yu...@aim.com wrote:
> 
> I hope i am at the right place to ask for help on file encryption/decryption 
> for iOS.
> 
> I need to encrypt a pdf file during download and to decrypt it for display 
> later on.  Can i get some pointers about implementing the 
> decryption/encryption part ?  or if there is any existing 
> decryption/encryption package or code i can use ?

Step back a bit; what’s the use-case for this?  If you’re worried about 
protecting data at rest, iOS already does that automatically; see
  


Applications can’t directly access other applications’ files anyway, so the 
only remaining use-case would appear to be preventing someone else with 
physical access to the device *and* the ability to unlock it from downloading 
the data.  Additionally, if you use a crypto layer on top of that, you’re going 
to have a problem, namely where to store the key.  The only way you’re going to 
be *more* secure is if you derive the key from a passphrase using a Key 
Derivation Function (PBKDF2, for instance) and then ask the user for that every 
time - but it isn’t clear to me what the advantage of doing that is over 
getting the user to use a secure passcode for their device in the first place.

If you *really* must do this, well, it’s quite complicated.  You’ll want to use 
CommonCrypto (see “apropos 3cc” or “man CC_crypto” in a Terminal window) with 
AES, which is a block cipher, so you’ll need padding (see 
), which you’ll need to 
implement carefully and check when you’re reading the file - any errors with 
the padding should be a hard fail.  If you just want to read the entire file in 
as one blob, you could use the default mode (CBC mode), but if you need random 
access for any reason you’ll need to build an implementation of CTR mode on top 
of CommonCrypto’s ECB mode (see 
).  You’ll also 
need to generate an IV (Initialization Vector) or nonce using a suitable random 
number source (/dev/random or SecRandomCopyBytes() are appropriate choices 
here; rand() or random() are not, nor is some dodgy function you came up with 
yourself, or *any* non-cryptographic RNG you looked up in a textbook); DO NOT 
USE ALL ZEROES FOR YOUR IV.  You’ll need to store the IV with the file (e.g. as 
the first chunk of data).  You’ll also need a nonce for your KDF, which also 
needs to be secure and also needs to be stored somewhere.  You’ll need to think 
about whether there’s a single passphrase that unlocks all the data in your 
application (in which case you then need to consider whether using a single AES 
key for everything is good enough, or whether you want per-file AES keys, and 
in *that* case you need to know either (a) how you’re going to derive all those 
keys from the one passphrase, or (b) if you’re going to store them encrypted 
with a key derived from the passphrase).  There’s a whole heap of complexity to 
think about here, and some of the answers may depend on exactly how your 
application works (e.g. whether an attacker could conceivably supply a PDF to 
it for encryption, or whether you can guarantee somehow - e.g. using SSL 
certificate pinning - that the PDFs only come from a trustworthy source).  This 
is tricky stuff and given the question you asked, I’m honestly not certain 
you’re the right person to be implementing it --- I’d tend to recommend that 
you find someone with expertise in this area to help you, or at least give you 
some advice --- and you’ll need to start by carefully examining the entire 
system you’re building and looking to see what threats you’re trying to protect 
against.

Personally, I strongly suspect that all of the above is unnecessary and that 
you can just let iOS protect your data for you.  On the plus side, you’re 
unlikely to make your data any less secure than it is by default, and the 
default level of security is, I suspect, already sufficient for your needs.  On 
the minus side, if you make a mistake anywhere in all of this, it might render 
the entire exercise totally pointless (i.e. you’ll have written an obfuscation 
layer, rather than something that genuinely provides extra security); in the 
very worst case, you might actually enable an attacker to cause your code to do 
something unexpected, though iOS does do various things (ASLR, non-executable 
memory) that make that harder.

TL;DR: You probably don’t need to do this; what iOS does already is probably 
good enough for you.  If you really *do* need to do this, given the question 
you asked, you should consider hiring an expert to help you to understand the 
threat model, to help you make appropriate choices, and perhaps even to 
implement the encryption