shred is not made for modern HDDs, or SSDs. It's design is based on a paper from times long long past, when hard drives didn't contain their own controllers. Whether or not the design ideas underlying shred hence still apply to modern hard drives or not is subject to ongoing debate. I'll go with "personally, I don't think so".
Anyways, your best bet is cryptography on an SSD, and using your file system's discard ability together with regular re-encryption.
At first, using an SSD seems counter-intuitive: SSDs are by nature "copy on write" under the hood: the memory blocks presented to you are mapped to arbitrarily ordered blocks on the physical flash memory. When you want to modify a byte on a block, you need to erase the whole block (i.e., set it to 0 completely) and then only flip the right bits. This erasing is a process that wears out the flash cells, so instead of erasing the same physical blocks over and over, every time you modify a block, its modified contents are written to a different, already erased, block, and the old block is enqueued for erasing. The SSD does this all internally, the host doesn't notice anything about it.
Now, there's one way to interact with that: you can TRIM / discard a logical block, and that will simply mark the underlying physical block as unused and enqueue it for erasing; the logical block gets marked as backed by "nulls", and will only get assigned to an erased block once it's getting written to (usually).
Now, LUKS / dm-crypt on Linux is clever. When your file system on an encrypted volume knows a logical block as "no longer used by a file", it hands down a "discard this block" down to the block device – the encrypted device itself then can hand this info one further down to the SSD.
So, you have a mechanism for this that makes it trivial for the encryption layer to quickly re-encrypt only the used parts of the block device (and not the full disk including the data belonging to blocks of deleted files).
Neat. So you delete files, that discards the blocks these use, the ciphertext of which then becomes impossible to read for anyone, but to make things even more secure, you afterwards tell luks to re-encrypt the whole disk, which gives you a new key, with which the old data in the "technically still potentially somewhere inside the SSD, but inaccessible from the computer" can't be decrypted as the key does no longer exist, and in the absence of a key, properly encrypted data is equally likely every possible unencrypted data. So, even when your luks encryption passphrase gets cracked at some point and the then-current (very long) master encryption key recovered, that wouldn't help an attacker recover that data.
tmpfsand turning off swap entirely?