Half the time when people say they're using telnet (including in this thread) they're really just using the client as a TCP client, not doing anything with the Telnet protocol.
No one is stopping you from using the telnet client. And really you should just use netcat
There's one thing I haven't figured out with netcat- how do you know it connected? (I just looked it up, after many years: the -v flag. Which makes sense because netcat is supposed to be "transparent").
To maximize device performance when wiping a drive to use for something else, I use nvme format with --ses=1.
Which in theory should free all of the blocks on the flash.
Really hard to find good documentation on this stuff. Doesn't help that 95% of internet articles just say "overwrite with zeroes" which is useless advice
What's the difference between this and sanitize? Should we be doing both?
[edit] sanitize runs on the controller level while format works on the namespace level. So I suppose formatting won't touch any pages not allocated to a namespace.
I wish there was _any_ way to find out which NVME controllers supported which operation before you buy them!
Anything that works at the logical block interface will not usefully wipe the device. SES 1 will physically hit every erase block on the device with 20V to blow it away. This happens suspiciously quickly (< 60 seconds typically) but that's just because flash is great.
It consumes one of the erase cycles, of which a device has a few hundred or maybe a few thousand over its lifetime. It's not something you'd want to do frequently.
This is broadly true of cheap thumb drives, but not true of all USB flash drives. The larger ones generally do support secure erase. E.g. the Crucial X6. I don't know if these use secret vendor commands, or if they use the standard SCSI "sanitize" command.
That doesn't work on any* NAND flash device, be it a flash drive, NVME, SATA, whatever.
The block device you see is an abstraction provided by the SSD controller. In reality, the flash capacity is larger. Pages are swapped out for wear leveling. If a block goes bad, it'll be taken out of commission, and your data may hide in there.
All of this happens on the SSD controller. The kernel doesn't know. You have no way to directly erase or modify specific blocks.
*Okay, there are raw NAND flash chips without controllers, but that is not you're working with when you have a SSD or flash drive. If you do have a raw flash chip, you can more directly control flash contents.
This is what `shred` and other secure wipes do. There is some concern over data stored in sections which the firmware has swapped out and made inaccessible. But if this is a concern to you, then you should be using full disk encryption anyway which makes all of this a non issue.
Don't you think it's time to update it, given you start by saying that "If someone, while trying to sell you some high security mechanical system, told you that the system had remained unbreached for the last 20 years you would take that as a compelling argument"?
Because you're clearly presenting it as a defense of PGP on a thread from a presentation clearly delineating breaks in it using exactly the kind of complexity that the article you're responding to predicts would cause it to break.
The mechanical analogy is particularly interesting here because at least one of the claimed vulnerabilities involves tricking the victim into decrypting an encrypted message for the attacker and then sending it to them. If someone can be tricked into opening a safe to let the burgler rummage around inside then few would consider that a failure of the safe technology. I mean there is still a problem there but it is a different one.
I think this supports my contention that we spend much too much time quibbling about cryptographic trivialities when it comes to end to end encrypted messaging. We should spend more time on the usability of such systems.
The constraint that you have implicitly applied to cryptosystems forecloses on using GPG as a base layer in other computing systems; in your view, GPG is a "safe", which can only be opened by the owner of the contents to retrieve and remove those contents.
reply