• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Encryption
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Encryption


  • Subject: Re: Encryption
  • From: Nicko van Someren <email@hidden>
  • Date: Thu, 1 Jan 2004 22:43:19 +0000

On 1 Jan 2004, at 21:56, Robert Tito wrote:

Besides, all the encryption functions are completely described on their
appropriate websites, as well as C/C++ code to create them. In stead of
using one engine (128 bits generally) that can be cracked nowadays within 20
minutes a mix seems more appropriate: dont use static encryption in stead
use a flexible multiple engine based on synchronized timestamps

I have to say that this is bad advice on a couple of counts.

Firstly, 128 bit symmetric encryption is perfectly safe for general use when performed properly. If your keys are random then it will take about 2^127 tries to guess it; if every person on the planet had a machine that could try 1 billion keys a second then you'd still be waiting a thousand times longer then earth has existed to try that many. As such a mix of encryption systems is unnecessary and simply adds complexity, which leads to bugs, which can lead to insecurity.

Secondly, though it's true that you should not use static encryption keys using keys based on time stamps is just as dangerous (one of the early implementations of SSL was broken for doing exactly that).

The best way to handle keys is very application dependent. If you are trying to encrypt bodies of data so that the same user can come back later and decrypt it then an effective way to handle the key is to get them to enter a pass phrase and run it through a hash function such as SHA1. If you're doing this it's a good idea to use what's called a "salt" where you take a bunch of random bytes that are appended to the pass phrase before you hash it to make the key and you also write the "salt" data, unencrypted, into the file. This is useful for stopping the attacker pre-computing the hashes of common passwords.

If you're trying to encrypt data so that it can then be sent to a remote recipient who is not necessarily already know to the user then you're best bet is to use public key encryption. The crypto library in from OpenSSL (in /usr/lib/libcrypto.dylib on the standard distribution) can do all of this, though the use is it is beyond the scope of a posting here. Another option for quality, interoperable public key crypto is the framework that comes with PGP for the Mac. It's commercial but worth considering if you want to use public key cryptography and have someone else deal with all the hassle of trust management.

Cheers,
Nicko
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: Encryption
      • From: Robert Tito <email@hidden>
References: 
 >Re: Encryption (From: Robert Tito <email@hidden>)

  • Prev by Date: How to download via WebKit pages?
  • Next by Date: Re: Encryption
  • Previous by thread: Re: Encryption
  • Next by thread: Re: Encryption
  • Index(es):
    • Date
    • Thread