# Tag: security

Can I have a secret?
Can I tell you a secret?
Can I tell you a secret when we know there is someone snooping around?

I’d like to share this graphical explanation of the Diffie-Hellman key exchange principle without going into the details about the math behind it. It uses physical abstractions as padlocks, keys, and treasure chests. The goal of the key exchange is to allow two parties to establish a shared secret key over an insecure communication channel.

Alice and Bob, a complicated couple, would like to talk through an insecure channel.

## Step by step

1. Alice has the padlocks A and C, two keys C and one key A. Bob has the padlock B, key B, and the letter he wants to send to Alice through the insecure channel.
2. Alice puts the padlock and key C in the chest.
3. Alice locks the treasure chest using the padlock A, and sends to Bob.
4. Bob receives the chest. He can’t open it because he doesn’t have the key A. He puts one more lock, the padlock B, in the treasure chest and send it back to Alice. Alice also can’t open the chest, as she doesn’t have the key B.
5. But Alice does have the key A, which she uses to remove the padlock A from the chest and send it back to Bob.
6. Bob now receives a chest which he can open. He opens it and receive the padlock and key C. At this point the key exchange is done. He can either keep the chest and padlock C to send something to Alice, or he can use the same key exchange technique from steps 1 to 6 to send the padlock C back to Alice.
7. Bob decides to send Alice a letter using the padlock C. He puts the letter in the chest.
8. Bob locks the chest using the padlock C, send it to Alice. He keeps key C.
9. Alice received the letter and now they both have the key C.

## Notice

• Alice’s key A never left her inventory. Bob’s key B never left his inventory.
• Neither Alice nor Bob really knows who is in the other side. In this example they just trust in each other. Authentication is very important but is not handled in this example.
• At every transference a different padlocks (or a combination of padlocks) was used.

## A tiny bit of math

Let’s (very) informally define computationally efficient as a computation that someone is willing to wait and pay.

The abstraction here is that a chest with padlock is easy to lock/unlock when you have the correct key but hard to be unlocked otherwise. To use this technique with data, we need a mathematical function f that is:

• Easy to lock: it is computationally efficient to apply f(m,k) over a message m and a key k
• Easy to unlock: there is a computationally efficient inverse function f’ such that m = f'(f(m,k),k)
• Hard to break: it is not computationally efficient to find m or k knowing only f and f(m,k)

If you want to know more about these functions, take a look in the original article “New directions in cryptography” by Diffie, W. and Hellman, M. in 1976.

How to reproduce:

1. An application with a bunch of EditText.
2. Go to setup and change the locale of Android.
3. Back to the application.

Expected behavior

Locale changed and input values are the same.

Observed behavior

Input values from the last EditText is copied to all others. Even if it’s a password sensitive EditText.

```<?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="fill_parent" android:layout_height="fill_parent" android:orientation="vertical"> <EditText android:layout_height="wrap_content" android:layout_width="wrap_content" /> <EditText android:layout_height="wrap_content" android:layout_width="wrap_content" /> <EditText android:layout_height="wrap_content" android:layout_width="wrap_content" android:password="true"> </EditText> </LinearLayout>```

Variations:
1. Same behavior in a EditText with default TransformationMethod.
2. DatePicker and TimePicker have strange behaviors too. They lose what I was writing on them but they don’t copy content.
3. The behavior was first noticed on the internal component NumberPicker and after that tested on EditText.

Malicious usage scenario:
Someone is filling user/password form in a application, go to the bathroom and forget the phone over a table. Other one gets it, use the flaw and read the user secret password.

Possible cause:
When locale is changed and you enter again in a application, it has to be destroyed and created but somehow old values are filled again. Probably the routine that cares about writing i18n details such orientation (left-to-right/right-to-left) has a bug.

Affected versions:

• Android 1.6, tested on 2 devices and emulator.
• Android 2.0, tested on device.
• Certainly all versions between them and I guess 2.1 also.

Thanks to Diego Almeida who first noticed that behavior on NumberPicker. :]

Update: I filled a issue on Android project. Seems that they know about that behavior and the workaround is to put android:id properties on elements. The problem persists on NumberPicker even when using android:id on them! In fact, is my real problem.