2010-06-24 81 views
1

我在想,如果有可能和/或可行的混淆和安全来做为后续:C#公钥验证Perl私钥并用作AES密钥?可能和/或可行?

  • 与服务器客户端启动会话(这意味着一个有效的登录名和密码已发送和接受)
  • 服务器使用私钥对随机密码进行加密,然后将其用于使用Rijndael方法的数据加密,并将两者都发送回客户端(密码是加密的随机密码和Rijndael的加密数据,这正是我们想要的客户端工作)
  • 客户端将收到两个,验证密码,看看它是用我们的一对密钥加密或不如果是的话,它将被用来解密数据。

从我看到的情况来看,Rijndael对密码大小有一些限制,所以这甚至可能(考虑加密随机密码的输出)?

是否有一些与我在想或想要描述的东西接近的antoher approuch?

这是甚至有点w?吗?

我想要这样的东西的原因主要是为了让任何人都难以重现我们的服务器与客户端通信的情况,除此之外我们还使用智能装配。我希望你们把重点放在上面的问题上,忘记包装我的代码等。如果可能的话,可以把它看作是客户端/服务器通信安全的信息。

此致敬礼。

回答

1

我可以解决第一部分。如果服务器使用其私钥对密钥进行加密,那么ANYONE及其公钥将能够对其进行解密。这为一个中间人攻击留下了一个空洞。换句话说,如果我拦截你所做的同样的道理,我现在知道你知道的同一把钥匙。这意味着我可以看到所有来回的流量。

安全的症结一直是这个最初的密钥交换问题。您可能需要采用行业标准方法,如Diffie-Helman进行实际的密钥交换。希望有所帮助

+0

@Rob嗨,我可能会说错了什么或弄错了,我的服务器私钥的含义是使用我的PERL代码我已经生成了一对私钥和公钥,这些私钥和公钥都是默认设置的要在我的客户端和服务器上使用(使用给定的私钥,我正在生成一个加密的随机密码),甚至有可能拦截SSL数据,它是通过https请求发送所有这些数据的地方?如果我说了些奇怪的话,请纠正我,否则我可能会误解你。 – Prix 2010-06-24 06:47:37

+0

@Prix - 在这种情况下,您所描述的基本上是SSL已经做了什么。换言之,当您建立SSL连接时,双方的公钥/私钥只用于协商要使用的对称密钥。所有其他流量均采用对称算法加密发送。 首先,如果您已经在使用SSL,我认为您不需要担心这一点。不,我不知道有任何打破SSL的实用方法。如果有的话,我们不能再去网上银行/信用卡公司了!我认为SSL单独处理你想要的东西 - 对吗? – 2010-06-24 07:02:25

+1

另一个想法 - 如果你想要的只是晦涩难懂,你可以base64编码数据,你可以使用二进制序列化,你可以使用压缩algortihm等。我想这一切都取决于你真正需要多少安全。 – 2010-06-24 07:04:58