Project

General

Profile

Actions

Feature #21407

closed

Provide a t3lib library for symmetric encryption

Added by Marcus Krause about 15 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2009-10-30
Due date:
% Done:

0%

Estimated time:
PHP Version:
4.3
Tags:
Complexity:
Sprint Focus:

Description

TYPO3 lacks general encryption support.
This RFC is about an easy to use t3lib library that provides symmetric encryption (!=asymmetric encryption/public key-private key).

The attached library is currently at proof of concept state; so please don't use it inproduction environments and expect API to change.

The library is a wrapper on mcrypt PHP extension.

The easies use case is to instanicate the t3lib library and use methods encrypt()/decrypt() with a given key (e.g. TYPO3's encryption key) and message to be encrypted.
Depending on the used encryption mode, you need to retrieve an initialisation vector (IV) using getCurrentIV() to be able to decrypt an encrypted message.

The IV doesn't need to be secret (so please don't use TYPO3's encryption key for it) and could easily transmitted/displayed together with an encrypted message.

Please test, comment and send suggestions.

What needs to be improved: * more testcases for different ciphers/modes * determine proper default settings (ciphers/modes) * use exceptions instead of null/false method results * ...

(issue imported from #M12402)


Files

Actions #1

Updated by Marcus Krause about 15 years ago

The t3lib library (class.t3lib_symencryption.php) is intented to be located in a newly to be created path t3lib/security.

Actions #2

Updated by Andreas Wolf almost 13 years ago

  • Target version deleted (0)

After playing a bit with mcrypt in the last days, I see different problems with it - though most of them can be circumvented for our usage. I would also go for a simpler user interface in an encryption library - developers should by default not have to care about setting the encryption algorithm etc. manually when decrypting existing stuff. I therefore propose to store all this information together with the encrypted strings. This seems to be common practice for the IV nonetheless, unless it is derived from some static data. It's also how we store the salt for hashed passwords.

As we experienced some trouble with the different password formats in our database in the past, I would also want to store the used encryption algorithm and mode (CBC, EBC etc.) together with the password, all parts separated by "$". One possible example would be: $blowfish$cbc$someIV$someEncryptedString

Decrypting would be really easy, you just have to set the correct key and throw an encrypted string at the decryption method - it would figure out algorithm, mode and IV (if set) from the string.

Actions #3

Updated by Benni Mack almost 10 years ago

Hey Marcus, nowadays we could easily add a composer package / 3rd-party-library.

Is this sufficient?

Actions #4

Updated by Susanne Moog over 9 years ago

  • Status changed from New to Needs Feedback

changed status according to comment #3

Actions #5

Updated by Alexander Opitz about 9 years ago

  • Status changed from Needs Feedback to Closed

No feedback within the last 90 days => closing this issue.

If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.

Actions

Also available in: Atom PDF