我现在是一名学生,我正在学习PHP,我正在尝试在PHP中对数据进行简单的加密/解密.我做了一些在线研究,其中一些很混乱(至少对我而言).

这是我正在尝试做的事情:

我有一个由这些字段组成的表(UserID,Fname,Lname,Email,Password)

我想要的是加密所有字段然后解密(是否可以sha256用于加密/解密,如果不是任何加密算法)

我想要学习的另一件事是如何创造一种hash(sha256)与良好"盐"相结合的方式.(基本上我只是希望有一个简单的加密/解密实现,hash(sha256)+salt) 先生/女士,你的答案会有很大的帮助,非常感谢.谢谢++

我是一名ASP.NET/C#开发人员.我一直使用VS2010.我想在我的笔记本电脑上启用BitLocker来保护内容,但我担心性能下降.使用像Visual Studio这样的IDE的开发人员正在同时处理大量的文件.我想,比通常的办公室工作人员更多.

所以我很好奇是否有其他开发人员使用BitLocker进行开发.表现如何？它引人注目吗？如果是这样,那不好吗？

我的笔记本电脑是2.53GHz Core 2 Duo,配备4GB RAM和Intel X25-M G2 SSD.它非常活泼,但我希望它保持这种状态.如果我听到一些关于BitLocker的坏故事,我会继续做我现在正在做的事情,这就是当我没有积极地工作时保留RAR的密码,然后在我完成时将其设置为SDelele(但它是这样的痛苦).

2015年更新:我旅行时一直在Surface Pro 3上使用Visual Studio 2015,默认启用了BitLocker.感觉就像我的台式机一样,i7-2600k @ 4.6 GHz.我认为在具有良好SSD的现代硬件上,你不会注意到!

我想加密二进制文件.我的目标是防止任何人读取没有密码的文件.

哪个是更好的解决方案,AES或Blowfish具有相同的密钥长度？我们可以假设攻击者拥有破解文件的大量资源(软件,知识,资金).

How can I encrypt bytes using a machine's TPM module?

CryptProtectData

Windows provides a (relatively) simple API to encrypt a blob using the CryptProtectData API, which we can wrap an easy to use function:

public Byte[] ProtectBytes(Byte[] plaintext)
{
   //...
}

The details of ProtectBytes are less important than the idea that you can use it quite easily:

• here are the bytes I want encrypted by a secret key held in the System
• give me back the encrypted blob

The …

我正在尝试实现基于密码的加密算法,但是我得到了这个例外:

javax.crypto.BadPaddingException:给定最终块未正确填充

可能是什么问题？(我是Java新手.)

这是我的代码:

public class PasswordCrypter {

    private Key key;

    public PasswordCrypter(String password)  {
        try{
            KeyGenerator generator;
            generator = KeyGenerator.getInstance("DES");
            SecureRandom sec = new SecureRandom(password.getBytes());
            generator.init(sec);
            key = generator.generateKey();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }


    public byte[] encrypt(byte[] array) throws CrypterException {
        try{
            Cipher cipher = Cipher.getInstance("DES/ECB/PKCS5Padding");
            cipher.init(Cipher.ENCRYPT_MODE, key);

            return cipher.doFinal(array);
        } catch (Exception e) { 
            e.printStackTrace();
        }
        return null;
    }

    public byte[] decrypt(byte[] array) throws CrypterException{
        try{
            Cipher cipher = Cipher.getInstance("DES/ECB/PKCS5Padding");
            cipher.init(Cipher.DECRYPT_MODE, key);

            return cipher.doFinal(array);
        } …

我正在尝试使用名为Pass的有趣的密码管理工具.

我做了以下事情:

1. 已安装的gpg工具 $ sudo dnf install gpg
2. 使用生成密钥 $ gpg --gen-key
3. 类型化$ pass init "foobar id of my gpg key"的规定在这里
4. 拿到

mkdir: created directory ‘/home/chichivica/.password-store/’ Password store initialized for foobar@email.com

5. 试图添加一个简单的密码

$ pass insert foo Enter password for foo: Retype password for foo:

6. 而且存在问题

gpg: A45A123C: There is no assurance this key belongs to the named user gpg: [stdin]: encryption failed: Unusable public key

有人能给我一些建议吗？也许我误解了什么？提前致谢.

在Android 上如何加密/解密 __CODE__和其他文件有一个很好的例子__CODE__吗？我正在开发一个需要加密/解密数据的项目,但我不确定该怎么做.

有没有办法以加密方式存储数据,以便可以使用多个不同的密钥对数据进行解密？

即如果我使用key1加密数据,但我希望能够使用密钥2,3和4进行解密.

这可能吗？

我意识到OAuth规范没有指定任何关于ConsumerKey,ConsumerSecret,AccessToken,RequestToken,TokenSecret或Verifier代码的来源,但我很好奇是否有任何创建显着安全令牌的最佳实践(特别是令牌/秘密组合).

在我看来,创建令牌有几种方法:

1. 只需使用随机字节,存储在与消费者/用户相关的数据库中
2. 散列一些用户/消费者特定数据,存储在与消费者/用户相关联的数据库中
3. 加密用户/特定于消费者的数据

(1)的优点是数据库是看起来最安全的信息的唯一来源.对(2)或(3)进行攻击会更难.

散列实数据(2)将允许从可能已知的数据重新生成令牌.可能没有真正为(1)提供任何优势,因为无论如何都需要存储/查找.比(1)更多的CPU密集型.

加密真实数据(3)将允许解密以了解信息.与(1)和(2)相比,这将需要更少的存储空间和更少的查找,但也可能不太安全.

是否还有其他方法/优点/缺点需要考虑？

编辑:另一个考虑因素是令牌中必须有某种随机值,因为必须存在过期和重新发行新令牌的能力,因此它不能只包含真实数据.

关注问题:

是否有最小的令牌长度,以显着加密安全？据我了解,更长的令牌秘密会创建更安全的签名.这种理解是否正确？

从散列角度来看,使用特定编码优于另一种编码是否有优势？例如,我看到很多使用十六进制编码的API(例如GUID字符串).在OAuth签名算法中,令牌用作字符串.使用十六进制字符串,可用字符集将比使用Base64编码的字符集小得多(更可预测).在我看来,对于两个长度相等的字符串,具有较大字符集的字符串将具有更好/更宽的散列分布.在我看来,它会提高安全性.这个假设是否正确？

OAuth规范在11.10熵的熵中提出了这个问题.

在工作中,我们有两种相互竞争的盐理论.我工作的产品使用类似用户名或电话号码来加密哈希值.基本上每个用户都有不同的东西,但我们可以随时使用.另一个产品为每个用户随机生成一个salt,并在每次用户更改密码时更改.然后在数据库中加密盐.

My question is if the second approach is really necessary? I can understand from a purely theoretical perspective that it is more secure than the first approach, but what about from a practicality point of view. Right now to authenticate a user, the salt must be unencrypted and applied to the login information.

在考虑之后,我只是没有从这种方法中看到真正的安全性收益.将盐从帐户更改为帐户,即使攻击者知道如何快速确定每个帐户的内容,仍然会使某人尝试强制执行散列算法变得非常困难.这是基于密码足够强的假设.(显然,找到一组密码的正确哈希值,它们都是两位数,比找到8位密码的正确哈希值要容易得多).我的逻辑是不正确的,还是我缺少的东西？

编辑:好的,所以这就是为什么我认为加密盐真的没有意义.(lemme知道我是否在正确的轨道上).

对于以下说明,我们假设密码总是8个字符,盐是5,所有密码都由小写字母组成(它只是使数学更容易).

Having a different salt for each entry means that I can't use the same rainbow table (actually technically I could if I …