5 ms·
IIRC earlier versions of bitlocker would rely upon SSD firmware implementations for drive encryption. They stopped doing that when it was revealed many of these
by yomlica8 3y ago
IIRC earlier versions of bitlocker would rely upon SSD firmware implementations for drive encryption. They stopped doing that when it was revealed many of these hardware encryption systems in common drives didn't actually work.
- blibble 3y agovoid encryptSector(struct context *c, long sector_no, unsigned char *data, size_t data_len) { // TODO }
- yomlica8 3y agoThis is also something to keep in mind when resale of SSDs is discussed and people recommend using the secure erase function of the SSD!
- dylan604 3y agoIt's only securely erased after I've put about six 5/8" holes with my drill in it
- vxNsr 3y agoYup, when I was working desktop support a few years ago my manager told me to just format the drive and send it back to dell at the end of the lease, they’d secure erase it anyway and the data was safe, I never trusted that and used dd to overwrite every bit of the ssd twice with junk data, I’m sure it decreased the longevity of the drive but wasn’t my problem and it felt cool to be the only desktop support guy who knew any Linux.
- heavenlyblue 3y agoSSD wear leveling mechanism would create new writes into different physical sectors so it was highly probable you were not in fct overwriting at least a proportion of the data
- blibble 3y agoI can imagine the wear levelling function on some SSDs looks pretty similar to the encryptSector function
- veave 3y agoWasn't it tremendously naive of Microsoft to trust that SSDs did encryption correctly? So naive that it borders incompetence and/or malice?