Re: The ascension of Matt Caswell
Thanks. I am still having issues with doing a debug. Mingw 32 with only code blocks still does not work. As best I can tell this thing is made to not look inside. Give me an idea on this. There is no way to tell how private keys are made. Dave On 11/4/2014 7:13 AM, Steve Marquess wrote: > I am very pleased to report that Matt Caswell, a current part time > OpenSSL team member, will be reporting for duty as a full time dedicated > OpenSSL resource beginning November 10. > > It has taken a small eternity in tedious aggravation to make the > necessary legal and accounting arrangements (which are even now not > entirely complete), but we are putting the donations that came our way > in the wake of the "Heartbleed" publicity to good use. We have > calculated that the donation funding in hand, plus that promised but > uncollected, plus revenue from our software support contracts, will > suffice to support this new full time position and eventually one other > as well. > > Matt is leaving a successful commercial career to join the two current > full time resources, Steve Henson and Andy Polyakov, who are funded via > the Linux Foundation Core Infrastructure Initiative (CII). Unlike those > two CII funded positions, Matt will be entirely funded by direct > donations from individual contributors, sponsors of various types, and > support contract customers. The list of such supporters is a long one, > and some of them have requested anonymity, but I would like to thank > Smartisan, Huawei, and Akamai in particular. > > -Steve M. > -- Dave Paxton dpax...@me.com 208 570 9755 skype: dpaxton __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate pass phrase brute force...
Perfect. No rudeness here. Just ideas. I do think that relying on a password as a base system for the private key will be the Achilles heal of any system. Even if you allow for CAPS you will soon have systems that will try to pass these in a few million times a second. As an administrator looking for the best route to take then always allow for all of the past mistakes made by others to be taken into account. Wide open systems allow for wide open attacks. On 9/5/2014 1:51 PM, flgirl799901 wrote: > I most certainly did NOT hack into anything. I thank you so much for > your response, but deplore your rudeness > > > Sent via the Samsung GALAXY S® 5, an AT&T 4G LTE smartphone > > > Original message > From: dave paxton > Date:09/05/2014 3:33 PM (GMT-05:00) > To: openssl-users@openssl.org > Cc: > Subject: Re: Certificate pass phrase brute force... > > That is easy. Just restrict the number of different passwords per > day. Any account. Thus the old school brute force idea passes out > the window. Most of what you are looking at it a signing issue. > Basically one person does a transaction and the the other person > verifies it. They do the DSA and thus they are the same person as > they should be. That is the idea anyway. As far as accounts go that > hold those keys then you have the few problems. Did the client get > hacked or you? Who can hack the account like our recent icloud > picture issue. All of this is lazy programming. It is really a > matter of how certain you are of the client and how you want to make > sure they are who they are. No biggie. Dave. > > > On 9/5/2014 1:03 PM, flgirl799901 wrote: >> How do I unsubscribe from all of this? >> >> >> Sent via the Samsung GALAXY S® 5, an AT&T 4G LTE smartphone >> >> >> Original message >> From: Gregory Sloop >> Date:09/05/2014 1:36 PM (GMT-05:00) >> To: openssl-users@openssl.org >> Cc: >> Subject: Certificate pass phrase brute force... >> >> General question: >> >> I've done a number of searches and can't find a lot about the >> subject. [I've searched the list archives too...at least as best I >> could.] >> >> In several cases, the most obvious being OpenVPN, I use client >> certificates generated by openssl, with a pass-phrase [password]. >> This means that if I ever have someone misplace the certificate, it >> can't be used without the password. [And I have little control about >> what users do with such things - they download and install software >> they shouldn't; They have unknown users use their machines; They get >> their machines/phones/tablets stolen etc.] >> >> However, if someone loses control of the certificate, I need to >> consider the safety of the certificate. [And I have to assume I'll >> never know they lost control of it either.] Assume users are >> practicing reasonable security and it's unlikely an attacker will >> obtain the pass-phrase when they obtain the certificate. [A hard/bad >> thing to assume, I realize.] >> >> So, I've seen reports of Elcomsoft's tool to attempt ~6K passwords a >> second against a certificate file. Let's assume two orders of >> magnitude better performance for a fairly determined attacker, and >> we're at 600K passwords per second. Three gets us 6M a second. >> >> But even at 6M a sec, a non dictionary guessable pass-phrase of 10 >> characters will require ~380 years to break - which isn't too bad, >> IMO. [Assume a 52 character set. This obviously gets complicated >> since the pass-phase probably isn't completely random etc...but lets >> assume a theoretical 52 character random set.] >> >> But since I can't find any reputable source for this kind of data, >> I'm questioning the assumptions above. >> >> Can anyone give me some pointers at a reputable attempt at >> quantifying this? [The brute-force-ability and the speed at which it >> might be accomplished.] >> Does anyone have a policy about loss of certificates and >> regeneration/revocation along with the underlying reasoning they're >> willing to share? >> >> Or, perhaps I completely misunderstand what's going on, and I'd be >> glad to be corrected. [Gently is always nice.] >> >> TIA >> -Greg >> >> >> >> > > -- > Dave Paxton > dpax...@me.com > 208 570 9755 > skype: dpaxton -- Dave Paxton dpax...@me.com 208 570 9755 skype: dpaxton
Re: Certificate pass phrase brute force...
That is easy. Just restrict the number of different passwords per day. Any account. Thus the old school brute force idea passes out the window. Most of what you are looking at it a signing issue. Basically one person does a transaction and the the other person verifies it. They do the DSA and thus they are the same person as they should be. That is the idea anyway. As far as accounts go that hold those keys then you have the few problems. Did the client get hacked or you? Who can hack the account like our recent icloud picture issue. All of this is lazy programming. It is really a matter of how certain you are of the client and how you want to make sure they are who they are. No biggie. Dave. On 9/5/2014 1:03 PM, flgirl799901 wrote: > How do I unsubscribe from all of this? > > > Sent via the Samsung GALAXY S® 5, an AT&T 4G LTE smartphone > > > Original message > From: Gregory Sloop > Date:09/05/2014 1:36 PM (GMT-05:00) > To: openssl-users@openssl.org > Cc: > Subject: Certificate pass phrase brute force... > > General question: > > I've done a number of searches and can't find a lot about the subject. > [I've searched the list archives too...at least as best I could.] > > In several cases, the most obvious being OpenVPN, I use client > certificates generated by openssl, with a pass-phrase [password]. This > means that if I ever have someone misplace the certificate, it can't > be used without the password. [And I have little control about what > users do with such things - they download and install software they > shouldn't; They have unknown users use their machines; They get their > machines/phones/tablets stolen etc.] > > However, if someone loses control of the certificate, I need to > consider the safety of the certificate. [And I have to assume I'll > never know they lost control of it either.] Assume users are > practicing reasonable security and it's unlikely an attacker will > obtain the pass-phrase when they obtain the certificate. [A hard/bad > thing to assume, I realize.] > > So, I've seen reports of Elcomsoft's tool to attempt ~6K passwords a > second against a certificate file. Let's assume two orders of > magnitude better performance for a fairly determined attacker, and > we're at 600K passwords per second. Three gets us 6M a second. > > But even at 6M a sec, a non dictionary guessable pass-phrase of 10 > characters will require ~380 years to break - which isn't too bad, > IMO. [Assume a 52 character set. This obviously gets complicated > since the pass-phase probably isn't completely random etc...but lets > assume a theoretical 52 character random set.] > > But since I can't find any reputable source for this kind of data, I'm > questioning the assumptions above. > > Can anyone give me some pointers at a reputable attempt at quantifying > this? [The brute-force-ability and the speed at which it might be > accomplished.] > Does anyone have a policy about loss of certificates and > regeneration/revocation along with the underlying reasoning they're > willing to share? > > Or, perhaps I completely misunderstand what's going on, and I'd be > glad to be corrected. [Gently is always nice.] > > TIA > -Greg > > > > -- Dave Paxton dpax...@me.com 208 570 9755 skype: dpaxton
Re: found half of it: EC key gen
Thanks, OK I got the rest of the way through the tangled mess. The question is there someone out there that can skip trace through the subroutines that can put together a tight code set on how this works? One command walk through to start from the beginning to the end which is the key feedback. If there are some good c++ people out there that might want to spend a day on it I can pay for the time. Dave On 8/7/2014 6:58 PM, Dave Thompson wrote: >> From: owner-openssl-us...@openssl.org On Behalf Of dave >> Sent: Monday, August 04, 2014 15:50 >> I have it that the elliptic multiply is not standard. So I have been >> skip tracing though the code. >> It starts with ec_key.c, with EC_KEY_generate_key. This grabs the >> group or or the particular curves prime field size. It then uses this > No, it uses the order of the generator or equivalently the subgroup > generated by the generator and used for operations. For a curve > over a prime field Zp the subgroup order is either slightly less than p > or slightly less than p divided by a small integer called the cofactor > (small meaning usually 2 or 4). For a curve over a "binary" (m-bit) field > the order is somewhat less than 2^m, or that divided by a small cofactor. > >> as the range for bn_rand_range. This is in bn_rand.c. In that it >> uses the first half which is bnrand. That grabs the time and shifts it >> around to start the process. Since the order or range is a large number > It logically adds the current time (assuming available) to the entropy pool. > Adding entropy is done by mixing bits in a fashion that should depend on > both/all inputs in a complicated way, but I haven't looked recently. Using > *only* the current time to seed random generation would not be secure, > and is a common mistake by inexperienced people. > >> in hex it looks like the output of the private key is also in hex. > The private key is a large (integer) number. There are many ways of > representing integers. Hex is a common way of representing large integers, > because it can easily be broken up into, or formed from, 8-bit bytes or > other > power-of-2 size units that are common on modern computers. In particular > when an EC private key is stored in the standard ASN.1 format defined in > X9.62 > and used in among others PKCS#8 and PKCS#12, the privatekey is stored as > ASN.1 integer which some tools including openssl asn1parse show in hex. > >> After that the generate key does the point multiply to make the public. >> Is there some other variable used here that I am missing? >> > Doesn't sound like it. > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org -- Dave Paxton dpax...@me.com 208 570 9755 skype: dpaxton __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
found half of it
In looking at this today I found what the new ec key is doing. It does a BN_rand_range operation. That does have the rand.h include. It looks like it is using from the random area pseudorand, pseudo, RAND_pseudo_bytes and RAND_bytes. So I guess it is a matter of putting this together with the various rand subroutines to get a handle on a logical flow chart. -- Dave Paxton dpax...@me.com 208 570 9755 skype: dpaxton /* crypto/bn/bn_rand.c */ /* Copyright (C) 1995-1998 Eric Young (e...@cryptsoft.com) * All rights reserved. * * This package is an SSL implementation written * by Eric Young (e...@cryptsoft.com). * The implementation was written so as to conform with Netscapes SSL. * * This library is free for commercial and non-commercial use as long as * the following conditions are aheared to. The following conditions * apply to all code found in this distribution, be it the RC4, RSA, * lhash, DES, etc., code; not just the SSL code. The SSL documentation * included with this distribution is covered by the same copyright terms * except that the holder is Tim Hudson (t...@cryptsoft.com). * * Copyright remains Eric Young's, and as such any Copyright notices in * the code are not to be removed. * If this package is used in a product, Eric Young should be given attribution * as the author of the parts of the library used. * This can be in the form of a textual message at program startup or * in documentation (online or textual) provided with the package. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the copyright *notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software *must display the following acknowledgement: *"This product includes cryptographic software written by * Eric Young (e...@cryptsoft.com)" *The word 'cryptographic' can be left out if the rouines from the library *being used are not cryptographic related :-). * 4. If you include any Windows specific code (or a derivative thereof) from *the apps directory (application code) you must include an acknowledgement: *"This product includes software written by Tim Hudson (t...@cryptsoft.com)" * * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * The licence and distribution terms for any publically available version or * derivative of this code cannot be changed. i.e. this code cannot simply be * copied and put under another distribution licence * [including the GNU Public Licence.] */ /* * Copyright (c) 1998-2001 The OpenSSL Project. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. All advertising materials mentioning features or use of this *software must display the following acknowledgment: *"This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit. (http://www.openssl.org/)" * * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to *endorse or promote products derived from this software without *prior written permission. For written permission, please contact *openssl-c...@openssl.org. * * 5. Products derived from this software may not be called "OpenSSL" *nor may "Op
ec key new
So in the code it does this:
if (!EC_KEY_generate_key(pkey))
throw key_error("CKey::MakeNewKey
So one then goes to EC_KEY. You can do either here:
#include
#include "ec_lcl.h"
#include
#include
EC_KEY *EC_KEY_new(void)
{
EC_KEY *ret;
ret=(EC_KEY *)OPENSSL_malloc(sizeof(EC_KEY));
if (ret == NULL)
{
ECerr(EC_F_EC_KEY_NEW, ERR_R_MALLOC_FAILURE);
return(NULL);
}
ret->version = 1;
ret->group = NULL;
ret->pub_key = NULL;
ret->priv_key= NULL;
ret->enc_flag= 0;
ret->conv_form = POINT_CONVERSION_UNCOMPRESSED;
ret->references= 1;
ret->method_data = NULL;
return(ret);
}
It goes on down the way a bit. It loads the LCL H file and that pulls
in BN. In BN it has a 64 bit number size for 32 bit systems. Right
there one get's lost.
>From there how does one trace this out into something like a logic
diagram? Can one load this into a program that shows the commands and
then shows the diagram for it with word sizes?
--
Dave Paxton
dpax...@me.com
208 570 9755
skype: dpaxton
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Can't get my CRL to work on my OpenSSL client
Thanks Steve,
I have been having a discussion with some friends of mine on this.
They were thinking that the problem from the recent random number issue
is a real problem in older 32 bit systems. I was thinking it is not as
bad as they are thinking. Since I was looking into this with the old
bitcoin code I thought I would take a look. The myriad of code in the
EC area is a problem to back trace. So I picked up the old 0.9.8h and
bitcoin 1.0. This would be a good way to diagram how it works. I see a
BN _new and then a bunch of work after that. One suggestion is they
used a get milli command to fill the 64 bits. I thought that was
silly. So I thought I would ask. Attached is the key h file. I was
nto sure if it can be diagrammed as there are some base changes as best
I can tell.
Dave.
On 7/30/2014 3:44 PM, Dr. Stephen Henson wrote:
> On Wed, Jul 30, 2014, Jason Schultz wrote:
>
>> OK. So as far as you're aware, there's not a way to avoid the requirement of
>> the combined root cert/CRL file when checking for revoked certificates? I
>> would prefer to just have to deal with the CRL in PEM format, but the CRL
>> file must always be the CRL appended to the root cert, as far as I can tell.
>> Thanks for your prompt responses, by the way.
>>
> The CRL can come from anywhere as long as it is supplied to OpenSSL in the
> appropriate way.
>
> There are some standard places a CRL can be included such as a file or
> directory containing the set of trusted certificates but it is not a
> requirement.
>
> I can't really comment more without seeing a sample of how your code is
> loading the CRL and how it is enabling CRL checks.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager majord...@openssl.org
--
Dave Paxton
dpax...@me.com
208 570 9755
skype: dpaxton
// Copyright (c) 2009 Satoshi Nakamoto
// Distributed under the MIT/X11 software license, see the accompanying
// file license.txt or http://www.opensource.org/licenses/mit-license.php.
// secp160k1
// const unsigned int PRIVATE_KEY_SIZE = 192;
// const unsigned int PUBLIC_KEY_SIZE = 41;
// const unsigned int SIGNATURE_SIZE = 48;
//
// secp192k1
// const unsigned int PRIVATE_KEY_SIZE = 222;
// const unsigned int PUBLIC_KEY_SIZE = 49;
// const unsigned int SIGNATURE_SIZE = 57;
//
// secp224k1
// const unsigned int PRIVATE_KEY_SIZE = 250;
// const unsigned int PUBLIC_KEY_SIZE = 57;
// const unsigned int SIGNATURE_SIZE = 66;
//
// secp256k1:
// const unsigned int PRIVATE_KEY_SIZE = 279;
// const unsigned int PUBLIC_KEY_SIZE = 65;
// const unsigned int SIGNATURE_SIZE = 72;
//
// see www.keylength.com
// script supports up to 75 for single byte push
class key_error : public std::runtime_error
{
public:
explicit key_error(const std::string& str) : std::runtime_error(str) {}
};
// secure_allocator is defined is serialize.h
typedef vector > CPrivKey;
class CKey
{
protected:
EC_KEY* pkey;
public:
CKey()
{
pkey = EC_KEY_new_by_curve_name(NID_secp256k1);
if (pkey == NULL)
throw key_error("CKey::CKey() : EC_KEY_new_by_curve_name failed");
}
CKey(const CKey& b)
{
pkey = EC_KEY_dup(b.pkey);
if (pkey == NULL)
throw key_error("CKey::CKey(const CKey&) : EC_KEY_dup failed");
}
CKey& operator=(const CKey& b)
{
if (!EC_KEY_copy(pkey, b.pkey))
throw key_error("CKey::operator=(const CKey&) : EC_KEY_copy
failed");
return (*this);
}
~CKey()
{
EC_KEY_free(pkey);
}
void MakeNewKey()
{
if (!EC_KEY_generate_key(pkey))
throw key_error("CKey::MakeNewKey() : EC_KEY_generate_key failed");
}
bool SetPrivKey(const CPrivKey& vchPrivKey)
{
const unsigned char* pbegin = &vchPrivKey[0];
if (!d2i_ECPrivateKey(&pkey, &pbegin, vchPrivKey.size()))
return false;
return true;
}
CPrivKey GetPrivKey() const
{
unsigned int nSize = i2d_ECPrivateKey(pkey, NULL);
if (!nSize)
throw key_error("CKey::GetPrivKey() : i2d_ECPrivateKey failed");
CPrivKey vchPrivKey(nSize, 0);
unsigned char* pbegin = &vchPrivKey[0];
if (i2d_ECPrivateKey(pkey, &pbegin) != nSize)
throw key_error("CKey::GetPrivKey() : i2d_ECPrivateKey returned
unexpected size");
return vchPrivKey;
}
bool SetPubKey(const ve
general
I have been having a discussion with some friends of mine on this.
They were thinking that the problem from the recent random number issue
is a real problem in older 32 bit systems. I was thinking it is not as
bad as they are thinking. Since I was looking into this with the old
bitcoin code I thought I would take a look. The myriad of code in the
EC area is a problem to back trace. So I picked up the old 0.9.8h and
bitcoin 1.0. This would be a good way to diagram how it works. I see a
BN _new and then a bunch of work after that. One suggestion is they
used a get milli command to fill the 64 bits. I thought that was
silly. So I thought I would ask. Attached is the key h file. I was
not sure if it can be diagrammed as there are some base changes as best
I can tell.
Dave.
--
Dave Paxton
dpax...@me.com
208 570 9755
skype: dpaxton
// Copyright (c) 2009 Satoshi Nakamoto
// Distributed under the MIT/X11 software license, see the accompanying
// file license.txt or http://www.opensource.org/licenses/mit-license.php.
// secp160k1
// const unsigned int PRIVATE_KEY_SIZE = 192;
// const unsigned int PUBLIC_KEY_SIZE = 41;
// const unsigned int SIGNATURE_SIZE = 48;
//
// secp192k1
// const unsigned int PRIVATE_KEY_SIZE = 222;
// const unsigned int PUBLIC_KEY_SIZE = 49;
// const unsigned int SIGNATURE_SIZE = 57;
//
// secp224k1
// const unsigned int PRIVATE_KEY_SIZE = 250;
// const unsigned int PUBLIC_KEY_SIZE = 57;
// const unsigned int SIGNATURE_SIZE = 66;
//
// secp256k1:
// const unsigned int PRIVATE_KEY_SIZE = 279;
// const unsigned int PUBLIC_KEY_SIZE = 65;
// const unsigned int SIGNATURE_SIZE = 72;
//
// see www.keylength.com
// script supports up to 75 for single byte push
class key_error : public std::runtime_error
{
public:
explicit key_error(const std::string& str) : std::runtime_error(str) {}
};
// secure_allocator is defined is serialize.h
typedef vector > CPrivKey;
class CKey
{
protected:
EC_KEY* pkey;
public:
CKey()
{
pkey = EC_KEY_new_by_curve_name(NID_secp256k1);
if (pkey == NULL)
throw key_error("CKey::CKey() : EC_KEY_new_by_curve_name failed");
}
CKey(const CKey& b)
{
pkey = EC_KEY_dup(b.pkey);
if (pkey == NULL)
throw key_error("CKey::CKey(const CKey&) : EC_KEY_dup failed");
}
CKey& operator=(const CKey& b)
{
if (!EC_KEY_copy(pkey, b.pkey))
throw key_error("CKey::operator=(const CKey&) : EC_KEY_copy
failed");
return (*this);
}
~CKey()
{
EC_KEY_free(pkey);
}
void MakeNewKey()
{
if (!EC_KEY_generate_key(pkey))
throw key_error("CKey::MakeNewKey() : EC_KEY_generate_key failed");
}
bool SetPrivKey(const CPrivKey& vchPrivKey)
{
const unsigned char* pbegin = &vchPrivKey[0];
if (!d2i_ECPrivateKey(&pkey, &pbegin, vchPrivKey.size()))
return false;
return true;
}
CPrivKey GetPrivKey() const
{
unsigned int nSize = i2d_ECPrivateKey(pkey, NULL);
if (!nSize)
throw key_error("CKey::GetPrivKey() : i2d_ECPrivateKey failed");
CPrivKey vchPrivKey(nSize, 0);
unsigned char* pbegin = &vchPrivKey[0];
if (i2d_ECPrivateKey(pkey, &pbegin) != nSize)
throw key_error("CKey::GetPrivKey() : i2d_ECPrivateKey returned
unexpected size");
return vchPrivKey;
}
bool SetPubKey(const vector& vchPubKey)
{
const unsigned char* pbegin = &vchPubKey[0];
if (!o2i_ECPublicKey(&pkey, &pbegin, vchPubKey.size()))
return false;
return true;
}
vector GetPubKey() const
{
unsigned int nSize = i2o_ECPublicKey(pkey, NULL);
if (!nSize)
throw key_error("CKey::GetPubKey() : i2o_ECPublicKey failed");
vector vchPubKey(nSize, 0);
unsigned char* pbegin = &vchPubKey[0];
if (i2o_ECPublicKey(pkey, &pbegin) != nSize)
throw key_error("CKey::GetPubKey() : i2o_ECPublicKey returned
unexpected size");
return vchPubKey;
}
bool Sign(uint256 hash, vector& vchSig)
{
vchSig.clear();
unsigned char pchSig[1];
unsigned int nSize = 0;
if (!ECDSA_sign(0, (unsigned char*)&hash, sizeof(hash), pchSig, &nSize,
pkey))
return false;
vchSig.resize(nSize);
memcpy(&vchSig[0], pchSig, nSize);
return true;
}
bool Verify(uint256 hash, const vector& vchSig)
{
// -1 = error, 0 = bad sig, 1 = good
if (ECDSA_verify(0, (unsigned char*)&hash, sizeof(hash), &vchSig[0],
vchSig.size(), pkey) != 1)
return false;
return true;
}
static bool Sign(const CPrivKey& vchPrivKey, uint256 hash, v
question
I have been working on a paper for some time. At the end of this I am looking at the use of secp256k1 in crypto currencies. This has been a problem to figure out how these things get the private key. I picked up the source code and although not a programmer I can sift through the Sanskrit OK. I cannot find this portion of the code in the H files. Nor have I found any explanation as to how one generates a private key. I downloaded this: http://slproweb.com/products/Win32OpenSSL.html After 24 hours messing with it I see that it is giving the right numbers. What I do not see is how the thing gives a different private key over time. The only thought I have is that it does some type of get time in milliseconds and then does some process. Does anyone have any knowledge on this? Thanks, Dave Paxton 6408 Colonial Drive Boise, ID 83709 208-570-9755 dpax...@me.com Skype: dpaxton
