标签: diffie-hellman

当我与某些IRC服务器建立SSL连接(但不是其他服务器 - 可能是由于服务器的首选加密方法),我得到以下异常:

Caused by: java.lang.RuntimeException: Could not generate DH keypair
    at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:106)
    at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:556)
    at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:183)
    at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
    at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:893)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
    ... 3 more

最终原因:

Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive)
    at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..)
    at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
    at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:100)
    ... 10 more

演示此问题的服务器示例是aperture.esper.net:6697(这是一个IRC服务器).没有证明问题的服务器示例是kornbluth.freenode.net:6697.[毫不奇怪,每个网络上的所有服务器共享相同的行为.]

我的代码(如上所述,在连接到某些SSL服务器时有效)是:

    SSLContext sslContext = SSLContext.getInstance("SSL");
    sslContext.init(null, trustAllCerts, new SecureRandom());
    s = (SSLSocket)sslContext.getSocketFactory().createSocket();
    s.connect(new InetSocketAddress(host, port), timeout);
    s.setSoTimeout(0);
    ((SSLSocket)s).startHandshake();

这是抛出异常的最后一个startHandshake.是的,'trustAllCerts'有一些魔力; 该代码强制SSL系统不验证证书.(所以...不是证书问题.) …

我正在尝试将DHE_DSS实现到go的crypto/tls包中.不幸的是,我似乎无法使PreMasterSecret(Z)变得相同,我的基本工作流程是:

接收服务器密钥交换消息

• 提取P,G,Ys
• 使用提供的数字签名验证

准备客户端密钥交换消息

• 创建客户端的Xc
• 生成Yc(Yc = G ^ Xc%P)
• 生成Z(Z = Ys ^ Xc%P)
• 发回Yc,包装如下:

ckx := make([]byte, len(yC)+2)
ckx[0] = byte(len(Yc)>>8)
ckx[1] = byte(len(Yc))
copy(ckx[2:], yBytes)

但是,当我使用gnutls-serv进行调试时,两个PreMasterSecrets(Z)是不同的.我是否需要签署退回的Yc,或者以其他方式包装？我在RFC 5246中看不到任何建议.

< - 编辑 - >

以下是我的更改补丁:

https://08766345559465695203.googlegroups.com/attach/48587532c74b4348/crypto.patch?part=4&view=1&vt=ANaJVrHbwydqEZc3zjUWqQ5C8Q5zEkWXZLdL0w6JJG3HYntOlBurUTY7mc9xR9OTfE0bJxs4eeL5a5SGd2jj9eIfXcwJQgLvJchXOgkYKBBynbPfshY8kuQ

我正在尝试在python中实现RC4和DH密钥交换.问题是我不知道如何将python long/int从密钥交换转换为RC4实现所需的字节数组.有没有一种简单的方法可以将long转换为所需的长度字节数组？

更新:忘了提到我正在处理的数字是768位无符号整数.

Diffie-Hellman(DH)是否提供完美的前向保密？或者它只是Ephemeral Diffie-Hellman(DHE)的特色？Elliptic Curve短暂的diffie-Hellman(ECDHE)是否优于DHE？

我对Diffie-Hellman密钥交换期间中间人攻击的机制有疑问.我听说在密钥协议通信期间可能会发生这种情况.但是在CA(证书颁发机构)存在的情况下,接收方可以在收到发送方的公钥时对发送方进行身份验证.因此,中间人攻击怎么可能？

我们有一个Java Socket服务器监听SSLSocket(端口443)和一个连接它的iOS应用程序.在iOS 5.1上运行时,当我们将Java版本的服务器从JDK 1.5升级到1.6(或1.7)时,应用程序停止工作.在iOS 6上运行时,该应用程序可以很好地连接到JDK 5和6.

iOS应用报告错误: -9809 = errSSLCrypto.在Java方面,我们得到了javax.net.ssl.SSLException: Received fatal alert: close_notify.

在Java服务器端,我们启用了所有可用的密码套件.在客户端,我们测试了几个不同的套件,虽然我们还没有完成一个涉及每个单独启用的测试.现在,当我们使用时TLS_DH_anon_WITH_AES_128_CBC_SHA它失败了,虽然它已经失败了,但我们开始认为它不是套件.

这是调试输出.它一直到达ServerHelloDone,然后很快失败:

Is secure renegotiation: false
[Raw read]: length = 5
0000: 16 03 03 00 41                                     ....A
[Raw read]: length = 65
0000: 01 00 00 3D 03 03 50 83   1E 0B 56 19 25 65 C8 F2  ...=..P...V.%e..
0010: AF 02 AD 48 FE E2 92 CF   B8 …

我的任务是重现下面的情节：

它来自这个期刊（第 137-145 页）

在本文中，作者描述了一种针对 Diffie-Hellman 密钥交换的名为 SETUP 的窃取攻击。特别是，他们编写了这个算法：

现在，在2中作者认为“也许我们可以实现诚实的 DHKE 和恶意的 DHKE，然后我们比较两种算法的运行时间”。然后，创建了上面的情节。为此，他们说

“我们在 ANSI C 中实施了受污染和未受污染的 Diffie-Hellman 协议版本，并使用 GNU C v 2.7 编译器与 RSAREF 2.0 库链接。所有测试均在 Linux 系统上运行，使用一台配备 Pentium II 处理器（350 MHz）和 64 Mb 内存。单个协议的计算时间测量为 10-2 秒。”

我想做同样的事情，即实现善恶DH并比较运行时间。这是我生成的代码：

import timeit #used to measure the running time of functions
import matplotlib.pyplot as plt #plot the results
import random
import numpy as np

import pyDH #library for Diffie-Hellman key exchange

X= pyDH.DiffieHellman() #Eve's private key …

我想知道是否有(并且我希望有)ECDH(椭圆曲线Diffie-Hellman)和ECDSA(椭圆曲线数字签名算法)的公钥大小的标准,用于素数场上的每种曲线类型(192,224,256) ,384和521).

我正在使用OpenSSL的c库生成椭圆曲线Diffie-Hellman(ECDH)密钥对,遵循此处的第一个代码示例.它掩盖了这一行的实际公钥交换:

peerkey = get_peerkey(pkey);

所述pkey变量和返回值的类型都是的EVP *.pkey包含先前生成的公钥,私钥和参数,返回值仅包含对等方的公钥.所以这提出了三个问题:

1. 如何get_peerkey()实际提取公钥pkey以便发送给对等方？
2. 代码如何从pKey密钥交换后提取私钥和params 来存储它们以供以后使用？
3. 如何从对等方的原始公钥get_peerkey()生成新EVP_PKEY结构？

我已经看到了OpenSSL的功能EVP_PKEY_print_public(),EVP_PKEY_print_private()和EVP_PKEY_print_params()但这些是用于产生人类可读输出.我还没有找到任何将人类可读的公钥转换回EVP_PKEY结构的等价物.

我正在尝试创建一个能够使用Push API发送推送消息的服务器:https://developer.mozilla.org/en-US/docs/Web/API/Push_API

我有客户端工作,但现在我希望能够从Java服务器发送带有负载的消息.

我看到了nodejs web-push示例(https://www.npmjs.com/package/web-push),但我无法将其正确地转换为Java.

我尝试按照示例使用此处的DH密钥交换:http://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/CryptoSpec.html#DH2Ex

在sheltond的帮助下,我能够找出一些应该工作的代码,但事实并非如此.

当我将加密的消息发布到Push服务时,我得到了预期的201状态代码,但推送从未到达Firefox.如果我删除了有效负载和标头,只是将POST请求发送到同一个URL,则消息成功到达Firefox,没有数据.我怀疑它可能与我用Cipher.getInstance("AES/GCM/NoPadding")加密数据的方式有关;

这是我目前使用的代码:

try {
    final byte[] alicePubKeyEnc = Util.fromBase64("BASE_64_PUBLIC_KEY_FROM_PUSH_SUBSCRIPTION");
    KeyPairGenerator kpg = KeyPairGenerator.getInstance("EC");
    ECGenParameterSpec kpgparams = new ECGenParameterSpec("secp256r1");
    kpg.initialize(kpgparams);

    ECParameterSpec params = ((ECPublicKey) kpg.generateKeyPair().getPublic()).getParams();
    final ECPublicKey alicePubKey = fromUncompressedPoint(alicePubKeyEnc, params);
    KeyPairGenerator bobKpairGen = KeyPairGenerator.getInstance("EC");
    bobKpairGen.initialize(params);

    KeyPair bobKpair = bobKpairGen.generateKeyPair();
    KeyAgreement bobKeyAgree = KeyAgreement.getInstance("ECDH");
    bobKeyAgree.init(bobKpair.getPrivate());


    byte[] bobPubKeyEnc = toUncompressedPoint((ECPublicKey) bobKpair.getPublic());


    bobKeyAgree.doPhase(alicePubKey, true);
    Cipher bobCipher = Cipher.getInstance("AES/GCM/NoPadding");
    SecretKey bobDesKey = bobKeyAgree.generateSecret("AES");
    byte[] saltBytes = new byte[16];
    new …