Frequently Asked Questions (FAQ)

Starting in World War I, but really taking off during the Cold War and still used to this day, high frequency radio stations are used to broadcast a person reading random numbers and/or letters.  These transmissions are secret messages that are only decryptable by an intelligence officer, spy or soldier operating behind enemy lines that has the corresponding one time pad (OTP) to decrypt the random numbers being read in to a message.  Because anyone in the area receiving the signal from the broadcasting tower can listen, it is impossible for defending forces to identify or locate the recipient within this region.  The use of one time pad encryption means that the message is secure forever provided the one time pad is not used again, kept secure before use and is destroyed after use.  Our app of course doesn't use high frequency radio signals to send messages but does use one time pads (OTPs) for the ultimate messaging security and allows for anonymous messaging where your identity is not revealed, analogous to a numbers station. Check out Wikipedia's page for more information on the origins and history of numbers stations.

NOT Quantum Safe: RSA, ECC, AES-128, all current versions of TLS that rely on RSA/ECC and many, many more...all at risk of "Harvest Now, Decrypt Layer" 

Quantum Safe:

• AES-256

  • • but only when the AES key is exchanged via a quantum safe system, i.e. not when exchanged using RSA or ECC like all other messaging apps use

• One Time Pads (OTP)

Potentially Quantum Safe:

• CRYSTALS-Kyber...needs to be vetted for a longer period of time before high assurance can be achieved

Using a source capable of generating truly random data, a sender and receiver create and share with each other two "pads" of random data that cannot be recreated by anyone (because if it could be recreated, it wouldn't be truly random data).  Traditionally these "pads" would have been small booklets with pages of random letters or numbers but today is more often a file(s) on a computer. In modern implementations, like our app, each byte of the message the sender wishes to send is then "combined" with one byte of random data from the OTP to generate a new byte that is now encrypted.  This occurs for each byte in the message until the entire message is encrypted and ready to send.  There is no need to add additional layers of encryption at all at this point although one may chose to, as we have, to add redundant protection in case one of the copies of the OTP is compromised before it is used.

The recipient then reverses this process using their copy of the same OTP used to encrypt the message.

Two pads are shared because each person involved in the conversation uses one when sending and one when receiving, if both used the same pad for both sending and receiving they might accidently re-use the same parts of the pad for sending messages with different content which would then severely weaken if not totally break the otherwise unbreakable security offered when properly using unique pad material for every message.

Nope, totally different!

According to public sources and amateur radio operators that follow them, high frequency radio numbers stations relying on OTPs for message security are still in use to this day, presumably continuing to be used as they have in the past by intelligence services to anonymously and securely communicate with their intelligence officers or human sources in the field.

OTPs are also still used by diplomatic staff in embassies to secure their communications to and from their home country for particularly sensitive communications.  The "pads" are distributed via diplomatic couriers, sometimes by a pair of couriers to ensure no single person can compromise the keys. In some cases two separate pairs of couriers, each carrying different sets of OTPs, are used to implement two layers of OTP based encryption.  Inside the embassy, the communications officer who only has access to one set of "pads", from one pair of couriers, removes one layer of encryption and a different person, the intended final recipient of the message, removes the second layer.  In this manner no single person has access to all of the material required to successfully decrypt any messages.  For our app, two layers isn't relevant as presumably you're not trying to compromise yourself!

The final "common" use today is by countries with nuclear weapons for authentication of nuclear command and control orders. Since OTPs are unbreakable regardless of the computing power of an adversary, even quantum computing, it is the ultimate guarantee that the order for nuclear weapons release comes from the legitimate command authority and cannot be spoofed or alerted.

While it is the only encryption system that is truly unbreakable, it is difficult to implement correctly.

Issue #1: the critical part that most implementations fail at is the generation of truly random data, not pseudo random data that is generated by most computer systems and which is not really random. An attacker that knows some basic information about a computer system using pseudo random data can recreate that data and use it to decrypt a message.   Apple's introduction of the Secure Enclave though, a hardware based security coprocessor, for the first time enabled true random number generation in a mass produced mobile personal computing device.  Before this, such true random number generators were external devices that connected to personal computers via serial or USB connections and were often bulky, hard to find, produced data slowly and were expensive.  Outside of security applications, such devices are also used by lottery and casino operators to meet legal requirements on fairness and likelihood of winning when gambling.

Issue #2: you need to securely transfer the OTP material between sender and receiver before you can begin messaging, usually by physically meeting or using a trusted intermediary (like a diplomatic courier). You can't use a traditional non-OTP based encryption system to transfer it remotely over the Internet as then the strength of your overall system is as weak as the non-OTP encryption system used, so at a minimum susceptible to attack by a future quantum computing system. This is why our application only transfers the OTP material when the two users are in close phsyical proxiomity to each other.  In addition, the AES-256 encryption used to secure the OTP material while it is transferred between the two iOS devices is quantum safe when the key is secure, hence sharing the key optically, an attacker has to literally see the screen of the person receiving the material, intercept the transmission between the two devices and break the extra traditional encryption system that is running on top of our system.  If an attacker has that kind of access and power, then they're likely already photographing your messages as you read them.

Issue #3: you need to securely store the OTP material after it is transferred. Since the OTP material is destroyed as it is used, as messages are sent, a compromise of the OTP material impacts future messages that are sent, prior ones are still secure. Traditionally the material is stored in a safe (or a safe within a safe sometimes). Having the OTP material stored on a mobile device that you take everywhere with you and that rarely if ever leaves your sight is a good first step in ensuring the security of it.  If you saw someone accessing and copying data off of your phone with a USB cable you'd know it was time to regenerate new keys on a new device!  The larger risk though is a remote cyber attack that you never see, this is why we believe the top risk that needs to be addressed by any messaging app is the risk of zero-click exploits. See the FAQ entry "How does Numbers Station prevent remote exploitation?" for further information on how we protect against this. In the event that undetected remote exploitation does occur and the OTP material is compromised, the Perfect Forward Secrecy (PFS) protection of the outer two layers of encryption would continue to provide strong protection, only the inner quantum safe layer would be at risk.

There are a number of tests used in academia to test the quality of the output from a true random number generator.  As part of our development process we created a test app that generated and then exported random data in varying sizes (8-128 MB) and ran it on all the iPhone models that support iOS 15 (iPhone 7 through to iPhone 13). We then ran this data through the tests listed above and found that all the devices we tested generated data that was indicitive of a true random number generator and of the same quality as results run on a radioactive decay based true random number generator. We have NOT tested on iPad devices but have no reason to believe that the Secure Enclave on them would not have similar high quality random data as iPhone devices that utilize the same processors.  While not supported, our app can also be run on Apple Silicon based MacOS devices, a single MacBook Air M1 was tested as above and also generated high quality random data.  We are very impressed with the quality of the random data generated by all tested versions of Apple's Secure Enclave.

OTP encryption does not have a key length or key size in the same sense as symmetric key block cipher encryption systems (such as AES 256) or elliptic curve cryptography do. Instead the "key", in this case random OTP material, is the same length as the message to be encrypted. The OTP layer is the quantum safe layer in our encryption setup.

The traditional encryption layers that our app also uses for end-to-end encryption are Elliptic Curve Diffie-Hellman (ECDH) for key exchange of the AES-256 symmetric key as well as signaturing, using curve 25519 and curve P-256 and implemented using Apple's CryptoKit API. AES-256 is in GCM mode.

Short version is we know you paid for the subscription, but know nothing else about you, not even your e-mail address, name or how you paid

If you use Sign in with Apple to login, we receieve from Apple a token that is essentially a string of random numbers that we can verify with Apple to say that you did successfully login to the app using your Apple ID while we do NOT know anything else about your Apple ID.  This token is also refreshed routinely, often hourly, and cannot be used to trace backwards to your Apple ID. We receieve no other information from Apple at all, not the e-mail nor the name associated with your Apple ID.  We don't even have a username assigned to you when you use Sign in with Apple.  Apple knows that you purchased a subscription with our app and that you logged in to it but has no other information at all, i.e. nothing about who you are messaging, what you sent, etc.

If you use a username, it can be random, whatever you want it to be as there is no e-mail address or social media account information at all.  This also means though that if you forget your username and/or password, we can't recover it for you, reset the password, etc. as we have no way to contact you.

The IP address used to login and to send and receive messages is temporarily stored on our server infrastructure, you can use a VPN if you wish to obscure your real IP address.

The current version of the app makes no attempt to hide the fact that the app is connecting to our server. If an adversary is able to intercept your communications they would be unable to read your messages, know who you are communicating with or what your Numbers Station address is but they would know that you are connecting to our server and therefore using the app. This also means the app is likely to be blocked in certain countries that routinely block messaging apps and would require a VPN or other means to bypass this blocking, which may also result in the adversary not being aware that you are using the app.  We hope to add built-in features in a future version of the app that will result in hiding the fact that the app is connecting to our servers but it is not possible to make this a user friendly easy to use feature.

For securing your device:

1) Ensure you are running the latest version of iOS for your device.

2) If you are running iOS16 or later, enable Apple's Lockdown Mode. 

3) If Apple's iCloud Private Relay is available in your region, use it. It is part of Apple's iCloud+ subscription, so not free.

4) Remove all other messaging apps from your device and remove unnecessary apps in general.  If you are running other messaging apps you are still at risk of zero-click exploitation via those apps, Numbers Station can only protect itself, not other messaging apps.

5) Ensure you have a passcode set for your iOS device and that Auto-Lock is set to 30 seconds to reduce the amount of time before your device automatically locks itself and requires a passcode. Ideally use a pin that is not just numeric and that is longer than 4 numbers or characters. If that's a headache, at least use a 4 number pin over nothing. 

6) Do NOT use FaceID or TouchID, use passcode only. 

7) Within Numbers Station, enable block or quarantine for messages from unknown users. Optionally you can also enable block images from all users, even those in your contacts (in case one of your contacts is "off side"), and if you wish to view what is sent you can export the images to another device for viewing, thereby ensuring your iOS device is still secure even if they contain exploits.

8) Again within Numbers Station, enable app password protection and use a password different from the passcode for your iOS device.  Ensure this password is as long and complex as you can remember and do not write it down. You will need to enter it every time you access the app, even if you leave the app for just one second and return to it.

9) If you are at very high risk of attack, it would also be recommended that you run the app on a device that either does NOT have a cellular modem (i.e. no LTE connection at all), such as an iPod Touch or some models of iPad, or that you disable the cellular connection in settings and/or physically remove the SIM card to avoid any LTE modem/firmware based attack possibilities. This WiFi only device could also be safely paired with an LTE mobile hotspot for mobility requirements.

10) Use a standalone iOS device that has been reset and have Numbers Station as the only app installed on it.

10) As always, follow the standard warnings about not clicking on links you receive from unknown senders. 

Within the app, we have "pinned" the TLS certificates of our backend service provider to protect from man-in-the-middle attacks where an attacker tries to remove the TLS layer of encryption (i.e. the layer between your device and our backend service provider, which is different from the end-to-end layers of traditional and OTP encryption underneath the TLS layer).  Many corporate and school networks conduct what amounts to a man-in-the-middle attack to inspect all traffic in and out of their network while blocking all traffic that cannot be inspected, certificate pinning protects against this but also causes your connection to our servers to be blocked.

Because we don't know who sent the message (a big security bonus for you!), there is no way for us to then allow someone to delete a message, how would we know it was their message to delete?

Complexity is what kills security....the more features thrown in to an app, the more security problems they introduce.  Other competing apps that offer this have had a number of security vulnerabilities discovered and publicly reported which specifically were found in their audio and video calling code and encoders/decoders.  Another reason, a business reason, is that the bandwidth costs of running an app that allows audio and video chat, especially video, adds up quite quickly and we'd have to increase our subscription pricing substantially to address it.  The fact that other competing apps offer this for free should concern you....there is no free lunch, someone is paying for the servers and bandwidth costs and it might very well be from selling your information and data.

No, we do NOT!  Many, if not most, apps add in analytic or crash analysis add-ons that tell the developing company how users use their app, how often, etc. as well as send back crash logs if the app crashes that help them quickly find an error and fix it in an new version of the app.  These crash and analytic logs could include sensitive user data, i.e. the contents of messages. For security and privacy reasons, our app does NOT include any such add-ons.  While this is great for security and privacy, ensuring no data every leaves your device except that which is fully encrypted and being sent to and readable only by who you are messaging, the downside to this is, we rely on user feedback to fix bugs, make improvements, etc.

Client app side logging: None in any scenario, no analytics add-ons, etc.

Server side  logging: We do not log on our servers any of the actions of our users, i.e. we don't keep track of your IP address or who you are sending messages to or receiving them from.  The only scenario where we do log activity is for when data is written to our server that does not pass validation (such as total message size is too large) and is rejected, this should only occur if a malicious entity has bypassed Apple's App Attest service, likely by jailbreaking a device under their physical control, and running a modified malicious version of the client app. Any such rejected messages being sent to our server are highly suspicious and are likely a potential attacker attempting to learn what our validation on server is and therefor requires our attention. No legitimate user's traffic would fall in to this category.

Note that our backend server service provider, like any other messaging app company's server service provider, could enable logging for IP address usage.  To avoid this risk, which due to end-to-end encryption is minimal, you can use a VPN, public WiFi access, etc.

Due to the layers of end-to-end encryption used by our app, our server is unable to read any of the contents of your messages or see who they are from.  Our server only validates the non-encrypted information to validate that all of the correct data required for the receiving client to decrypt the message is likely present (only the client app side validation can confirm for sure) and of the correct data size to indicate that no obviously malicious content is present such as public encryption key sizes that are too large, payload size that is too small or too large to contain a legitimate message, etc.

For security reasons we chose not to allow the display of any sensitive information (such as the sender's Numbers Station address, your assigned nickname for that address and message contents) when your device is locked or the app is not active on the screen.  User's at high risk of their device being stolen and analyzed may also want to consider not having any notifications enabled at all as to not draw attention to the app being actively used, i.e. no incoming message notifications when device is locked as well as no badge notifications for when the device is unlocked but the app protection password is enabled blocking access to the app and the stored data.

Since we wipe the encryption keys used to access the app's stored data when the app is put in to the background (i.e. it is not actively running on the screen after you hit the home button or lock the device), there is no way to decrypt the incoming messages within the Notification Service Extension (NSE) since the data required is not accessible.

In short, security trumps ease of use in this instance.

Your list of contacts as well as the nicknames you assign them never leave your device and are stored with an app specific layer of encryption. They are also not backedup to iCloud. If you lose your device there is no way to recover them.

Not yet but we will begin working on one once there is a large enough iOS user base.

All recent iOS devices offer high quality security hardware co-processors, with Android it can be more hit and miss. Therefore we will have to restrict the app on Android to only certain devices which will require more extensive testing on a large number of different devices.

We just started the importation approval process with the French authorities, once it is complete the app will be available in France. This is separate from US export approvals.

Simply having the ability to quarantine potentially malicious messages and submit them for verification is enough to deter and fight back against hackers.  They will think twice before using a multi million dollar exploit chain against someone using our app when their exploit might be blocked, collected and exposed. Such exposure would make it worthless and destroy their ability to go after other victims using other apps as well. It is easier to just pass over our users entirely and move on to those using other messaging apps.

On top of our quarantine system, which makes it impossible for a remote unknown hacker to send you a malicious message that the app will process without your consent, we have taken other steps including:

"Memory Safe" Programming Language

Numbers Station's iOS version was developed entirely in Apple's "memory safe" programming language Swift, which removes entire classes of vulnerabilities, stopping the most common exploitation techniques from occurring. Other apps use Objective-C which does NOT remove these risks.

No Processing of Attachments 

Other messaging apps allow multiple image and file formats to be processed as messages arrive, in the background unseen by the user. This processing typically includes rescaling images.  Numbers Station though does zero processing of any inbound images or files as they are added to conversations, only decoding and displaying HEIC formatted images as the user opens the conversation they are in and does not allow any other image or file formats to be displayed within the app. To ensure user's actively consider the security implications of opening files, no files can be opened in the app.  They can be exported to the Files app and opened there, but for the absolute top security, they can be exported via iTunes to a PC, a virtual machine, etc. for opening the file off device therefore ensuring the security of the iOS device.

Attack Surface Reduction

Numbers Station is purely a secure messaging app. It is designed to securely message text, images and files.

Numbers Station does not include features that are rarely, if ever used, such as niche cryptocurrency payment systems.  Such features just add a larger attack surface, more things to go wrong and more vulnerabilities. Numbers Station also does not include "adware" or analytic code that can also be vulnerable to exploitation.

Secure Enclave backed App Specific Password & Secure Storage

Numbers Station uses Secure Enclave for encrypting all user data at rest and offers optional per user passwords to control access to the app and to that user's stored data.  When using this protection, all sensitive data in memory is wiped whenever the app is not active (i.e. when the app is not selected and on the screen). This restricts an attacker that has successfully exploited your device via another app from obtaining any information from users that are not actively logged in and in use after the user specific device password was entered (which is different from the login password for that user).

Limited Access to Operating System Data

Numbers Station does NOT have access to your microphone, video & photo library, location/GPS, etc.  The only thing Numbers Station requests access to is the camera, primarily for QR code scanning, and it can be disabled in iOS settings when not scanning QR codes.

Other messaging apps request access to ALL categories of data available on iOS, check for yourself, go to iOS Settings and then scroll down to your current messaging app to see everything it has access to. This puts all of that data at risk if an attacker is able to compromise that app, even if they are unable to break out of the app sandbox and compromise the entire operating system.

Metadata Not Visible

Other messaging apps allow hackers to see if victims are using that app just by searching on your phone number, e-mail address or social media login, all things an adversary could easily know.  Not only do they now know which app you are using, they have what they need to send a malicious message to you to exploit your device.  That's simply not happening with Numbers Station.

Summary

In summary, we use layers of security to:

A) make it difficult for a hacker to send you a malicious message in the first place

B) if someone tells them your address, we make it risky for them to even try to send an exploit since their malcious message could get quarantined, then shared with us by the user for us to perform analysis and the vulnerability the exploit is using would then be made public/patched

C) if they take the risk anyway *AND* you are not quarantining unknown messages, or they have someone you know send it, we make it difficult for that malicious message to actually do anything to your device 

D) and finally, we limit what they could access and the damage caused if they somehow made it through all of the previous steps and actually exploited the app, i.e. no access to your microphone, location/GPS, etc.

The app can use up to 3 layers of encryption when sending messages:

Inner layer: Quantum safe, end-to-end (optional to use)

This layer directly encrypts the text of your message and is only visible after the two following levels have been successfully decrypted, which is only possible for you the recipient to do.

Each byte of text in the message you are sending is XOR'd with a single byte from the sending One Time Pad (OTP) material.  The same OTP material is stored as the receiving pad on the recipient's device. This results in not only a quantum safe solution but also a completely unbreakable solution provided the security of the OTP material is not compromised (i.e. the material is secretly copied from your device before it is used).  If somehow it is copied, then the following layers still provide protection due to the use of ephmeral keys/Perfect Forward Secrecy (PFS).

There is no compression used on the text prior to OTP encryption as compression can weaken the security of the OTP process.

Images and files in a Quantum Safe-OTP conversation are encrypted differently from text messsages. Text is encrypted using the One Time Pad (OTP) process.  Images or files though are instead encrypted using an ephemereal AES-256 key (which is a quantum safe algorithm).  The AES-256 key itself is then encrypted using the OTP process and sent as a message that is also encrypted by the following layers.

Middle layer: State-of-the-art, end-to-end, using ephemeral keys for Perfect Forward Secrecy (PFS)

If Quantum Safe-OTP encryption is enabled for the conversation, this layer encrypts the OTP encrypted layer preceding it.  If QS-OTP is not enabled, then it directly encrypts the text of the message.  While the OTP layer is optional, this layer and the following layer are mandatory for all messages, it is NOT possible to send a message that is not protected by at least two layers.

A per message ephemeral Elliptic Curve Cryptography (ECC) Curve 25519 key pair is used to share an ephemeral AES-256 key with the recipient using one of the recipient's previously received per message ephemeral public keys.

All non-OTP cryptographic functions are performed using Apple's Crypto Kit framework which utilizes the Secure Enclave for generating encryption keys using the True Random Number Generator (TRNG) within the Secure Enclave. It also provides hardware acceleration and secure memory wiping of key material once it is no longer needed.

All ephemeral Curve 25519 key pairs expire within 24 hours and are stored within the app's sandbox but the data is encrypted using an AES-256 key.  This is on top of the encryption that iOS provides so that this data is still secure if you have entered a password for Numbers Station, even if your device is unlocked.  The AES-256 key for data storage is not stored in the app but is generated as required using key pairs that are within the Secure Enclave that are combined with your Numbers Station password.

This middle layer also contains within it's encrypted contents the sender's address (which is later cryptographically verified if further processing takes place, i.e. the message is not quarantined or blocked).

The middle layer is what is stored on our server for retrieval by the recipient, i.e. all we know is there is an encrypted blob of data being sent to an address, no idea who sent it since we do not log server activity

Outer layer: State-of-the-art, app-to-server, using ephemeral keys for Perfect Forward Secrecy (PFS)

This layer is similar to what is used when you see the lock next to a domain name in your web browser.  It protects the connection between our app running on your device and our server, but does not protect the data once it gets to our server, the previous layers do that. Certificate pinning is enabled to ensure this layer cannot be removed by an adversary attempting to perform a man-in-the-middle attack.

This layer currently uses TLS v1.3, the encryption algorithms used will depend on what iOS and our server negotiate but at a minimum will employ Perfect Forward Secrecy (PFS).

Short version: CRYSTALS-Kyber is simply too new and unvetted for us to rush to use it when an existing, well vetted, "no question it works and will survive" algorithm (i.e. One Time Pads) is available to use instead.  We may add CRYSTALS-Kyber in the future as an optional layer of encryption after the QS-OTP layer but would never remove the QS-OTP layer as an option.

Longer version:

The National Institue of Stanrdards and Technology (NIST) is part of the US government responsible for setting new encryption algoritm standards. In 2016 NIST began a process to identify new quantum safe or post-quantum algorithms that would survive the arrival of large quantum computers. When the process began, 59 encryption/key exchange mechanism schemes were submitted and over a number of years and rounds of vetting only one of them (CRYSTALS-Kyber) was not fully broken or had other concerns raised. All 59 were based on relatively new cryptographic ideas and 58 were rejected with the lone one remaining also relying on new cryptographic ideas. That just doesn't leave us feeling confident enough to rely on it.

See the following article for a good idea of why we don't think any algorithm but OTP is ready yet to be called quantum safe:  “Quantum-Safe” Crypto Hacked by 10-Year-Old PC

Note: while four algorithms were selected by NIST for post-quantum, three of the four are for signaturing, not for encryption/key exchange. There were 23 signaturing candidates at the start of the process.

You might find some critiques of One Time Pad based encryption systems on the Internet, this is because a lot of folks don't do it right, not because the system itself is broken.

1) They don't use a truly random hardware based number generator but some other process to generate "random" data that isn't actually random, thereby destroying the security of OTPs.  Our app uses Apple's Secure Enclave security co-processor hardware built-in to your device that provides very high quality truly random data that meets all tests of randomness that we threw at it.

2) They reuse One Time Pad material for different messages and don't delete used material. Numbers Station deletes them as they are used making re-use impossible.  Numbers Station also uses different pads for sending and receiving messages, this also avoids re-use.

3) They use One time pad material that is not as long as the message being sent, causing re-use. Our app simply stops encrypting messages if there is not enough one time pad material left to secure it and alerts the user that they need to exchange more pad material.

4) They exchange one time pads over the Internet that are either not secured at all or secured by traditional NON-quantum safe public key encryption (such as RSA, ECC, etc.) to share an AES-256 key, which then means all of the security of the system relies on the security of the traditional public key encryption, which a quantum computer will break, resulting in total failure.  While our app does exchange the one time pads between users, it does so in a quantum safe way that ensures security.  The transfer occurs over a local Bluetooth link (i.e. AirDrop), that isn't interceptible beyond a short distance.  More importantly though, we do NOT use a public key encryption system for sharing the AES-256 key (note: AES-256 is NOT broken by a quantum computer, only the systems used to share the key) that secures the one time pad material while it is being transmitted, we instead share the key optically in a QR code that the recipient scans with their phone's camera.  In addition to our encryption, AirDrop adds yet another layer of encryption, albeit a traditional public key based one. 

This means to compromise the exchange an attacker would have to do all of the below, which is impossible: 

A) physically follow you to the meeting with the other user you are sharing one time pad material with

B) know in advance that they should bring Bluetooth interception gear with them

C) be close enough to intercept the Bluetooth signal

D) be close enough to clearly photograph the screen sharing the QR code (which you could easily hide so that only the other user's camera can see it)

E) successfully intercept the entire Bluetooth transmission 

F) break the traditional encryption offered by AirDrop (not possible without a quantum computer!)

G) do all of the above without anyone noticing, thereby leaving you believing the pad material is still secure

The source code that implements our end-to-end encrypted messaging and that then sends the message to the server is available at: https://github.com/NumbersStationApp/Numbers-Station

This code covers both the end-to-end Quantum-Safe One Time Pad (QS-OTP) inner layer as well as the end-to-end middle layer of encryption implemented using Apple's Crypto Kit framework. The TLS v1.3 final layer, which is app-to-server, is implemented within iOS and therefore is not within our source code.

We'd be pleased to make the rest of the source code available for review by security researchers, media organizations, enterprise clients, etc. provided they agree to: 

• in the unlikely event they discover a security issue, they give us 30 days to release a new version of the app before going public with their discovery

• not release the source code outside of their organization, although small snippets may be made public as part of a public disclosure to demonstrate any issue found

• not use the source code in their own messaging application

Once we hit a critical mass of users, i.e. when a competitor would find it hard to just copy and use our code for their own competing app, then we will release the entire source code publicly. 

We recommend anyone interested in reviewing the app first start by looking at the compiled app itself since there is no attempt to obfuscate the code, so it should be easy to reverse engineer, and as our middle layer of encryption uses Apple's CryptoKit framework, calls to it will be readily identifiable.  Calls to external network resources are also easily identifiable therbey confirming that all data leaving the device is as expected. We think you're better off starting by reviewing what is actually available to users on the App Store than reviewing source code. Better to work with what is actually confirmed to being run on user's devices than source code that is rarely verified to be the same as the deployed binary anyway.

If you have technical questions we'd be happy to answer them, please contact us at  support@numbersstation.app.

Signature/Identity

Each Numbers Station address has a longterm Curve P-256 based signature/identity key that is used to digitally sign every sent message proving that it is from that address.  This public/private pair is created within the iOS device's Secure Enclave (via Apple's Crypto Kit) such that the private key never leaves the Secure Enclave and is not available to the operating system or to our app.  This is the ultimate in hardware security to ensure that no one can impersonate the sender but is also the reason why you cannot use the same account on multiple devices at the same time and why if you switch to a new device, everyone you message gets a warning about your identity key having changed and inviting them to reconfirm it with you. Security first is our approach.

Encryption/Key Exchange

There are three categories of Curve 25519 based public encryption keys for each user.

First there is a long-term default public encryption key stored on our server that is used when the sender's app cannot find one of the other two following categories of public keys to use.

Second there is the daily public encryption key that is refreshed every 24 hours and stored on our server. This key is used if the sending app has run out of ephemeral per message public keys.

Third there are two ephemeral per message public keys generated as each message is sent to a recipient that are included within the encrypted payload sent to the recipient directly.  Two are sent per message so that it would be rare for the sender to ever run out if actively conversing with the recipient, such that the daily or default keys are rarely used. When these ephemereal keys are used, which is almost all of the time, there is Perfect Forward Secrecy (PFS).  The newest, "freshest" key is always used first since in an active conversation, new fresh keys will continue to come in. All ephemeral keys expire within 24 hours if not used sooner.

The longterm default public key would only be used in the case where the recipient's device had not connected within the past 24 hours to provide a daily key AND when no ephemeral keys for that recipient are stored, likely since no prior communication had occurred with this specific recipient (i.e. very first message).

As the Secure Enclave does not support Curve 25519 based key generation and storage, all private keys are created and stored by the Numbers Station app.

Over the past few years, a number of exploits against mobile devices have relied on sending malicious data masquerading as an image to a victim via their messaging app.  The app then tries to decode the data as an image or attempts to resize it or does some sort of processing on it that triggers the vulnerable code in the image processing library (especially ImageIO).

The other main category of attack is sending the victim a link to a malicious web site, the messaging app then attempts to generate a preview link (without the user clicking on anything or even seeing the message!) which triggers function calls to WebKit thereby triggering an exploit.  To counter this second main threat, Numbers Station simply does not show any link previews.

The top threat currently of concern is if a user is NOT using our block or quarantine function for messages from unknown senders and is NOT blocking images (especially from unkown senders), malicious data masquerading as a HEIC image file that passes basic validation as a HEIC image is then decoded for display when the user views a conversation.  In this worst case scenario, unlike other messaging apps, our user would at least see that a new message had arrived in a new conversation. Viewing of a HEIC image triggers a function call within iOS to ImageIO to decode the image. ImageIO is a library that has had a rough history in terms of security issues (see https://googleprojectzero.blogspot.com/2020/04/fuzzing-imageio.html for more info on ImageIO). You'll often see in Apple security updates references to issues in ImageIO that have been patched (e.g. iOS 16.5 fixes an issue within ImageIO where there was the risk of arbitray code execution due to a buffer overflow https://support.apple.com/en-ca/HT213757).

Based on the above and the expected volume of files being mostly supposed images, we are prioritizing automated assessment of submitted data that is claiming to be an image. Everything else is manually assessed, such as PDF file sent to a user.

We pull submitted files, which are stored in an encrypted state, from our server using a dedicated laptop that is not used for any other purpose and then transfer the files via USB key to an otherwise airgapped laptop that we use solely for automated assessment.  This second laptop contains the private key required to decrypt the submitted data. At this point automated and manual analysis can occur.  Anything deemed not malicious is immediately deleted.