By the way, dont ask "is it possible". Everything is technically possible, provided you have unlimited resources.
Instead, describe what you want to do (eg prevent everybody but you and those you trust from accessing your files) without talking about technical implementation (in this case, encryption). Solution for your problem as I understand it is: Change your host company to a company you trust. If you don't trust any company nor physical hosting providers (they can control your computers too, althrough it will require downtime probably), the only way is to build own DC (still technically possible but you probably do not want to have such an expensive solution provided you don't have very very very sensitive materials such as top secret government materials). The rule is "I control it physically, I have full access to it if I want". Yeah, you can encrypt everything but RAM and boot sector. But still, when booting, how would you give the computer its decryption key? Stored in boot sector? Host can copy it and decrypt your files just as your computer does. Enrypted with a password being entered during booting? Who would enter the password then? If a company technical, the host can decrypt your files just as your computer can. If you, they can add small keylogger between keyboard and computer and do the same process your computer does. I know I'm talking about extremes, I really cannot imagine a VPS provider nor physical servers hosting provider that read its customer's data, as long as it is big enough. Why? Imagine I can prove that Google technical noticed I have my credit card details in my Google Drive (no, I don't, but my ID card is there) and bought something without my authorization. Nice newspaper title can be "Google abuses your data". Google do not want such newspaper article, of course. As Brian said, this can make sense when you have separate file server and web server. Or in another cases, which may or may not be relevant to MediaWiki. Best, Martin Dne po 28. kvě 2018 16:30 uživatel Brian Wolff <[email protected]> napsal: > It is possible - You would probably want to implement your own > FileBackend subclass - > https://doc.wikimedia.org/mediawiki-core/master/php/classFileBackend.html > . I am not aware of anyone else doing something like this. > > However, conceptually you need to consider your threat model carefully > here. As with most "encryption at rest" schemes, the sticking point is > where is the key stored. To do something like this, you would probably > put your encryption key in LocalSettings.php (Even if you do something > more complex, MediaWiki would have to have access to the key at some > point in order to decrypt the files to send them to your users). If > you don't have control to the host, the attacker could just read the > key out of your LocalSettings.php (or in more complex schemes, PHP's > memory), and thus defeat the encryption. > > The type of system where this sort of thing makes more sense, is if > you are storing files on a different server then your main web server > (Say amazon S3 or whatever). If you don't trust the file server, but > do trust your web server, then encrypting the files could make sense > as long as the key stays only on the server you trust. > > -- > Brian > > On Mon, May 28, 2018 at 2:08 PM, Stephan Gambke <[email protected]> > wrote: > > To prevent unauthorized access I may have to ensure that uploaded files > are stored encrypted. Wiki pages themselves are less critical, and may > remain in clear text. > > The scenario is a relatively small wiki (30,000 pages, 10,000 files, but > only 27 users) on a virtual server where I have full remote root access. > The host of the virtual machine is not under my control. > > > > - Is there any obvious problem that makes this conceptionally impossible? > > - Is anybody already doing this or working in that direction? > > - What could be viable approaches and what limitations would there be? > > > > I know, it's a rather broad topic. Still, any pointers would be welcome. > > > > Cheers > > Stephan > > > > _______________________________________________ > > MediaWiki-l mailing list > > To unsubscribe, go to: > > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l > > _______________________________________________ > MediaWiki-l mailing list > To unsubscribe, go to: > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l > _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
