|
|
@@ -53,6 +53,14 @@ Messages are encrypted using 256 bit AES in GCM mode. Each message gets its own
|
|
|
random IV. On reception the tag generated by GCM is verified and the message
|
|
|
discarded if it doesn't match.
|
|
|
|
|
|
+A simple mechanism to prevent replay attacks is implemented. Each time the app
|
|
|
+enters an encrypted chat an ID is generated by SHA-256 hashing the Flipper's
|
|
|
+name with the current system ticks. Each message is prefixed with this ID and a
|
|
|
+counter. A receiving Flipper will check if the counter on a received message is
|
|
|
+higher than the last counter received with this ID. If it is not, the message
|
|
|
+is discarded and an error is displayed. ID and counter are included in the GCM
|
|
|
+tag's computation and are therefore authenticated with the used key.
|
|
|
+
|
|
|
If a password is used, the key for the encryption is derived from the password
|
|
|
by applying SHA-256 to the password once.
|
|
|
|
|
|
@@ -68,11 +76,6 @@ The same key is used for all messages. This means that no forward-secrecy is
|
|
|
provided. If the key is compromised, all previous messages are compromised as
|
|
|
well.
|
|
|
|
|
|
-Currently, no protection against replay attacks is implemented. This means that
|
|
|
-someone without the key can capture an encrypted message and resend it as many
|
|
|
-times as they want. A receiving flipper will display the replayed message as if
|
|
|
-it were new.
|
|
|
-
|
|
|
If you do not understand the implications of the caveats mentioned here, do not
|
|
|
expect to gain any security by using encryption.
|
|
|
|