If you have relatively few pieces of text (for example, around N = 1000 pieces of text), and it's OK for your system to occasionally give a "false positive",
you might consider using a truncated hash.
Alice has a database of around N = 1000 sensitive documents on a secured computer that is normally turned off.
Alice is willing to have a false positive error rate of e = 1/100.
Before that computer is turned off, Alice uses that computer with any cryptographically secure hash function (SHA-3, BLAKE, Argon2, etc.) to hash each document (perhaps using the same publicly-published salt value for all 1000), then
truncate the hash to log2( N/e ) = log2( 1000 * 100 ) = around 17 bits,
then copy those 17-bit truncated hashes to a USB stick and then puts that USB stick in a separate server that Alice keeps turned on and allows the public to access.
Later, Bob has some allegedly sensitive document in hand and wonders if it is the same as one of those previous documents.
So Bob hashes the document in hand, and compare its 17-bit truncated hash to each of the roughly 1000 hash values on the server (possibly using a relatively quick binary search).
The result will always be one of:
- No match: No, that document is definitely not on the secured computer
- Match: That document might be on the secured computer.
This algorithm is fairly resistant to the "learn the remaining information attack",
because there are so many false positives it's difficult for an attacker to figure out which one is the actual remaining information.
If someone randomly generates a bunch of documents (none of which exactly match any of the sensitive documents), I expect about 1% of those documents to have a coincidentally-matching hash value, giving the "false positive" of "That document might be on the secured computer".
The remaining 99% of those documents give the correct "No, that document is definitely not on the secured computer".