Completed
Push — master ( 23cd7e...7877b2 )
by Francesco
02:54
created

Encryption::encryptWithKey()   A

Complexity

Conditions 1
Paths 1

Size

Total Lines 4
Code Lines 2

Duplication

Lines 0
Ratio 0 %

Code Coverage

Tests 2
CRAP Score 1

Importance

Changes 0
Metric Value
dl 0
loc 4
ccs 2
cts 2
cp 1
rs 10
c 0
b 0
f 0
cc 1
eloc 2
nc 1
nop 2
crap 1
1
<?php
2
3
/*
4
 * This file is part of the MesCryptoBundle package.
5
 *
6
 * (c) Francesco Cartenì <http://www.multimediaexperiencestudio.it/>
7
 *
8
 * For the full copyright and license information, please view the LICENSE
9
 * file that was distributed with this source code.
10
 */
11
12
namespace Mes\Security\CryptoBundle;
13
14
use Defuse\Crypto\Crypto as BaseCrypto;
15
use Defuse\Crypto\File as BaseCryptoFile;
16
use Mes\Security\CryptoBundle\Model\Key;
17
use Mes\Security\CryptoBundle\Model\KeyInterface;
18
19
/**
20
 * Class Encryption.
21
 */
22
final class Encryption extends AbstractEncryption
23
{
24
    /**
25
     * {@inheritdoc}
26
     *
27
     * @throw \Defuse\Crypto\Exception\EnvironmentIsBrokenException
28
     */
29 2
    public function encryptWithKey($plaintext, KeyInterface $key)
30
    {
31 2
        return BaseCrypto::encrypt($plaintext, $this->unlockKey($key));
0 ignored issues
show
Compatibility introduced by
$key of type object<Mes\Security\Cryp...dle\Model\KeyInterface> is not a sub-type of object<Mes\Security\CryptoBundle\Model\Key>. It seems like you assume a concrete implementation of the interface Mes\Security\CryptoBundle\Model\KeyInterface to be always present.

This check looks for parameters that are defined as one type in their type hint or doc comment but seem to be used as a narrower type, i.e an implementation of an interface or a subclass.

Consider changing the type of the parameter or doing an instanceof check before assuming your parameter is of the expected type.

Loading history...
Bug introduced by
It seems like $this->unlockKey($key) targeting Mes\Security\CryptoBundle\Encryption::unlockKey() can also be of type object<Defuse\Crypto\KeyProtectedByPassword>; however, Defuse\Crypto\Crypto::encrypt() does only seem to accept object<Defuse\Crypto\Key>, maybe add an additional type check?

This check looks at variables that are passed out again to other methods.

If the outgoing method call has stricter type requirements than the method itself, an issue is raised.

An additional type check may prevent trouble.

Loading history...
32
    }
33
34
    /**
35
     * {@inheritdoc}
36
     *
37
     * @throws \Defuse\Crypto\Exception\EnvironmentIsBrokenException
38
     * @throws \Defuse\Crypto\Exception\WrongKeyOrModifiedCiphertextException
39
     */
40 5
    public function decryptWithKey($ciphertext, KeyInterface $key)
41
    {
42 5
        return BaseCrypto::decrypt($ciphertext, $this->unlockKey($key));
0 ignored issues
show
Compatibility introduced by
$key of type object<Mes\Security\Cryp...dle\Model\KeyInterface> is not a sub-type of object<Mes\Security\CryptoBundle\Model\Key>. It seems like you assume a concrete implementation of the interface Mes\Security\CryptoBundle\Model\KeyInterface to be always present.

This check looks for parameters that are defined as one type in their type hint or doc comment but seem to be used as a narrower type, i.e an implementation of an interface or a subclass.

Consider changing the type of the parameter or doing an instanceof check before assuming your parameter is of the expected type.

Loading history...
Bug introduced by
It seems like $this->unlockKey($key) targeting Mes\Security\CryptoBundle\Encryption::unlockKey() can also be of type object<Defuse\Crypto\KeyProtectedByPassword>; however, Defuse\Crypto\Crypto::decrypt() does only seem to accept object<Defuse\Crypto\Key>, maybe add an additional type check?

This check looks at variables that are passed out again to other methods.

If the outgoing method call has stricter type requirements than the method itself, an issue is raised.

An additional type check may prevent trouble.

Loading history...
43
    }
44
45
    /**
46
     * {@inheritdoc}
47
     *
48
     * @throws \Defuse\Crypto\Exception\IOException
49
     * @throws \Defuse\Crypto\Exception\EnvironmentIsBrokenException
50
     */
51 1
    public function encryptFileWithKey($inputFilename, $outputFilename, KeyInterface $key)
52
    {
53 1
        BaseCryptoFile::encryptFile($inputFilename, $outputFilename, $this->unlockKey($key));
0 ignored issues
show
Compatibility introduced by
$key of type object<Mes\Security\Cryp...dle\Model\KeyInterface> is not a sub-type of object<Mes\Security\CryptoBundle\Model\Key>. It seems like you assume a concrete implementation of the interface Mes\Security\CryptoBundle\Model\KeyInterface to be always present.

This check looks for parameters that are defined as one type in their type hint or doc comment but seem to be used as a narrower type, i.e an implementation of an interface or a subclass.

Consider changing the type of the parameter or doing an instanceof check before assuming your parameter is of the expected type.

Loading history...
Bug introduced by
It seems like $this->unlockKey($key) targeting Mes\Security\CryptoBundle\Encryption::unlockKey() can also be of type object<Defuse\Crypto\KeyProtectedByPassword>; however, Defuse\Crypto\File::encryptFile() does only seem to accept object<Defuse\Crypto\Key>, maybe add an additional type check?

This check looks at variables that are passed out again to other methods.

If the outgoing method call has stricter type requirements than the method itself, an issue is raised.

An additional type check may prevent trouble.

Loading history...
54 1
    }
55
56
    /**
57
     * {@inheritdoc}
58
     *
59
     * @throws \Defuse\Crypto\Exception\IOException
60
     * @throws \Defuse\Crypto\Exception\EnvironmentIsBrokenException
61
     * @throws \Defuse\Crypto\Exception\WrongKeyOrModifiedCiphertextException
62
     */
63 1
    public function decryptFileWithKey($inputFilename, $outputFilename, KeyInterface $key)
64
    {
65 1
        BaseCryptoFile::decryptFile($inputFilename, $outputFilename, $this->unlockKey($key));
0 ignored issues
show
Compatibility introduced by
$key of type object<Mes\Security\Cryp...dle\Model\KeyInterface> is not a sub-type of object<Mes\Security\CryptoBundle\Model\Key>. It seems like you assume a concrete implementation of the interface Mes\Security\CryptoBundle\Model\KeyInterface to be always present.

This check looks for parameters that are defined as one type in their type hint or doc comment but seem to be used as a narrower type, i.e an implementation of an interface or a subclass.

Consider changing the type of the parameter or doing an instanceof check before assuming your parameter is of the expected type.

Loading history...
Bug introduced by
It seems like $this->unlockKey($key) targeting Mes\Security\CryptoBundle\Encryption::unlockKey() can also be of type object<Defuse\Crypto\KeyProtectedByPassword>; however, Defuse\Crypto\File::decryptFile() does only seem to accept object<Defuse\Crypto\Key>, maybe add an additional type check?

This check looks at variables that are passed out again to other methods.

If the outgoing method call has stricter type requirements than the method itself, an issue is raised.

An additional type check may prevent trouble.

Loading history...
66 1
    }
67
68
    /**
69
     * @param Key|KeyInterface $key
70
     *
71
     * @return \Defuse\Crypto\Key|\Defuse\Crypto\KeyProtectedByPassword
72
     */
73 9
    private function unlockKey(Key $key)
74
    {
75 9
        return $key->unlock()
76 8
                   ->getRawKey();
77
    }
78
}
79