Hi!
I've prepared my plugins for the first publication.
You can (I hope) get .zip with all files by this link: https://drive.google.com/file/d/0BwmXNkLWgcmuZ1BSWThGek05ZDQ/view?usp=sharin...
It is my working version in which I added and translated comments. Respectively, it is made for Rcube v.1.1.3. In texts I kept some comments in Russian. Don't pay attention: always nearby there is their translation into English.
I think that this option will allow to understand better work of a plug-in and possibility of its use in other projects.
Soon I will begin work with the Rcube 1.2 version.
As as I understand, in this version essential changes for encryption of mail are made, I would be very grateful to receive recommendations about application of my algorithms in the new RCube version.
The README file contains more detailed comments to a plug-in.
Best regards, Vladimir Gorpenko, Moscow
On 01/09/2016 11:03 AM, Владимир Горпенко wrote:
Soon I will begin work with the Rcube 1.2 version.
As as I understand, in this version essential changes for encryption of mail are made, I would be very grateful to receive recommendations about application of my algorithms in the new RCube version.
Yes. In 1.2 you have all parts needed for encryption already implemented. The Enigma plugin which implements PGP is prepared to provide also S/MIME encryption in the future. So, the best would be to focus on integrating your code with Enigma.
It is to be decided if we want a separate interface to manage certificates or to store/display them on the same list with PGP keys. Anyway, some UI work will be needed.
The plugin code assumes certificates and keys can be handled in the same unified way, but I didn't yet try S/MIME much, so some modifications may be needed (to the key, subkey, userid, signature "interfaces").
Most important places to take a look:
- enigma_engine and enigma_ui - The engine will need some small changes
- enigma_driver_phpssl - S/MIME driver complete implementation (the is
the only place in enigma classes where openssl functions should be used)
- enigma_mime_message - Mail_mime wrapper where encrypted/signed
messages are created - needed code to build S/MIME messages.
------ Исходное сообщение ------ От: "A.L.E.C" alec@alec.pl Кому: dev@lists.roundcube.net Отправлено: 10.01.2016 13:03:12 Тема: Re: [RCD] S/MIME encryption and signing plugin
On 01/09/2016 11:03 AM, Владимир Горпенко wrote:
Soon I will begin work with the Rcube 1.2 version.
As as I understand, in this version essential changes for encryption of mail are made, I would be very grateful to receive recommendations about application of my algorithms in the new RCube version.
Yes. In 1.2 you have all parts needed for encryption already implemented. The Enigma plugin which implements PGP is prepared to provide also S/MIME encryption in the future. So, the best would be to focus on integrating your code with Enigma.
I don't know, whether it is correct to connect both ways of encryption in one plug-in. Solve it you. But I needed to receive the working plug-in in short terms. I am afraid if I built in my development into Enigma, we now just would agree.
Understand me correctly. I do my work and I need encryption of mail. Unfortunately, it appeared that the fastest way to receive it is to write myself. I wrote. Of course, it would be very good that the plugin worked with standard rcube versions. It would be useful also for me and other users.
But to deal with the Enigma as I dealt with some parts of rcube and to build in my development an Enigma are more than that I am able to afford. I very much respect work of those who does plug-ins for general use. But itself I can participate in this process only restrictedly.
I think, 90% of my texts are repeated that you already made for PGP encryption. If it is about sharing experience of transformation of the message from the S/MIME encryption form to decrypted and back, I am ready to make it and to offer code samples. Certainly, the same belongs and to signing of messages.
Also, if the rcube developers accept my changes in the text of the program or will offer similar, smime_crypto can be used by users of version 1.1.3 +. As I see, the line 1.1 continues to be supported and, therefore, changes can be made.
It is to be decided if we want a separate interface to manage certificates or to store/display them on the same list with PGP keys. Anyway, some UI work will be needed.
I think that management of certificates and keys has to be allocated in the separate module or management of certificates and keys has to provide many possible options. Different users can are need different options: storage on the LDAP server, in SQL base or is simple in files. Also management of certificates and keys can be transferred to users or is made the centralized. For example that option which I will do for myself, will be so specific that I won't even offer it to anybody.
But that option which I made now, has to be considered as the simple temporary option allowing to debug the main plug-in rather. Though it isn't excluded that to someone it can be sufficient.
UI, of course, should be done anyway. But at present I am able to do UI insufficiently.
The plugin code assumes certificates and keys can be handled in the same unified way, but I didn't yet try S/MIME much, so some modifications may be needed (to the key, subkey, userid, signature "interfaces").
It is just simple. There are only two types of data - the certificate and a private key. Formats of these data are standard and even not necessarily their nobility.)) There is one problem - safe storage of private keys. It can be solved differently. It is too the reason for allocation of management of certificates and keys in the separate module.
Most important places to take a look:
- enigma_engine and enigma_ui - The engine will need some small changes
- enigma_driver_phpssl - S/MIME driver complete implementation (the is
the only place in enigma classes where openssl functions should be used)
- enigma_mime_message - Mail_mime wrapper where encrypted/signed
messages are created - needed code to build S/MIME messages.
Sorry, Alexander! I think that it isn't enough to study only those places where the new code is directly built in. It is necessary to know the general structure and functioning of an Enigma. And for this purpose it is necessary to study some thousands of lines of a code of which it consists. I can't make it.
I was also so already strongly beaten out from the schedule. Besides, there are many of different tasks in which I have to be engaged.
Best regards Vladimir
On 01/11/2016 11:10 AM, Владимир Горпенко wrote:
I don't know, whether it is correct to connect both ways of encryption in one plug-in. Solve it you.
It is correct. That was the idea behind the Enigma plugin from the beginning.
I think, 90% of my texts are repeated that you already made for PGP encryption. If it is about sharing experience of transformation of the message from the S/MIME encryption form to decrypted and back, I am ready to make it and to offer code samples. Certainly, the same belongs and to signing of messages.
If we extend Enigma you'll get 80% less work in the future and you'll get support "for free". Similar to the password plugin, S/MIME will be just a driver, all the rest of code (like engine and UI) will be shared and supported.
Also, if the rcube developers accept my changes in the text of the program or will offer similar, smime_crypto can be used by users of version 1.1.3 +. As I see, the line 1.1 continues to be supported and, therefore, changes can be made.
We will not apply any changes to the core in 1.1, especially when they are not needed in 1.2. And 1.1 will be discontinued after 1.2-stable is released.
It is to be decided if we want a separate interface to manage certificates or to store/display them on the same list with PGP keys. Anyway, some UI work will be needed.
I think that management of certificates and keys has to be allocated in the separate module or management of certificates and keys has to provide many possible options. Different users can are need different options: storage on the LDAP server, in SQL base or is simple in files.
Storage is the next thing that we could unify and make shared by all Enigma drivers. At the moment Enigma uses files, but above I was referring to the UI. We have a list of PGP keys. Do we want a separate list for certificates or we could merge them on one list?
Also management of certificates and keys can be transferred to users or is made the centralized. For example that option which I will do for myself, will be so specific that I won't even offer it to anybody.
I don't know what it is, but we always could add hooks in Enigma, so you'd create a separate plugin only for this specific functionality.
It is just simple. There are only two types of data - the certificate and a private key. Formats of these data are standard and even not necessarily their nobility.)) There is one problem - safe storage of private keys. It can be solved differently. It is too the reason for allocation of management of certificates and keys in the separate module.
Well, welcome in the server-side encryption word. The same applies to PGP keys. In this case we just assume server is safe or not. There's really no point (or just no way) in securing private keys stored on the server.
I think that it isn't enough to study only those places where the new code is directly built in. It is necessary to know the general structure and functioning of an Enigma. And for this purpose it is necessary to study some thousands of lines of a code of which it consists. I can't make it.
I'm sure it's not so bad ;) At least for the most of work we need.
I was also so already strongly beaten out from the schedule. Besides, there are many of different tasks in which I have to be engaged.
Unfortunately I also have not much time recently to merge your code with Enigma. But as you provided the code, I'm sure someone if not me will do this eventually.
------ Исходное сообщение ------ От: "A.L.E.C" alec@alec.pl Кому: dev@lists.roundcube.net Отправлено: 11.01.2016 13:39:37 Тема: Re: [RCD] S/MIME encryption and signing plugin
Storage is the next thing that we could unify and make shared by all Enigma drivers. At the moment Enigma uses files, but above I was referring to the UI. We have a list of PGP keys. Do we want a separate list for certificates or we could merge them on one list?
I believe, everything depends on application. If it is about public service, the role of the administrator has to be minimized and the user has to do all work on maintaining base of certificates and keys. If it is about corporate service, the general address book and base of certificates are necessary, but also personal address books and bases of certificates are also useful.
Well, welcome in the server-side encryption word. The same applies to PGP keys. In this case we just assume server is safe or not. There's really no point (or just no way) in securing private keys stored on the server.
Yes, it is impossible to secure the keys which are stored on the server completely, of course. However if the private key is stored on the server in the form protected by the password, and the user shows the password during session, security of private keys will be higher. Here even it is necessary to invent nothing, PKCS12 provides such storage of keys.
I was also so already strongly beaten out from the schedule. Besides, there are many of different tasks in which I have to be engaged.
Unfortunately I also have not much time recently to merge your code with Enigma. But as you provided the code, I'm sure someone if not me will do this eventually.
I think that there is the third approach. If you specify to me: in THIS point it is necessary to insert the code transforming the message from one form to another, the source message is stored HERE, and the result should be received HERE, I probably could write such code. And such division would be effective: You would use your knowledge, I - mine.
I am anyway grateful for answers and an explanation of your position.
If it is interesting to you, my plans are as follows:
- As the working mail system is necessary to me right now, I will use
now the modified version 1.1.3.
- Today I will create some new servers. On one of them there will be
Rcube 1.2. I will look at Rcube regarding possibility of use of the existing hooks for my plugin. If it is possible and not too difficult, the plugin will be modified under version 1.2. If the existing possibilities of Rcube 1.2 seem to me insufficient, we can discuss it if you want.
- In the third turn I will look at those places of an Enigma which you
to me called. Then I will be able to estimate possibility of embedding of S/MIME encryption by me at an Enigma and, respectively, to solve, whether I will participate in it.
Best regards Vladimir
Hello!
------ Исходное сообщение ------ От: "A.L.E.C" alec@alec.pl Кому: dev@lists.roundcube.net Отправлено: 11.01.2016 13:39:37 Тема: Re: [RCD] S/MIME encryption and signing plugin
I think that it isn't enough to study only those places where the new code is directly built in. It is necessary to know the general structure and functioning of an Enigma. And for this purpose it is necessary to study some thousands of lines of a code of which it consists. I can't make it.
I'm sure it's not so bad ;) At least for the most of work we need.
I fluently saw enigma_driver.php. If I correctly understand, you suggest to make the driver for S/MIME.
I have some questions.
- Processing of the message is entirely made in memory? And if message
is very big? Is ciphered and subscribes not only the text of the message, but also the attached files.
- If I correctly understood, the driver processes only a message body.
But it is also necessary to work with headers - to remove one, to add others. How it is offered to be realized?
- php openssl works with private keys and certificates. And the driver
receives only keys. Whether it is possible to build in this scheme work with certificates?
- The certificate can be attached to the received message. It can be
kept by the recipient for further use. It can be done in the existing scheme?
- The certificate attached to the signed message can be invalid or not
entrusted. For verification of the power of attorney of the certificate the base of the entrusted CA is necessary. It can be realized in the driver?
Perhaps, I not completely understood ideology of drivers and everything is simpler, than it seemed to me. In that case I apologize.
Best regards, Vladimir Gorpenko
On 01/12/2016 03:15 PM, Владимир Горпенко wrote:
I fluently saw enigma_driver.php. If I correctly understand, you suggest to make the driver for S/MIME.
I have some questions.
- Processing of the message is entirely made in memory? And if message
is very big? Is ciphered and subscribes not only the text of the message, but also the attached files.
Yes. In case of plain text messages. For messages with mime structure we load one encrypted part at a time. Parsing big plain text messages using temp files is planned for future.
- php openssl works with private keys and certificates. And the driver
receives only keys. Whether it is possible to build in this scheme work with certificates?
Sorry, I don't have enough knowledge about S/MIME yet to provide help here.
- The certificate can be attached to the received message. It can be
kept by the recipient for further use. It can be done in the existing scheme?
We already have handling of attached public keys so you can import them on request, but we probably need to implement use of them for decryption of the same message.
There's currently no option to attach a key to messages being sent.
- The certificate attached to the signed message can be invalid or not
entrusted. For verification of the power of attorney of the certificate the base of the entrusted CA is necessary. It can be realized in the driver?
Well, probably some changes will be needed, but PGP keys can also be entrusted or invalid or expired, etc. Not all is implemented yet.
------ Исходное сообщение ------ От: "A.L.E.C" alec@alec.pl Кому: dev@lists.roundcube.net Отправлено: 14.01.2016 23:13:12 Тема: Re: [RCD] S/MIME encryption and signing plugin
On 01/12/2016 03:15 PM, Владимир Горпенко wrote:
There was a question 2, I'd like to get answer on it too.
"2. If I correctly understood, the driver processes only a message body. But it is also necessary to work with headers - to remove one, to add others. How it is offered to be realized?"
- php openssl works with private keys and certificates. And the
driver receives only keys. Whether it is possible to build in this scheme work with certificates?
Sorry, I don't have enough knowledge about S/MIME yet to provide help here.
If I correctly understand, keys of PGP is only keys. The certificate contains, except a public key, a lot of other information. This information not only is of interest to the recipient, but also allows to check the certificate. The certificate is signed, and in the certificate is specified with whom exactly it is signed.
I can specify the following features of work with certificates.
- The certificate of the sender is often attached to the signed letter.
In that case for verification of the signature it is necessary to use this certificate. Yes, openssl will make it automatically.
- It is useful to be able to store this certificate in base. However it
is attached to the letter not as a standard attachment, at verification of the signature php openssl will take it from the letter. Therefore for saving of the certificate attached to the letter the main program needs to provide possibility of getting of the taken certificates from the driver. Or again to attach it to the letter already as a standard attachment that isn't quite trivial.
- Php openssl carries out independent verification of the certificate
in procedure of verification of the signature. I don't know precisely, which check it carries out, but the power of attorney CA, signed the certificate is checked. Check of integrity of the certificate, an expiration date, whether the certificate is withdrawn are essentially possible. Respectively after openssl verification additional information which needs to be told to the user will be received.
- For check, whether the certificate is signed with the entrusted CA,
openssl demands additional information, namely certificates of the entrusted CA. This information also has to be transferred to the driver somehow.
- Part of information containing in the certificate it is necessary to
tell to the recipient of the letter. It is right both for a case of the attached certificate, and for a case of the certificate received from the RC base. The driver has to provide means for transfer of this information to the main program.
There's currently no option to attach a key to messages being sent.
It does openssl sign if it isn't forbidden specially.
- The certificate attached to the signed message can be invalid or
not entrusted. For verification of the power of attorney of the certificate the base of the entrusted CA is necessary. It can be realized in the driver?
Well, probably some changes will be needed, but PGP keys can also be entrusted or invalid or expired, etc. Not all is implemented yet.
I meant another: openssl verify can recognize the certificate as incorrect or not entrusted, and with this information it is necessary to do something right after verification of the signature.
Vladimir Gorpenko
-
A.L.E.C -
Владимир Горпенко