mirror of
https://github.com/XRPLF/rippled.git
synced 2026-04-29 15:37:57 +00:00
89 lines
2.8 KiB
C++
89 lines
2.8 KiB
C++
#include <xrpl/protocol/AccountID.h>
|
|
#include <xrpl/protocol/HashPrefix.h>
|
|
#include <xrpl/protocol/KeyType.h>
|
|
#include <xrpl/protocol/PublicKey.h>
|
|
#include <xrpl/protocol/SField.h>
|
|
#include <xrpl/protocol/STExchange.h>
|
|
#include <xrpl/protocol/STObject.h>
|
|
#include <xrpl/protocol/SecretKey.h>
|
|
#include <xrpl/protocol/Serializer.h>
|
|
#include <xrpl/protocol/Sign.h>
|
|
|
|
namespace xrpl {
|
|
|
|
void
|
|
sign(
|
|
STObject& st,
|
|
HashPrefix const& prefix,
|
|
KeyType type,
|
|
SecretKey const& sk,
|
|
SF_VL const& sigField)
|
|
{
|
|
Serializer ss;
|
|
ss.add32(prefix);
|
|
st.addWithoutSigningFields(ss);
|
|
set(st, sigField, sign(type, sk, ss.slice()));
|
|
}
|
|
|
|
bool
|
|
verify(STObject const& st, HashPrefix const& prefix, PublicKey const& pk, SF_VL const& sigField)
|
|
{
|
|
auto const sig = get(st, sigField);
|
|
if (!sig)
|
|
return false;
|
|
Serializer ss;
|
|
ss.add32(prefix);
|
|
st.addWithoutSigningFields(ss);
|
|
return verify(pk, Slice(ss.data(), ss.size()), Slice(sig->data(), sig->size()));
|
|
}
|
|
|
|
// Questions regarding buildMultiSigningData:
|
|
//
|
|
// Why do we include the Signer.Account in the blob to be signed?
|
|
//
|
|
// Unless you include the Account which is signing in the signing blob,
|
|
// you could swap out any Signer.Account for any other, which may also
|
|
// be on the SignerList and have a RegularKey matching the
|
|
// Signer.SigningPubKey.
|
|
//
|
|
// That RegularKey may be set to allow some 3rd party to sign transactions
|
|
// on the account's behalf, and that RegularKey could be common amongst all
|
|
// users of the 3rd party. That's just one example of sharing the same
|
|
// RegularKey amongst various accounts and just one vulnerability.
|
|
//
|
|
// "When you have something that's easy to do that makes entire classes of
|
|
// attacks clearly and obviously impossible, you need a damn good reason
|
|
// not to do it." -- David Schwartz
|
|
//
|
|
// Why would we include the signingFor account in the blob to be signed?
|
|
//
|
|
// In the current signing scheme, the account that a signer is `signing
|
|
// for/on behalf of` is the tx_json.Account.
|
|
//
|
|
// Later we might support more levels of signing. Suppose Bob is a signer
|
|
// for Alice, and Carol is a signer for Bob, so Carol can sign for Bob who
|
|
// signs for Alice. But suppose Alice has two signers: Bob and Dave. If
|
|
// Carol is a signer for both Bob and Dave, then the signature needs to
|
|
// distinguish between Carol signing for Bob and Carol signing for Dave.
|
|
//
|
|
// So, if we support multiple levels of signing, then we'll need to
|
|
// incorporate the "signing for" accounts into the signing data as well.
|
|
Serializer
|
|
buildMultiSigningData(STObject const& obj, AccountID const& signingID)
|
|
{
|
|
Serializer s{startMultiSigningData(obj)};
|
|
finishMultiSigningData(signingID, s);
|
|
return s;
|
|
}
|
|
|
|
Serializer
|
|
startMultiSigningData(STObject const& obj)
|
|
{
|
|
Serializer s;
|
|
s.add32(HashPrefix::txMultiSign);
|
|
obj.addWithoutSigningFields(s);
|
|
return s;
|
|
}
|
|
|
|
} // namespace xrpl
|