Pages:
Author

Topic: Signature Mining (to embed messages into the blockchain without using OP_RETURN) (Read 3547 times)

legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
The two are incompatible with one another, but there would remain no way that an outside observer (who doesn't have the privkey used for a signature) to determine if k was generated deterministically or it was "mined", so your method remains possible (and it's pretty cool that you went and implemented it Smiley).

Agreed and thanks - just trying to offer ideas for those that are interested to use them.
hero member
Activity: 672
Merit: 504
a.k.a. gurnec on GitHub
I was just bringing up that point -- none of this really applies to open source implementations.

Okay - yes - I understand the issue of poor k values (which have been exploited already in Android).

Although deterministic is most likely a more secure method of generating addresses it of course would make this data injection method unfeasible.

The two are incompatible with one another, but there would remain no way that an outside observer (who doesn't have the privkey used for a signature) to determine if k was generated deterministically or it was "mined", so your method remains possible (and it's pretty cool that you went and implemented it Smiley).
hero member
Activity: 672
Merit: 504
a.k.a. gurnec on GitHub
...
I was just bringing up that point -- none of this really applies to open source implementations.

In theory.  

But look at heartbleed, shellshock, Ken Thompson's self-referencing Unix C compiler, perhaps truecrypt etc.

Open source does not imply that one is safe.  It certainly is helpful to verify that there are not back doors, but if you don't have enough people looking at it and security audits, well hidden bugs or intentional backdoors are easy to miss.  Obfuscated code that has intentional vulnerabilities can be difficult to spot.

Consequently, it is important to bring up vulnerabilities like this and discuss them - I'm glad you mentioned it.

 Smiley


Yes, and it's quite salient that you brought up TrueCrypt -- it has some leaky side channels which (before the ongoing audit began) were pointed out as avenues for exactly this kind of evil-implementation attack (and yes the source code was examinable at the time, but there wasn't a reproducible build process for Windows).
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
Open source does not imply that one is safe.  It certainly is helpful to verify that there are not back doors, but if you don't have enough people looking at it and security audits, well hidden bugs or intentional backdoors are easy to miss.  Obfuscated code that has intentional vulnerabilities can be difficult to spot.

Consequently, it is important to bring up vulnerabilities like this and discuss them - I'm glad you mentioned it.

 Smiley


Of course - I have made this open source and it should be audited by those that are interested (and I am not making any *guarantees* that this is 100% secure - so of course "use this at your own risk").
legendary
Activity: 4256
Merit: 1313
...
I was just bringing up that point -- none of this really applies to open source implementations.

In theory.  

But look at heartbleed, shellshock, Ken Thompson's self-referencing Unix C compiler, perhaps truecrypt etc.

Open source does not imply that one is safe.  It certainly is helpful to verify that there are not back doors, but if you don't have enough people looking at it and security audits, well hidden bugs or intentional backdoors are easy to miss.  Obfuscated code that has intentional vulnerabilities can be difficult to spot.

Consequently, it is important to bring up vulnerabilities like this and discuss them - I'm glad you mentioned it.

 Smiley
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
I was just bringing up that point -- none of this really applies to open source implementations.

Okay - yes - I understand the issue of poor k values (which have been exploited already in Android).

Although deterministic is most likely a more secure method of generating addresses it of course would make this data injection method unfeasible.
hero member
Activity: 672
Merit: 504
a.k.a. gurnec on GitHub
I thought that the ability to create subliminal messages in a security protocol was generally considered a flaw of that protocol.

For example, an evil ECDSA implementation could leak a user's private key to the implementation's authors. Isn't that (one) reason that newer ECDSA implementations deterministically generate k?

(I'm just repeating what I've read elsewhere on the forums and on the web, e.g. DJB's blog.)

For a start you'd need to *be aware* that the subliminal message exists (there is no way to tell by just looking at the sigs especially if you don't know how the code that encoded them is working as the placement of the message bytes can be made arbitrary).

Also this is only removing 1 or 2 bytes of security (assuming you could work out what had been purposely injected) which is not going to let you crack a private key.

If you consider a "vanity address" it is the same thing. Just because you know that I have an address that is prefixed with 1ciyam does not mean you are going to be able to *crack its private key* (if it were that easy then there should be zero BTC at my sig address - but there isn't).

Sorry, I wasn't very clear.

The "attack" I was trying to refer to involves an evil (and closed source) ECDSA implementation that intentionally leaks X successive bytes of a privkey in each signature it creates. Only someone aware of the leak, e.g the authors of the implementation, would able to take advantage of it. Given multiple signatures, the evil authors could reconstruct privkeys of those using their implementation.

An advantage (perhaps not the main advantage though) of a deterministically generated k is that one can validate the output of a closed-source implementation without needing the source code (assuming the method of generating k is published). If for example ProprietarySoft Corp. published an ECDSA library, researchers could verify that it wasn't using this channel to leak privkeys.

I was just bringing up that point -- none of this really applies to open source implementations.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
I thought that the ability to create subliminal messages in a security protocol was generally considered a flaw of that protocol.

For example, an evil ECDSA implementation could leak a user's private key to the implementation's authors. Isn't that (one) reason that newer ECDSA implementations deterministically generate k?

(I'm just repeating what I've read elsewhere on the forums and on the web, e.g. DJB's blog.)

For a start you'd need to *be aware* that the subliminal message exists (there is no way to tell by just looking at the sigs especially if you don't know how the code that encoded them is working as the placement of the message bytes can be made arbitrary).

Also this is only removing 1 or 2 bytes of security (assuming you could work out what had been purposely injected) which is not going to let you crack a private key.

If you consider a "vanity address" it is the same thing. Just because you know that I have an address that is prefixed with 1ciyam does not mean you are going to be able to *crack its private key* (if it were that easy then there should be zero BTC at my sig address - but there isn't).
hero member
Activity: 672
Merit: 504
a.k.a. gurnec on GitHub
I thought that the ability to create subliminal messages in a security protocol was generally considered a flaw of that protocol.

For example, an evil ECDSA implementation could leak a user's private key to the implementation's authors. Isn't that (one) reason that newer ECDSA implementations deterministically generate k?

(I'm just repeating what I've read elsewhere on the forums and on the web, e.g. DJB's blog.)
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
I decided to add a couple of functions to CIYAM's crypto keys implementation (https://github.com/ciyam/ciyam/blob/master/src/crypto_keys.cpp#L730) to emulate a "vanitygen" approach to "mining addresses" in order to encode a message in the address itself (just one byte per address for simplicity and because the code would need to be optimised to do more and it's obvious that vanitygen is very well optimised when I checked the timing).

Code to "encode the encrypted message" into a bunch of private keys is as follows ("Hello!" would of course be replaced with an encrypted message). The addresses and private keys are then output to the console.

Code:
vector< string > secrets;
generate_secrets_for_leading_byte_encoded_message( "Hello!", secrets );

vector< string > addresses;
for( size_t i = 0; i < secrets.size( ); i++ )
{
   addresses.push_back( private_key( secrets[ i ] ).get_address( ) );
   cout << addresses.back( ) << ' ' << secrets[ i ] << endl;
}

the other side (to decode the encrypted message) is as follows:

Code:
cout << decode_message_from_leading_byte_encoded_addresses( addresses ) << endl;

and this is a sample of the console output:
Code:
17crfGDDU1MJSdM2rrFGNXYm6db4hEQo6A bdad968085aa4b7b6cd653e4341c8845a84ccc37ce2438c3965c814d3cc686de
1AEqwSMc8rdR3jMUsSMU1Fx1x6sBKtLyhA a8f3b581a5fd2af58c7b9841df878f4631e189f69143ba6f34874ad527f6c435
1AurJRfZ8mLZfLAEonYnB2fRNKJj2sM52g a67bb9045d5bf12f89a871be3554aa798e69ab088740c3136d8111f21ba53c3b
1AujLMPYW3nkEte13PSmmrLJe6pJZYswgu 1bffc5f7d38e7a609511c89d24127b78324d74328a301ef803d539f6adcc65f6
1B85SG1dvTaF9JsM1UMaeLoQyb6MT6FHxr c180c4c1256e6b9dc1cf9ca9f9468953b3c9de9b7c25cd90969f25bb709a3164
145KFvZFLSYWHfDtJrmghcTKvaKAkp9rKu 1639eb3dce0143dd8b468abdcfe05e4f9ede0cf9a4621c6d07fc1eca44a4d56d
Hello!

Granted that only using 1 byte per address (and assuming 1 UTXO as the input) you could only fit 25 bytes for a 1K tx but it is at least a template of how this could be used by an application in order to send private messages via Bitcoin.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
legendary
Activity: 2576
Merit: 1186
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
@Crowex - nice - and yes I think you are right that the approach I've outlined is more like *subliminal* than normal *steganography*.

I'll let others be the judge of that however (I just enjoy *hacking* every now and again).  Grin
member
Activity: 111
Merit: 10
care to give a succinct explanation of the difference (not just for me but for others that might be following this topic)?

I couldn't do much better than quote the paragraph from the paper.

Quote
Steganography hides a secret message in another message, such that the existence
of the secret message is concealed. This can be done in various ways. Historically
this has been done with invisible ink, tiny pin punctures or pencil marks on
typewritten characters etc.. Today it is popular to hide a message in computer
graphics, where the least significant bit of each byte is replaced. Modern graphic
standards specify more gradations of color than the human eye can differ. By
changing the least significant bit the graphic do not change noticeable and it
is improbable that the change is noticed by the human eye. In this way a 64
kilobyte message can be stored in a a 1024 × 1024 grey-scale picture.

The subliminal channel uses an algorithm or protocol to hide messages in a
normal looking communication. Because the algorithm’s signature creation procedure
 is unchanged, the subliminal signature is indistinguishable from a normal
signature. Without the knowledge of the secret the subliminal message cannot
be read nor detected.

To summarize, a steganographic message is hidden in an object while a subliminal
message is embedded in an algorithm.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
Use an 1-of-N multisig, with 1 real public key, and N-1 fake public keys encoding the message

Another good idea (I like the way ideas flow here in this part of the forum).

Maybe Amir might add some approach along these lines to "sx".
legendary
Activity: 1792
Merit: 1111
Use an 1-of-N multisig, with 1 real public key, and N-1 fake public keys encoding the message
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
The paper I quoted explains the difference between steganography and subliminal channels.
I thought this was more along the lines of subliminal channels.

I did read the paper but perhaps not carefully enough - care to give a succinct explanation of the difference (not just for me but for others that might be following this topic)?

Unfortunately there has been so much to read lately (and I like many others am very busy) so it can really be helpful if smart people that understand these things can just succinctly explain the concepts in a way that most of us can easily absorb (rather than drowning ourselves in white papers - I am still digesting the side chains white paper at the moment).
member
Activity: 111
Merit: 10
The paper I quoted explains the difference between steganography and subliminal channels.
I thought this was more along the lines of subliminal channels.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
@trout - I agree that this is a form of steganography and also that I could have just *set up a service website* to ask people for BTC to send such messages (if I could be bothered) but you'll notice I didn't do that as I am just interested in getting the ideas out there (maybe a website for this will pop up next week but I assure you it will have nothing to do with me).

I am pretty sure it is much safer than using OP_RETURN (in terms of evidence) but yes I do think that you'd have to design it very carefully to make it *undetectable* (and using any website service for a start would be a huge weak point).
sr. member
Activity: 333
Merit: 252
what you are doing is called steganography.

Exchanging secret information in such a way that it looks like all that being
exchanged is public. Practically most used (and not secure) steganographic schemes use embedding secrets in the least significant bits of pictures, but any other "cover source" can be used instead of pictures, like music, video, chat messages, or as you suggest bitcoin transactions.

There are two main characteristics of a steganographic protocol.
- Secrecy. The messages exchanged should look "innocent", in the sense
that a passive observed should not be able to tell that secret information is being
passed.  This what you are trying to achieve by not using OP_RETURN, but
in fact that's not all to look out for. It might  be that your protocol creates a certain
pattern of exchanges, like  a transaction from A to B followed by B to A followed by A to B
(this is just hypothetical. I think your protocol doesn't result in any such pattern, but I didn't
really understand it very well.)


- Efficiency. The ratio between the amount of secret information passed and the total amount of data sent.
I suppose for bitcoin there's another measure of efficiency, namely the cost per secret bit.

I think bitcoin can be used for steganography in various ways (I can think about a few), probably more efficiently than you suggest. However, secrecy, which is not a big problem if you want to send
short text messages, will become major concern when you want a reliable source for sending
megabytes of data.  So in the end of the day, bitcoin may be not the best cover source out there.

Also, googling "bitcoin steganography" brings out a 3-years-old thread on this forum, where a guy wrote up
a paper suggesting a bitcoin protocol, but wants 1 BTC per download (I'm not giving a link because
I don't want to promote him, besides I'm not sure the download link is still up).
Pages:
Jump to: