AeroFS Security Overview

Security is at the heart of everything we do at AeroFS, and this page is intended to give a brief description and explanation of the security and cryptography usages in AeroFS.

Hybrid Cloud vs Private Cloud

This document describes the various communications that happen amongst AeroFS services. We'd like to take a moment to make some things in regards to the Hybrid Cloud vs Private Cloud models as clear as possible before diving into the details.

In the Private Cloud deployment model, absolutely no data or communications should happen with AeroFS servers. Period.

In the Hybrid Cloud deployment model, we do not store any file data on our own servers, and strive to reduce the overall amount of communication that happens with our servers, but some communication is still necessary (e.g. for account creation, email notification, and so on). These communications are outlined below in detail.

Account Creation

During sign up for both the Hybrid Cloud and the Private Cloud model, we take your password and apply the scrypt key-derivation algorithm with a per-user salt to produce a hard-to-compute shared secret. We never store your password in plaintext, ever - neither on your machine, nor on our servers or the AeroFS Appliance.

Device Setup

When you set up a new client, that client creates a 2048-bit RSA key which never leaves that machine. The key is stored in that user's AeroFS configuration folder (location varies by platform) and is set to be only accessible by the user setting up AeroFS. The client generates a certificate signing request, and depending on whether you use the Hybrid Cloud or the Private Cloud deployment, does one of the following:

  • Hybrid Cloud: Connects to our server, over TLS, and verifies that the server's certificate is signed by the AeroFS root CA (which is shipped with every client).
  • Private Cloud: Connects to your AeroFS Appliance, over TLS, and verifies that the appliance's certificate is signed by the AeroFS Appliance root CA (this CA is unique per AeroFS Appliance deployment and is generated on first boot).
The AeroFS client then provides your username, the certificate signing request, and the scrypt-derived password to the server/appliance, which verifies that the username and scrypt-derived password match. The server/appliance signs the certificate signing request and returns the freshly-minted certificate to the authorized device. This certificate will then be used in various communications.

Device-to-Device Communication

The clients communicate amongst themselves through TLS atop a variety of other transports, including direct TCP over a LAN, STUN, and a relay server used when direct network connectivity is impossible. In the Hybrid Cloud deployment, this relay server is In the Private Cloud deployment, your AeroFS Appliance also acts as a relay server. Each client has a 2048-bit RSA key and a certificate signed by the AeroFS root CA as described above in "Device Setup". We currently use the DHE-RSA-AES256-SHA ciphersuite, which establishes an AES-256-CBC session between the two peers. Each client verifies that the other client it is communicating with is:

  1. certified by the AeroFS CA to represent the device and user claimed,
  2. not listed as using a certificate with a serial number revoked by the AeroFS root CA, and
  3. authorized to send and receive information about the relevant shared folder.

All file data and metadata sent between peers is encrypted end-to-end through this TLS channel, so neither network sniffers nor our relay server can see your data.

Device-to-Server/Appliance Communication

Some actions require talking to AeroFS servers (or in the case of the AeroFS Private Cloud deployment, to the AeroFS Appliance). These mostly relate to account preferences, administration of shared folders, and information to help us improve AeroFS.

For these communications, we use connections secured with TLS. Where possible, we use the same client certificate signed by the AeroFS root CA as used in the peer-to-peer communications to verify identity, but we also have some services where the client identifies itself by presenting a username and password (after verifying the services's identity, of course).

We use strong ciphers and follow best practices for SSL/TLS usage.

Lost or Stolen Devices

We use certificate revocation lists to revoke the certificates for deleted devices. When you unlink or erase a device, we mark the certificate associated with that device as revoked, and notify each of your clients either immediately or as soon as they come online and reconnect to our push notification service that the revoked device is no longer to be trusted.

Security Libraries Used

Our implementation uses OpenSSL. We are subscribed to the OpenSSL security advisory mailinglist, and we update our OpenSSL version promptly when upstream releases security fixes.

Sign Up Now

Responsible Disclosure

We take all security issues and concerns seriously. If you believe you've found a security problem relating to AeroFS, please get in touch with us at

When disclosing security issues to us, we ask that you:

  1. Share the security issue with us in detail.
  2. Give us a reasonable opportunity to address the issue before making any information about it public
  3. Act in good faith not to degrade the performance of our services (including Denial of Service attacks)
  4. Not violate the privacy of other users.


Our PGP key is below. All security-related emails from AeroFS will be signed with this key, and you're also welcome to use this key to encrypt security related communication emails to us.

Key ID
Key type
Key Size
4096 bit
1224 692E 7E32 9664 1324 0BFB A3D2 4EC3 6E1D C9F9
User ID
AeroFS <>
        -----BEGIN PGP PUBLIC KEY BLOCK-----
        Version: SKS 1.1.0
        -----END PGP PUBLIC KEY BLOCK-----