Chapter 22. The Broken Cloud Logic

Part 3: The Struggle with Tuya Encryption

As I mentioned in the last chapter, I needed to build my own “Zoom connection” to remotely monitor and control the noisy classroom.

But how?

My programming knowledge went back to a one-year university course in 1992 — and even then, I spent less than six hours on actual computers. Machines were rare and valuable back then, even in top universities.

So I started from almost zero.

Fortunately, ChatGPT existed.

I fed the pile of code files written by the freelancer into ChatGPT, one by one, and asked it to explain what they did. Slowly, I began to understand the core logic of the system.

Then came the long nights and weekends.

Reading.
Testing.
Breaking.
Fixing.
Breaking something else.

The process was painfully slow.

Partly because I lacked formal software training. Partly because early versions of ChatGPT had a habit of “forgetting” things.

More than once, we fixed one problem… only to accidentally bring back another one we had already solved a week earlier.

You might be thinking:

Hang on. Didn’t you just want the lights to switch on when someone is around, and the gate to open when a customer arrives? How hard can that be?

In concept, you are absolutely right.

It is simple.

But making something feel simple for the user often requires a frightening amount of invisible work behind the scenes.

Take a very basic task: checking whether the kitchen light is on.

You can’t just shout into the open world:

“Hello, smart switch number 123, are you on?”

That would be madness — although emotionally, I was close to trying it.

In programming, the usual method is to make an API call. Think of it like sending a postcard:

1. You need the correct postal address — the Tuya server for the device.
2. You need to encrypt the message so strangers cannot read it.
3. The other side must know how to decrypt it.
4. You need a return address, so the reply knows where to go.

That is the friendly explanation.

The reality was far less friendly.

I struggled from the beginning because I had almost no experience with APIs. Once I finally grasped the rough idea, I hit the next wall: encryption.

To encrypt a message, you need a key. But in Tuya’s system, you need to request a temporary key each time — and the temporary key itself is encrypted.

So before you can encrypt your message, you must first decrypt the key.

Tuya’s documentation did not explain everything clearly. During testing, I found what looked like a contradiction. The encrypted key appeared to be either a 32-byte plain text or a 16-byte HEX string. But AES-128 encryption only accepts 16-byte keys.

Naturally, I tried using the 16-byte HEX string to decrypt the encrypted key.

The result was a 64-byte string — far too long to use as an AES-128 key.

So I tried AES-256 next.

Tuya’s response was not encouraging:

request api failed: param is illegal

Very polite. Completely useless.

I went to the Tuya Developer Forum and found others discussing the same issue. One developer had worked out that the encrypted key must be treated as plain text, but it was still twice as long as AES-128 expected.

Some suggested using the first 16 bytes.
Others suggested using the middle 16 bytes.

Tuya’s documentation, naturally, mentioned none of this.

In the end, after countless rounds of trial and error, I found a combination that worked:

1. Use AES-256 to decrypt the encrypted key as a 32-byte plain text, using my Tuya API client secret as the key.
2. Convert the deciphered HEX string into a 16-byte plain text key.
3. Use that 16-byte key to decrypt the actual device message.

When it finally worked, I felt the kind of relief only a non-programmer can feel after spending days fighting invisible locks.

My messages could now travel securely to and from the classroom.

But one more problem remained.

I could manually read messages and send commands to the IoT devices — but how could I make them talk to each other automatically, without me sitting in the middle like an exhausted schoolteacher?

That became the next challenge.

Next Chapter: AWS — The IoT Commanding Centre

free to follow my BSS journey — a real, unfiltered account of building an independent self-storage business in the UK, one problem, mistake, and hard-won solution at a time.