MediaWiki extensions manual
Release status: beta
Implementation Hook , Special page
Description Page level encryption based on defuse/php-encryption and OOUI
Author(s) (thomas-topway-ittalk)
Latest version 1.0 (2023-06-15)
Compatibility policy Master maintains backward compatibility.
MediaWiki 1.35+
License GNU General Public License 2.0 or later
  • pageencryption-cancreateencryption
Quarterly downloads 3 (Ranked 146th)
Translate the PageEncryption extension if it is available at translatewiki.net

PageEncryption implements symmetric, page level encryption based on the php-encryption library. It includes a special page where to manage disposable access keys to grant external users one-time access to confidential data, and it works with WikiEditor in a transparent way (with VisualEditor is not yet guaranteed to work, see #Known issues section) for the Encrypted: namespace.

Installation edit

  • Download and place the file(s) in a directory called PageEncryption in your extensions/ folder.
  • Add the following code at the bottom of your LocalSettings.php
<!-- place after the registration of other extensions!! -->
wfLoadExtension( 'PageEncryption' );
  • Run php maintenance/update.php (this will create the necessary database tables that this extension needs)
  • Run composer update --no-dev in the extension's folder, to install the required PHP libraries
  •   Done – Navigate to Special:Version on your wiki to verify that the extension is successfully installed.

  Warning: PageEncryption does not perform client-side E2E encryption and therefore assumes that you trust the system administrator or the wiki is self hosted. Don't use this extension if you cannot check the integrity of the extension server-side, or the system administrator isn't legally bound not to tamper with it!

Features edit

PageEncryption enables an encrypted namespace (Encrypted:) where authorized users (users with right pageencryption-cancreateencryption, by default set to all registered users) can create/edit protected articles.

The extension works in a transparent way, first requiring to set a global password to lock a password-protected key stored on the server, and then setting a cookie with the user-key by which to encrypt/decrypt the articles in the relevant namespace.

The password and the user-key are never stored on the server and the symmetric key can only be used in conjunction with the user-key, so there is no way for system administrators (unless the extension itself has not been hacked before you set the key) to access your confidential articles/data. To learn more how it works take a look to the following: Encrypting account data with the user's login password.

PageEncryption is therefore an optimal solution when you agree with systems administrators (or the wiki is self-hosted) to take all the possible measures to protect your data, and you want to safeguard them from possible attackers.

Besides the editor-relative global symmetric key, PageEncryption also allows to set disposable access-codes to provide external visitors with a secret code or url through which to access confidential data. The secret code and url can be used only once and again they are not stored on the server. You can use them to grant a single access to the recipient of sensitive data ensuring that nobody else will get access to them: of course in this case it is the editor responsibility to provide the secret key or url only through trusted channels. (currently there isn't yet an interface to enter the secret code, although this is the most secure method, because it allows to send the url of the document and the code through separate channels ‐ so please rely on the secret-url until the first stable release)

Still in the first stable release of the extension, PageEncryption is planned to feature an asymmetric mode as well, by which users registered on the wiki can access confidential articles/pages an arbitrary number of times (technically, as it is known, the extension will create a private/public key pair for registered users and then will encrypt a given page revision using their public key).

Also note that all encrypted versions of an article/page are relative to a given revision, therefore external users (or registered users with public key) will be able to access only the specific revision encrypted using the key which is then given to them, therefore as one might expect the method doesn't grant access to future revisions of the same article/page.

Register user-password edit

In order to register a global symmetric key, just go in the Encrypted: namespace, and create/edit an article (you must be the article unique editor in order for this to work). A popup appears and you can set your global password.



As mentioned, the global password, used to create an userkey only stored client-side, is never stored on the server.

(when you logout or the cookie is deleted, the global password must be re-entered again, in order to create the same user-key to encrypt/decrypt pages/articles, however note that if either the password or the protected-key (registered on the server) are lost, encrypted pages/articles cannot be recovered. For this reason the first stable release will also include a step where users can save the created protected-key locally).

Encrypted/decrypted articles edit

As long as you are the editor of a protected article, you can read/edit it seamlessly.


including the history


On the other side, this is how the article appears when accessed from unauthorized users (including wiki administrators/sysops)  



Manage access keys edit

For each protected article/page of which you are the editor, you can create an arbitrary number of disposable codes by which to grant to external visitors one-time access to them, also setting an expiration date for the access code/secret url. Conversely to the global password, the generated secret key is stored server-side in an encrypted format (although this might change in future versions of the extension) so you can retrieve them easily (through your global password) at a later time, without prejudice to safety.



Once the code/secret url is generated, you can provide it to your recipient through a secure channel (for instance by an encrypted chat message, sms, or secure email message) and the extension will record access time and other access-related information, if enabled.

How it works edit

The extension redefines the RevisionStore and RevisionLookup services, and manipulates (i.e. encrypts/decrypts) the RevisionRecord as soon as it is retrieved from the database. Cache is disabled for the Encrypted namespace, and makeAutoSummary on Manual:Hooks/MultiContentSave is disabled as well. The extension does not manipulate EditPage through Manual:Hooks/AlternateEdit as one might expect in similar cases. (thanks to the mocked-up RevisionRecord handled at a lower level).

Known issues edit

(for professional support please use this form – an Extension:CIForms's form)

Road-map edit

  • simple form/UI by which to enter an access code (instead than just using the secret url)
  • asymmetric encryption for registered users
  • encrypt/decrypt uploaded images seamlessly

See also edit