The Real Cost of DTLS on a Coin Cell

The Real Cost of DTLS on a Coin Cell

Ada re-derives this chapter’s own numbers step by step, at full precision

foundations
math-foundations
calculation-audit
coap
Ada ADA · CALCULATION AUDIT

The Real Cost of DTLS on a Coin Cell

The chapter’s hospital-wearable example adds DTLS to a CoAP link and reports it costs only about 15% more energy — dropping battery life from 550 to 480 days — even though it grows every message from 85 to 114 bytes. A 34% larger message that costs only 15% more energy is a paradox worth checking on the 2,376 J coin cell. This audit rebuilds the budget to find the real cost of DTLS on a coin cell.

Companion to the chapter CoAP Security and Applications — every number here comes from that chapter.

Try

The chapter’s hospital-wearable example adds DTLS to a CoAP link and reports it costs only about 15% more energy — dropping battery life from 550 to 480 days — even though it grows every message from 85 to 114 bytes . Calculate this case.

Observe

This audit rebuilds the budget to find the real cost of DTLS on a coin cell. Check shows this.

Explain

The audit resolves the apparent paradox: the message grows 34% in bytes but only 14.7% in energy because radio time is not the whole per-message cost -- the app-layer option was already paying for AES, and the one-time handshake amortizes to 0.125 bytes each. The design meaning is that transport-layer encryption of the entire message, metadata included, costs about two months of battery life in this ledger. Check confirms it.

See the relationship before changing it

The figure reads from left to right. The blue input is secure energy per message. The middle card names the page’s rule. The green output is ideal battery life. The arrow matters: change the input, apply the rule once, then read the result with its unit.

Secure Energy Per Message changes ideal battery life A three-part teaching diagram connects secure energy per message, the rule life = 2,376 J / (2,880 x mJ/message / 1000), and ideal battery life. INPUT Secure energy per message APPLY THE RULE predict calculate check units OUTPUT RESULT
Walk the arrow. A small per-message increase repeats 2,880 times each day.

Derive the baseline in four named moves

  1. 1

    Name the input. The chapter baseline is 1.72 mJ.

  2. 2

    Name the relationship. life = 2,376 J / (2,880 x mJ/message / 1000)

  3. 3

    Substitute with units. 2,376 / (2,880 x 1.72 / 1000) = 479.7 days

  4. 4

    Read the result. Keep the unit beside the value, then use the result only inside the technical boundary below.

Predict, then change secure energy per message

Try Predict how ideal battery life responds when secure energy per message moves. Calculate secure energy per message; compare ideal battery life with that prediction.

1.72 mJ
Chapter baseline
Ideal battery life

Observe Return to 1.72 mJ. Recheck ideal battery life with secure energy per message at its chapter value.

Explain A small per-message increase repeats 2,880 times each day.

Check yourself

What should you do before trusting a moved-slider result?
Answer: Predict its direction, apply the displayed relationship, keep the units, and compare the reset value with the chapter’s worked baseline.
What does this small model leave out?
Answer: Only secure energy per message moves here. The ideal battery life calculation excludes field effects listed below.

Technical boundaries

Excluded from the “The Real Cost of DTLS on a Coin Cell” calculation are handshake retries, session resumption failures, radio tail energy, cryptographic hardware variance, battery ageing, or application traffic changes; “The Real Cost of DTLS on a Coin Cell” therefore reports only its named fixtures.

Ada: The hospital wearable example above claims DTLS adds only about 15% energy – dropping battery life from 550 to 480 days – even though it grows every message from 85 to 114 bytes. A 34% larger message that costs only 15% more energy deserves a check, so let me rebuild the budget from the CR2032 spec and the per-message figures the section states.

  • Coin-cell energy: 0.22 Ah x 3 V x 3600 s = 2376 J – the chapter’s 2,376 J.
  • Handshake amortization: 120 + 140 + 40 + 60 = 360 handshake bytes spread over 2880 messages/day is 360 / 2880 = 0.125 bytes per message – negligible.
  • Per-message size: 13 (DTLS record) + 85 (encrypted CoAP) + 16 (MAC) = 114 bytes versus 85 bytes plain, a 34% growth.
  • Application-layer AES daily energy: 2880 x 1.5 mJ = 4320 mJ = 4.32 J/day, giving 2376 / 4.32 = 550.0 days.
  • DTLS-PSK daily energy: 2880 x 1.72 mJ = 4953.6 mJ = 4.9536 J/day, giving 2376 / 4.9536 = 479.7 days, the chapter’s ~480 days.
  • Energy overhead: 4.9536 / 4.32 = 1.14667, i.e. +14.7% (the chapter’s “15% more energy”).

The audit resolves the apparent paradox: the message grows 34% in bytes but only 14.7% in energy because radio time is not the whole per-message cost – the app-layer option was already paying for AES, and the one-time handshake amortizes to 0.125 bytes each. The design meaning is that transport-layer encryption of the entire message, metadata included, costs about two months of a 550-day battery, which is why the honest release record prices HIPAA-grade confidentiality at “about 15% energy and 70 fewer days,” not “free.”

Every number above is taken from the chapter’s own material and re-derived step by step.