Encryption PSR?

[Phil Sturgeon]

Not sure if anyone on the Phalcon, Yii or PHPASS teams would be interested but they all have some encryption code doing fairly similar stuff so this seems like something that could have a PSR thrown at it.

https://github.com/rchouinard/phpass

http://www.yiiframework.com/doc/api/1.1/CSecurityManager

http://docs.phalconphp.com/en/latest/reference/crypt.html

Obviously this is not a proposal, but what do people think?

[Rémi Gaillard]

Hi Phil,

I think this is definitely a good idea to create a new PSR about encryption. Someone is interested to work on a first proposal with me ?

Best Regards,

Rémi Gaillard

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/dd5f7229-9a83-4a9b-af76-4206645c7d6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Dragoonis]

The goal of the group is to solve problems, big problems. Problems that cause restrictions with too much variation on how thing should be implemented. I see no problems with using any of the previously mentioned packages and don't see merit on spending time on a PSR for encryption. In the event an entrance vote is called on this and you ask other project leads like myself is encryption a pressing issue, I bet you they will say no.

Please focus on hard tasks like Caching, Logging, phpdoc, that's what the PHP community need.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/53831036.8030806%40prestashop.com.

[Alexander Makarov]

We may attempt to standardize inteface. In Yii2 we have the following set of methods exposed:

encrypt($data, $password)

decrypt($data, $password)

hashData($data, $key, $algorithm = 'sha256')

validateData($data, $key, $algorithm = 'sha256')

getSecretKey($name, $length = 32)

generateRandomKey($length = 32)

generatePasswordHash($password, $cost = 13)

validatePassword($password, $hash)

[Michiel Rook]

I'm very much in favor of an encryption PSR.

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/bc794024-52e5-4253-b899-abf7877903f7%40googlegroups.com.

[Phil Sturgeon]

On Monday, 26 May 2014 11:00:20 UTC+1, Paul Dragoonis wrote:

The goal of the group is to solve problems, big problems. Problems that cause restrictions with too much variation on how thing should be implemented. I see no problems with using any of the previously mentioned packages and don't see merit on spending time on a PSR for encryption. In the event an entrance vote is called on this and you ask other project leads like myself is encryption a pressing issue, I bet you they will say no.

Please focus on hard tasks like Caching, Logging, phpdoc, that's what the PHP community need.

Oh absolutely, this is a "could have" not a "must have". That said, I can think of occassions where I would like to encrypt something in another library (OAuth 2 Server, etc) where doing this with a standardized package would be awesome, especially when we want to implement things a little tougher than sha1() :)

People definitely need to focus on Caching and phpdoc, no doubts. But, we can have a small working group of one/two people (who dont even need to be members) putting together a pre-draft over the next few months without any distraction to the group whatsoever. :)

[Enrico Zimuel]

Hi all,

i'm the author of Zend\Crypt component of Zend Framework 2
(http://framework.zend.com/manual/2.3/en/modules/zend.crypt.introduction.html),
i think that a standard interface for encryption can be a good idea.

Regards,
Enrico Zimuel

> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig/dd5f7229-9a83-4a9b-af76-4206645c7d6d%40googlegroups.com.

[tim...@gmail.com]

Hi all,

I found a link to this discussion via @ircmaxell's tweet and I'd like to share some thoughts about this.

@ircmaxell tweeted he strongly disagree with this kind of PSR, and I agree with him.

This is because "data encryption" is such a broad topic and may to be implemented in many different ways (depending on the specific use case).

Some may want to only sign the data, some may want to sign the data but with truncated MAC, some needs encryption also, while some needs encryption too but with different settings.

Does the encryption/MAC key need to be derived or can it be used as is (is the key user supplied or, as preferred, machine generated)? Is there support for key rotation (if there is, some sort of "key identifier" needs to be stored somewhere, maybe next to IV)? Where should you store machine generated keys?

Should there be any kind of time frame when the data is valid?

How about randomness requirements? I'd say 99% of the time you need a strong randomness source when dealing with encryption. This alone is actually quite a big real problem we face today (ie. https://github.com/symfony/symfony/issues/10759).

Those were a few issues, and while I see some of them are "hidden implementation details", I think there is no point to try to standardize this kind of varying construction (too many moving parts).

When engineering data encryption, probably the most important detail is "the implementation". This is something that is hard to PSR (it is probably out of scope).

And as already brought up, often password hashing seems to be included as well. I think this does not need a PSR coverage (we already have password_hash() and it is compatible with crypt(3)).

That being said, I think we could try to plan and write some kind of data encryption "cheat sheet". We could address the most common quirks and problems and get the reader to the "right track" (maybe something like how to handle issues brought up here http://timoh6.github.io/2012/08/21/Cryptography-in-web-applications-a-false-sense-of-security.html).

Of course in this kind of situation it may be just the same if one managed to do it 99% correct or if one managed to do it 1% correct, the outcome could be a fail for both of them. But at least we could try to root out the most common issues (and make sure the reader acknowledges the situation).

Timo

[Phil Sturgeon]

So, do you understand how PSRs work? That they are only for basic interfaces and implementation is left up to the implementators?  Because nothing you said would be effected, worsened or damaged by an encryption PSR.

[Enrico Zimuel]

Hi Timo,

your concerns are about the implementation and I agree with you and
@ircmaxell but PSR is about interface so I don't see problem here.
Even because we are talking about Encryption and not all the others
cryptographic primitives.
So I think we can try to propose something, for instance I used the
following interface for symmetric encryption:
https://github.com/zendframework/zf2/blob/master/library/Zend/Crypt/Symmetric/SymmetricInterface.php

Generally speaking I think an interface like that can cover the most
common encryption use cases:

encrypt($data, $key = null, $options = array())
decrypt($data, $key = null, $options = array())
setKey($key)
setOptions($options)
getKey()
getOptions()

I don't think we need to define APIs to generate random keys or to
hash values. This can be done using other components or PHP internal
functions for the hash case.

Regards,
Enrico Zimuel

> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig/a5e0d282-c89d-439f-b703-c1aef8367d2e%40googlegroups.com.

[tim...@gmail.com]

Hi Enrico and Phil,

I see the point we could maybe define an interface like ZF has (as Enrico showed), but my concern is that then we encourage people to implement their own crypto code (rolling their own crypto, based on the PSR). This is a big problem, I think.

I'd rather see just one dedicated library to do the crypto, which offers only a _high level_ entry point to be used.

I admit I don't have deep knowledge about the PSR standardization, but having a standard like PSR-0 is a great way to increase interoperability, whereas this kind of encryption standard is not so (dealing with encryption is not so straightforward than dealing with standardized autoloading). Ie. if you need to handle emailing, you could use, say, Swift Mailer and be done with it. I think the same applies to data encryption.

Timo

[Paul Dragoonis]

Hi Timo,

Your points have been taken on board, they are indeed valid points in general PHP coding but that's outwith the scope of a PSR.

The point of an encryption PSR is interoperability (not which library is better) The end goals is to allow library A and B to have a common interface for their adapters and you can switch between library A's adapter and library B's adapter with no refactorisation.

I hope that made sense and that you agree with us.

Many thanks,

Paul

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/af779bd2-dd9f-4b78-85a6-409517ddf5f2%40googlegroups.com.

[Anthony Ferrara]

All,

> The point of an encryption PSR is interoperability (not which library is better) The end goals is to allow library A and B to have a common interface for their adapters and you can switch between library A's adapter and library B's adapter with no refactorisation.

Yes, that is the point. And that is the reason this isn't a good idea.

In order for implementation A to be drop-in compatible with implementation B, the data formats and methods must be identical (otherwise all data produced by A can't be consumed by B). At which point you're no longer specifying the interface, but the implementation as well. At which point what you're trying to do fails.

Unless you say that you don't care about data compatibility. And each implementation is free to implement as they wish. But then, things quickly deteriorate as well. 

The problem is that there is so much that goes into an implementation that an interface would need to be *really* simple:

public function encrypt($data);

public function decrypt($data);

The second you add things like "keys" or "options", it starts to get overwhelmingly complicated.

And that's just talking about symmetric key block ciphers.

What about stream ciphers? What about public key cryptography. What about authentication. What about signing. What about key generation. What about key derivation.

Things get so complicated so quickly that it's a severe can of worms that you're opening by going down this route.

At best it won't be successful. At worst, it won't be secure.

Instead, what I'd rather see than a "standard interface(s)", would be standard implementations. Multiple. One for each usecase

class BlockCipher {
    public function encrypt($data);
    public function decrypt($data);
}

class StreamCipher {
    public function open($mode = StreamCipher::ENCRYPT);

    public function write($data);

}

class Authentication {
    public function authenticate($data);

}

etc.

Simple interfaces, with a centrally maintained implementation that can be reviewed. 

There are definite drawbacks to having a large number of cryptographic implementations. There are fewer to having a single implementation. And a single implementation that can be peer reviewed and maintained is going to be infinitely better than a dozen or so implementations that may or may not be. And audits are not a replacement for solid peer review.

Interoperability is an awesome goal. But I think in this case, it will do nothing but cause harm. 

My $0.02.

Anthony

[Phil Sturgeon]

Anthony: I have heard a few points from you and plenty from Zack K who is on your side on this one, but I managed to convince him otherwise and feel like I could do the same with you. Sadly I don't have the time or energy to get into it at the moment. Your feedback is great and offers a lot of things to think about, as for sure, encrypt() / decrypt() is not going to be the answer. 

I feel like this is something best saved for a Brooklyn cider/bike afternoon sometime this July, as we can either get a solution worked out, or get a list of reasons why it would be f**king moronic to link people to next time an encryption PSR is suggested.

If anyone else wants to pick up the "maybe we could do something useful with Encryption" conversation in the mean time, be my guest. I'm just outta steam for a bit.

[Ronan gloo]

What i think after reading this thread ans other PSR proposals, is basically:

Providing interoperability through standard PHP interfaces is a fair idea, but, to my opinion, beyond of the scope of the current sate of the language itself.

As long as PHP will not be able to specify the return type with interfaces, we are just thinking one, and only one aspect of the problem. Take a look at the cache proposal, and particularly the "get" implementation (https://github.com/php-fig/fig-standards/blob/master/proposed/cache.md).

There is no way to guarantee interoperability here (@return mixed ?), and efforts are, i some way, useless, as long as frameworks /  libraries have the ability to return their own stuff.

You can't safe switch to implementation to another without to know what you have to deal with, and even with a detailed docblock return tag, you're alone with the library's developer here.

[Larry Garfield]

That argument could be made about any interface in all of PHP ever.
"mixed" is dangerous, sure, but in context may be appropriate. Eg, if
you're caching data that could be of different types then you should get
back whatever type you put in, which is exactly what the spec says.

If someone implements an interface where a method says to return Foo,
and then returns Bar, it's not the caller's problem. The implementer
screwed up. File a bug report. :-)

That is the current status of PHP, for better or worse, and is not
something FIG is able to address.

--Larry Garfield

[Sebastian Krebs]

2014-07-24 23:28 GMT+02:00 Ronan gloo <sonot...@gmail.com>:

What i think after reading this thread ans other PSR proposals, is basically:

Providing interoperability through standard PHP interfaces is a fair idea, but, to my opinion, beyond of the scope of the current sate of the language itself.

As long as PHP will not be able to specify the return type with interfaces, we are just thinking one, and only one aspect of the problem. Take a look at the cache proposal, and particularly the "get" implementation (https://github.com/php-fig/fig-standards/blob/master/proposed/cache.md).

There is no way to guarantee interoperability here (@return mixed ?), and efforts are, i some way, useless, as long as frameworks /  libraries have the ability to return their own stuff.

Well, you've chosen a very specific edge-case. The problem here is, that as long as you can cache everything, you can fetch from the cache everything, or in other words: The type is always the same type, which was passed to "set()" before.

The solution would be, that you arbitrarily limit the type, but (because only "string" makes sense) it doesn't sound reasonable and means, that it always needs additional manual preparation, before you can cache things, instead of just "throwing things in".

 

You can't safe switch to implementation to another without to know what you have to deal with, and even with a detailed docblock return tag, you're alone with the library's developer here.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/92e8344d-3c01-4d83-a2ba-03ec7b6792a6%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
github.com/KingCrunch

[Henry Irving]

For more cyber security, please do check:

http://www.passwordmanagers.net/   Windows Password Manager

http://www.passwordmanagers.net/Android-Manager.html   Android Manager For PC

http://www.passwordmanagers.net/Iphone-Manager.html   iPod Manager

SEE MORE AT: http://www.passwordmanagers.net/

[Adam Englander]

Phil,

For what it's worth, it would be nice if there could be a common interface that was simple to understand and portable. Being able to quickly add scrypt or Argon2 to your framework would be super nice.

I would be willing to put in some of the grunt work if need be.

Also, you can add Symfony to the list:

http://api.symfony.com/3.2/Symfony/Component/Security/Core/Encoder/PasswordEncoderInterface.html