Part 1 is here: https://interruptlabs.ca/2022/07/29/I-m-Building-a-Self-Dest...

First, a specification for Maximum Voltage does not imply that it is also a contract for the Minimum Voltage Required to Destroy Device. And even if it were, you're still missing a spec for the current/power required to destroy the device. I would guess that the maximum voltage spec is based on the forward/reverse voltages of the body diode (hence the alternative -0.6v rating that would actually be easier to hit with no voltage doubler), rather than say gate punch through. Thus you're going to need a lot of energy to create the heat required to cook the silicon. Your chip may desolder itself from the board before it's been appreciably damaged.

But really, apart from the novelty, why attempt to destroy the chip in the first place? Encrypt the bulk flash memory, store the key in supercap backed SRAM, and then zero out and short the RAM when triggered. Then you'd have a reusable device in case of inadvertent triggering. You could even load it with a key from a trusted host computer (stored on the computer or derived from passphrase), gain safety for transporting your files while walking around and plugging in to less trusted computers), and then if you did accidentally trigger the device, simply reload the key afterwards when you got back to the trusted computer and not have to rewrite the flash. The utility of such reloading functionality would depend on your threat model, but could be very useful for a lot of people. Perhaps border crossings.

Since we're on the topic of bespoke crypto ideas, I've often mused about the possibility of a probabilistic KDF that would take a lengthy amount of time to derive the key, and/or be resilient to typos in the passphrase. Rather than doing a fixed number of rounds that take a few seconds to derive the key xor failure, there would be additional random bits that had to be derived via hash collision finding, stretching out the time. Such a thing could be resistant to typos or omissions of words in the passphrase, with the result that such errors would increase the time even more. Thus, until the KDF reported success, an attacker would not know whether you gave them the correct passphrase and they just need more time, or whether you were stalling.

Very interesting project, but I must admit I raised an eyebrow when the author said it was nice to use an ATtiny25(8-bit core) instead of the usual (32-bit) ARM micro controllers, then proceeded to use float in the code all over the place.

Since the AVR core has zero support for floats, that will mean it's all software emulation, bloating the code fantastically. I guess (and understand) it doesn't matter as long as the application fits and does what it's supposed to do, it was just ... extremely jarring.

This, for example:

    void set_pwm(float voltage) {
       OCR1A = ( voltage / 5 )* 0x400;
    }

The above generates 100+ instructions, without inlining the floating-point operations that are left as library calls (see [1] for a Compiler Explorer view).

Normally you'd expect code like that to use 8-bit variables wherever possible, and perhaps stretching to 16-bit numbers when more range is needed such as when computing the above PWM value.

[1]: https://godbolt.org/z/PvP5jsrnG

I think Naomi Wu's Big Red Switch Box is better. With a seemingly dead drive, an adversary may still try to rubber-hose an access method out of you on the assumption that there's some special sequence to required to gain access. A simply dead drive is suspect, especially given the prevalence of ideas like port knocking, etc.

With the Big Red Switch that throws sparks and emits smoke, the adversary may still inflict punishment on you, but they have no illusions that they can torture you into revealing "the secret way to access it".

Build in 2 flashdrives - don't lick your fingers, you see the regular drive with innocuous crap. Lick, and you see the real deal. Better, have a magnetic key or transponder that unlocks the real drive (and hides the innocuous one.) Doesn't draw the attention that a mysteriously not working drive does.

How about authenticating with an accelerometer rather than through skin conductivity? To unlock your USB device, or to avoid the self-destruct, you would wave it, tap it, spin it, or rotate it in a specific way before plugging it in.

Accelerometers are widely used by smartphones so I assume that the ICs are common and inexpensive (at least if bought in volume). A tiny battery would be needed as well.

Carrying the idea even further, maybe you could even do key entry this way. Imagine that the USB device stores encrypted data and you enter a short decryption key by tapping out a particular bit of music before plugging it in.

To get even fancier, maybe you can enter a hexadecimal key (0123456789ABCDEF) through various motions. For example, spinning the USB clockwise on your desk is a 0, flipping it from horizontal to vertical is a 1, waving it through a figure eight loop is an 8, rolling it along the long axis is a B, etc.

Does this actually prevent forensics from finding any data?

I don't like how it's engineered: the uC is completely overkill as the high voltage could be generated by a single transistor switcher that charges a capacitor, not unlike those "Joule thief" circuits used to light higher voltage leds with small batteries. The mosfet would then just switch that voltage, which could well be tens of volts or more. However, the working principle assumes the user's skin would be normally high, which is not the case if he/she is sweating since sweat would lower the skin resistance even more so because of sweat higher sodium content.

I have the flash drive pictured in the first image of Part 1, and I'd say it, almost self-destructs on its own purely from overheating. If you plug it in or read it, it gets hot, and if you write to it it gets rapidly hotter. I've never tried writing gigabytes, but some people online say it gets so hot the drive slows down and eventually starts throwing errors instead of writing data, until it gets a chance to cool down.

I don't think this is a good way to initiate the destruction.

Washing hands, sweating, condensation from beverages, etc. could easily trigger this.

I'm not convinced that destroying the flash chip makes it more secure. Erasing the chip should be secure and fast enough. Damaging it with overvoltage might leave the data recoverable.

How does it differentiate between licked fingers and sweaty hands?

Why use a micro at all? You could have implemented the entire circuit with a couple extra discrete components to reduce complexity.

Better off with a strong shallow field, high intensity rare earth magnet attenuated by a removable stainless steel shield that erases the data only if the USB key is removed from a holster incorrectly, thereby removing the stainless steel shield.