Suppose I made an app that allows a user to enter plain text, and encrypt it with a password. Then the app stores the cipher text in core data. The user can select a "file", enter that same password to decrypt it, then view the plain text (but hopefully not the cipher text). If the wrong password is entered, the app will not attempt to decrypt the cipher text.

  1. How could one acquire and view the cipher text? Is it possible? I would expect this to be a major help to one trying to discover the algorithm or decrypt the cipher text.
  2. How could one alter the cipher text so that they could attempt to decrypt it in order to learn more about the algorithm? Is it possible to alter an app's core data without using the apps built-in update functions?

Assume that neither the password, the plain text nor the cipher text is sent over a network.

I expect I should provide more details. Just let me know.

  • 3
    Why do you care if the attacker knows anything about the algorithm? Encryption is supposed to be secure when the attacker knows everything but the key/password. Commented Jan 11, 2017 at 13:47

3 Answers 3


Cryptography can be used to protect against tampering even with offline attacks. Modern cryptography which doesn't detect tampering and relies on secrecy of its algorithms should be considered broken and is essenatially useless. A modern cryptosystem (say , AES-GCM) uses completely public algorithms , is resistant against differential cryptanalysis and tamper-proof with offline access to the ciphertext.


Disclaimer: as I don't know apple architecture well, I won't answer the "how could", only the "could someone" question and add some ideas about how you should make an app that uses encryption.

Found in https://stackoverflow.com/questions/25747327/securing-data-using-core-data-in-ios :

Core Data makes no guarantees regarding the security of persistent 
stores from untrusted sources and cannot detect whether files have been
maliciously modified. The SQLite store offers slightly better security than
the XML and binary stores, but it should not be considered inherently 
secure. Note that you should also consider the security of store 
metadata since it is possible for data archived in the metadata to be 
tampered with independently of the store data. If you want to ensure 
data security, you should use a technology such as an encrypted disk image.

Basically, you can't (and shouldn't) trust that core data is secure.

That means that you should expect someone could both modify and access your ciphered text.

Also, if you rely on no one discovering your algorithm (security through obscurity) to secure something, you'll have a bad time.

Finally, I would suggest using a tried-and-true method:

  • user enters a password
  • you take the sha 256 checksum of [password + some pseudo-random number (called salt)]
  • use this as your key
  • (de/en)crypt the text with AES, using the key you generated.

Conveniently sha256 gives us 256bits, and AES needs a key of 128, 192 or 256bits.

The salt should be something you can easily calculate, like another hash of the password or that is stored alongside the file. (makes it a bit more annoying to bruteforce)

Voila, your data is secured, the only* way to decypher it is to either crack AES (probably not anytime soon), or know/bruteforce the password.

A way to slow down bruteforce is to use a pepper, a small number randomly generated each time the user uses his password, it is added to the salt.

The way it works is that you try every pepper until you find the one that unlocks the file, that is "slow" (if you have 16 possible peppers, you try on average 8 times before getting the file open, but with the wrong password, you try all 16 before figuring out) but fast enough so that the user doesn't notice, with something like a pepper size of 8bits (0-255) it may take 1/10s, that is really painful for a bruteforce attack on the password, but not really slow for the user.

to slow down again, you can use multiple rounds of the hash algorithm you chose. e.g. hash(hash(hash(password+salt)))

I'm not sure if it matters in this case, but just to be sure use sha256 instead of md5.

Instead of rolling your own version of a Key derivation function by concatenating a salt with the password and applying multiple times the hash, use an already made one such as PBKDF2. to do that, use PBKDF(password,salt,Number of iterations), the greater the size and entropy of the salt, and the greater the number of iterations, the better.

  • 1
    MD5 is not suitable for transforming passwords into keys. MD5 is not suitable for virtually anything related to cryptography, and has not been for more than five years. But it's especially not suitable as a KDF. Please use PBKDF2, scrypt, or Argon2 to turn passwords into keys suitable for encryption. Commented Apr 11, 2017 at 22:43
  • @StephenTouset I edited my post according to that, but I'm not sure if it matters when used to stretch the key to use as an input to the AES algorithm and the password is not stored. though, for brute force it would matter, as sha 256 is 1.5-3 times slower than md5.
    – satibel
    Commented Apr 12, 2017 at 9:35

Only encryption you completely control can be trusted. Anything 'stored' on the computer is in danger so the logical method is by using encryption that is not connected to the internet. Old school cipher instruments are now coming back due to the fact the communicators control every aspect of the process.

The Galaxy Cipher Instrument is one example: Cryptography Forums, Topix.

The patterns should also be non-logic patterns like the shape of a wire found in a junk yard, the twisting line of a river on a map, anything.

There is a dot on each disc somewhere in between the numbers that is used as a reference for shifting the next disc away from. This instrument is secure even from the NSA.

  • You are really not answering the question at all, and I believe the majority here will not agree with you that open source encryption algorithms are untrustworthy.
    – MiaoHatola
    Commented Jun 2, 2017 at 15:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .