使用SSL证书进行加密与生成的密钥

我正在加密,我目前正在使用 openssl_encrypt </ code>解决方案来加密我的数据 。 目前我正在重写使用 openssl_public_encrypt </ code>和 openssl_private_decrypt </ code>的旧代码库。</ p>

当然我必须匹配使用的加密 以前,但我正在考虑撤消加密数据并为其重写加密和解密方法。</ p>

openssl_public_encrypt </ code>值的缺点是它们 不能</ em> </ strong>大于用于加密的证书。 openssl_encrypt </ code>不存在这种缺点。 </ p>

http:/ /php.net/manual/en/function.openssl-public-encrypt.php#55901 </ p>

遗留代码库中的解决方法是将加密部分粘合在一起 能够加密大数据。 这对我来说似乎非常麻烦和密集。</ p>

我目前的解决方案是使用 openssl_encrypt </ code>和一个简单生成的密钥,比如Laravel会为它生成一个密钥:</ p >

  protected function generateRandomKey()
{
返回'base64:'。base64_encode(random_bytes(
$ this-&gt; laravel ['config'] ['app.cipher' ] =='AES-128-CBC'?16:32
));
}
</ code> </ pre>

这项工作非常出色,但选择了旧的代码库 用于加密/解密的SSL证书,原因我还不完全清楚。</ p>

openssl_encrypt </ code>与公共/私人相比有什么优势/劣势? 方式?</ p>

我想与第三方合作,你可以向他们提供你的公共证书,但你也可以向他们提供你生成的密钥。</ p>

如果第三方(如金融系统)需要访问加密,他们也可以解密它。</ p>

在这两种情况下,您都提供密钥来解密您的数据 。</ p>

我希望有人可以解释为什么你会限制自己加密不超过你的证书的值,这样你就可以使用 public / private openssl </ code> 功能。</ p>

干杯。</ p>
</ div>

展开原文

原文

I am working on encryption and I am currently using an openssl_encrypt solution to encrypt my data. Currently I am rewriting an old codebase that uses openssl_public_encrypt and openssl_private_decrypt.

Of course I will have to match the encryption that was used previously, but I am thinking about undoing the encrypted data and rewriting the encryption and decryption methods for it.

The downside with openssl_public_encrypt values, is that they can not be larger than the certificate that is used for encryption. This downside does not exist for openssl_encrypt.

http://php.net/manual/en/function.openssl-public-encrypt.php#55901

The workaround in the legacy code base was to glue encrypts pieces together to be able to encrypt large data. This seems pretty messy and intensive to me.

My current solution is using openssl_encrypt with a simple generated key like Laravel would generate a key for it:

protected function generateRandomKey()
{
    return 'base64:'.base64_encode(random_bytes(
        $this->laravel['config']['app.cipher'] == 'AES-128-CBC' ? 16 : 32
    ));
}

This works brilliantly but with the old code base have chosen SSL certificates for encrypting/decrypting for a reason that I am yet not fully aware of.

What would be the advantage/disadvantage with openssl_encrypt vs the public/private way?

I guess working with third parties you can provide them your public certificate, but you could just as well provide them your generated key.

If third parties(like a financial system) need access to encrypted they can decrypt it just as well.

In both cases you are supplying the key to decrypt your data.

I am hoping somebody can shed some light on why you would limit yourself to encrypt values no longer than your certificate so you could use the public/private openssl functions.

Cheers.

doujin8673
doujin8673 常见的解决方案是使用对称算法加密数据,该算法不受长度限制,然后使用私钥加密对称密钥。
3 年多之前 回复

2个回答

some light... ok...

first let's look at what algorithms or categories of algorithms we are dealing with here:

public/private key ... this means asymetric cryptography with algorithms like RSA... DH ...

in contrast to symetric cryptography with algorithms like AES ... DES ... TwoFish...

if your codebase contains stuff like gluing together chunks of encrypted data because the datasize was too large for the asymetric algorithm, one can safely say whoever build that did not know what he/she was doing.

symetric algorithms are used to encrypt bulk data ... asymetric algorithms are used to encrypt the symetric key so that the owners of the corresponding private keys can decrypt the symetric key and therefore can decrypt the bulk data ciphertext

the key for a symetric cipher like AES is not larger that the size restriction you find in the described methods

the reason for asymetric cryptography is that you can share your public key with the world, and everyone can encrypt data for you (data here means in 99% of all real world scenarios: symetric keys) but only you as the holder of the private key can decrypt ... the private key never leaves your hands ... noone ever has access to that except the owner

a certificate is merely a public key + metadata

that metadata contains information about who owns the keypair, what it may be used for, from when to when the keypair is valid, etc...

the metadata is put into a specific format and signed by a trusted third party ... the result is what you call a certificate

the signature on the certificate is something else you can do with public key crypto ... but this time the other way around ... to create the signature for a certain set of data, you need the private key... without it you can't sign ... but everyone that holds the public key can verify the signature ... if you change a single bit in the data the signature belongs to, it becomes invalid, so you cannot simply tamper with the contents of a certificate and for example change the key

update:

if you need some thirdparty to be able to send you encrypted data while they have your public key:

-they create a RANDOM symetric key that will be only known to them (let's call it Ksym)
-they encrypt whatever data they need with that key and a symetric cipher ... (ct=ENC(DATA,Ksym))
-they encrypt Ks for you using your public key (eKsym=ENC(Ksym,Kpub))
-they send you ct and eKsym

-you decipher eKsym (Ksym=DEC(eKsym,Kpriv))
-you decipher DATA = DEC(ct,Ksym)

facts:

only you and that third party know Ksym

if you want to store that data in a way even that thirdparty can not decrypt, you need to renecrypt it

if you store eKsym and ct only you and the thirdparty that originally encrypted the data have knowledge of the needed decryption key Ksym (and of course everyone who got the key from either you or said third party)

the fun fact is: Ksym is different for every piece of incoming data and is only valid for that piece of data ... sharing one Ksym with another third party only gives access to the one pice of data that belongs to this key

douzhanlai4671
douzhanlai4671 nah ......他想要了解事情是如何工作或应该工作的......甚至在TLS案例中他们确实以这种方式工作......不同之处在于TLS仅用于运输安全,而不用于存储(关键) 处理存储中缺少的东西)...你不能简单地去TLS,一切都很好......每个案例都没有开箱即用的解决方案
3 年多之前 回复
douyong1905
douyong1905 您是否建议实施此自定义解决方案比简单地删除它并使用众多跨平台和符合TLS实现之一更具时间和成本效益? 当然不是吗?
3 年多之前 回复
dongyishen5796
dongyishen5796 从理想的角度来看,当前实施的系统必须被拆除并被像TLS这样可靠的东西所取代,是的......问题在于成本,项目时间和工作时间的实际可用性。 程序员与项目的利益相关者...好的加密可悲的是没有赚钱,有时很难卖掉那个糟糕的加密可能会花费很多...有时候,遗憾的是,它只是用你所拥有的东西来解决你所能做到的事情
3 年多之前 回复
dswmmvrg40957
dswmmvrg40957 你的答案是有道理的,理论上是正确的,但在实际环境中实现这一点需要的不仅仅是你所描述的安全性。 您应该编辑您的答案,只需推荐TLS。
3 年多之前 回复
dsfs23434
dsfs23434 感谢您抽出宝贵的时间。 这真是有用的信息!
3 年多之前 回复
duanqianwei2485
duanqianwei2485 我会扩大答案......
3 年多之前 回复
douweng1904
douweng1904 因此,我们分发公钥,供人们加密他们可以发送的数据。 而且因为我们持有私钥,我们是唯一能够解密它的人? 那讲得通。 但是如何粘合数据块呢? 如果我们希望第三方能够加密我们的数据并将其发送给我们,该怎么办? 我们无法将它们交给openssl_encrypt密钥,因为它也将用于解密。 这意味着当有人掌握钥匙时,我们的数据可能会受到影响。 我这么说吗?
3 年多之前 回复



如果您不确定如何解决这个问题,那么您现在应该退出并雇用知道他们正在做什么来解决它的人。 不是卑鄙或粗鲁,做正确的事情会更好。 无论是谁在你明明不知道他们在做什么之前做了这些,都不要把自己添加到那个列表中。</ p>

如果你要自己解决这个问题(我不这样做) 我认为您应该这样做,我建议您使用TLS来保护您和最终用户之间的连接,接收他们发送给您的任何数据,然后加密并存储它。 我真的不知道为什么你(或者在你之前为此工作的人)认为用同一设备上的密钥加密静态数据是有益的......很多工作几乎没有安全性。</ p>

</ div>

展开原文

原文

If you are unsure how to solve this problem then you should back away now and hire someone that knows what they are doing to solve it. Not being mean or rude, it's just better to do it right. Whoever worked on this before you obviously had no idea what they were doing, don't add yourself to that list.

If you were going to solve this problem yourself (which I don't think you should), I would recommend you use TLS to secure your connection between you and your end users, receive whatever data they are sending you, and then encrypt that and store it. I don't really know why you (or whoever worked on this before you) thought it would be beneficial to encrypt data at rest with the keys on the same device... A lot of work for practically no security.

dongzhuo1958
dongzhuo1958 要看。 您正在加密的数据,它将存储在数据库中? 你在哪里保留加密密钥? 对称加密很可能是要走的路,是的。
3 年多之前 回复
doushi5024
doushi5024 目前没有第三方使用公钥。 它仅适用于未来的案例。 所以这还不是一个问题。 如果我们排除第三方,我想知道你认为什么是理想的解决方案。 openssl_encrypt会成为公共/私人方法的方式吗? 我知道这是需要正确完成的事情,但我非常怀疑我们会聘请某人为我们解决这个问题。
3 年多之前 回复
Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
立即提问
相关内容推荐