Question on message decryption

[chan] bitmessage
Oct 5 17:16

Sorry for the noob question. When messages are recieved the client decodes the messages if you have the relevant keys. How exactly does this process work. Is the entire message decoded all at once or is it in parts? I am wanting to know if its possible to only decode a part of the message for example if I wanted to only decode the subject line portion of the message. Thanks in advance.

[chan] bitmessage
Oct 6 05:25

The cipher Bitmessage uses is a streaming cipher so when treated as a stream you can stop at any point you want.

[chan] bitmessage
Oct 6 07:29

To my understanding of it, bitmessage has to decode the entire message with a key, because it only knows if a message was correctly decrypted by verifying the MAC (which is inside the encrypted message). And to verify that, it also has to have the entire message decrypted.

[chan] bitmessage
Oct 6 08:51

Your understanding is wrong. The MAC is not encrypted and covers the object header, iv, ephemeral public key and cipher text which anyone can read. If you can verify the MAC, then there is an astronomically high chance the message is for you and decryption will be successfull.

[chan] bitmessage
Oct 6 09:36

(To OP + all) This is open source software - don't guess, look it up! Read from bookmark to end of file: https://github.com/Bitmessage/PyBitmessage/blob/196d688b138393d1d540df3322844dfe7e7c02ba/src/pyelliptic/ecc.py#L449 The darknet is like the Internet of the early 90's. You learn new things every day. :)

[chan] bitmessage
Oct 6 09:39

My bad - the MAC does not cover the object header.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Oct 13 21:53

I don't remember if I replied to this thread, but yes, this is correct. You can hypothetically decrypt a smaller part but unless you already know that it's encrypted to that particular key, you won't know if the content is valid. And since bitmessage is designed in a way that you're not supposed to know who the message is for, that pretty much makes partial decryption useless unless you're in very special circumstances. Peter Surda Bitmessage core developer

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Oct 13 22:06

Correction: > I don't remember if I replied to this thread, but yes, this is > correct. Except some details outside the scope of the question (e.g. MAC). Peter Surda Bitmessage core developer

[chan] bitmessage
Oct 14 05:32

The current decryption process is as equally useless as partial decryption. Just because the MAC check passed doesn't mean the encryption key is the correct key. Even if the key is correct that doesn't mean that the content is valid.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Oct 14 07:40

There is a statistical chance that the MAC check succeeds even if the tried key isn't the intended recipient's key, but this is such a small chance that it can be ignored except for some special cases of cryptographic attacks. The MAC is 32 bytes, if it's truly random that makes a chance of a mismatch about 1/10^77. The objects also have an additional ECDSA signature, which is an additional verification layer. Peter Surda Bitmessage core developer

[chan] bitmessage
Oct 14 08:32

Yes but in order to verify the contents using ECDSA the contents still has to be valid in the first place so that you can work out the offset of the senders public signing key and offset and size of the signature to correctly access those fields so you can perform signature verification. If the contents is invalid (which can happen with the current decryption process) you will get non-sensical offsets and all sorts of other invalid data.

[chan] bitmessage
Oct 14 08:56

Use the source, Luke. Instead of guessing, why not model your attacks in Python with pyelliptic, test them using known keys and see how far it gets you. Benchmark your attacks by running them x1000 and counting the nanoseconds or whatevers. You don't need a cluster of ASICs to test your theories. Like Donald Knuth said, first make it work, then make it fast.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Oct 14 12:01

> Yes but in order to verify the contents using ECDSA the contents > still has to be valid in the first place so that you can work out > the offset of the senders public signing key and offset and size of > the signature to correctly access those fields so you can perform > signature verification. If the contents is invalid (which can happen > with the current decryption process) you will get non-sensical > offsets and all sorts of other invalid data. Yes, there are additional checks that have to pass before it is considered valid, so the probability is even lower, layer after layer. There's also a separate recipient check to prevent surreptitious forwarding attack, which as a side effect further reduces the likelihood for an invalid message to appear valid. Peter Surda Bitmessage core developer PS In the previous message I should have said collision instead of mismatch. But I think I got my point across anyway.

[chan] bitmessage
Oct 14 12:12

What you don't seem to fucking understand Peter is that partial decryption is exactly the same fucking steps as full decryption just in a different fucking order. All these fucking checks and balances for full decryption you are harping on about can still be fucking used in partial decryption, albeit at different fucking points in the process.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Oct 14 12:57

You could use the checks in a different order and skip MAC verification as you write. But there are still some restrictions. For example, the signature is at the end of the decrypted data, so if you want to check the signature, you still have to decrypt the whole object (or at least as long as the length variables are telling you where the signature should be). Some checks are also ambigous when done early. For example, an unknown encoding doesn't necessarily mean the message isn't for you, it could also mean you should upgrade. In most scenarios checking MAC first is probably the best option. If you already started the decryption, it's using AES256 which is very fast. Maybe if you were building a cracking software or hardware a different order may be better but I'm skeptical. My tests show that initialising the ECDSA is the most expensive step and I suspect that it will remain so unless you found some special cryptographic vulnerability. Peter Surda Bitmessage core developer

[chan] bitmessage
Oct 14 17:38

Linus? is that you?

[chan] bitmessage
Oct 14 17:43

Assholes. Assholes everywhere. Was this your tough childhood or were you born that way?

[chan] bitmessage
Oct 15 01:19

No one is talking about partial decryption requiring skipping MAC verification except you. Please explain why in partial decryption an unknown encoding can't result in a message to the user informing them to upgrade? For your reference the message encoding occurs after the destination ripe so by the time partial decryption gets to the encoding it has already ensured the message is for the user. If the destination ripe didn't match partial decryption would have bailed out avoiding decrypting the rest of the message and the expensive signature verification. You are still assuming an incomplete or badly implemented hypothetical partial decryption process. Please for future discussion change your model to a complete properly implemented hypothetical partial decryption implementation. Both methodologies are 100% viable they just detect different things at different times in the process. They each have pros and cons, which different people will weigh differently and thats okay. But you seem personally against partial decryption and hunting around for any and every flimsy excuse for why it is a bad idea.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Oct 15 10:15

> No one is talking about partial decryption requiring skipping MAC > verification except you. In order to verify the MAC, you at least need to have the full encrypted payload (you can't verify it until you have retrieved the data from the network or the disk) as you need to calculate its hash. This was an example of restrictions on order (you need to retrieve the data before attempting to verify the MAC). Also, if you don't have the right key, the MAC verification will almost certainly fail. I looked at the pyelliptic code and tested it just to make sure I get it right. It first checks the MAC, and only if it succeeds, does the decryption. So you're almost certainly only decrypting messages that are valid and for you. > Please explain why in partial decryption an unknown encoding can't > result in a message to the user informing them to upgrade? It can but unless further variables are checked, this alone is ambiguous. Please pay attention to what I'm writing. > For your > reference the message encoding occurs after the destination ripe so > by the time partial decryption gets to the encoding it has already > ensured the message is for the user. If the destination ripe didn't > match partial decryption would have bailed out avoiding decrypting > the rest of the message and the expensive signature verification. This was an example of verification order restriction, not decoding order restrictions. You can decode the object incrementally and verify the components on the fly (just like, as the issue in this thread is, you can decrypt it incrementally). This is how PyBitmessage tended to do things (with respect to decoding/verification, not decryption). I don't like it as the code is crappy. I'm trying to separate the decoding and verification. > You are still assuming an incomplete or badly implemented > hypothetical partial decryption process. Please for future > discussion change your model to a complete properly implemented > hypothetical partial decryption implementation. I'm pointing out that there are restrictions in how you proceed. I didn't say it's impossible but impractical under most circumstances. You'll get negligible performance benefits and have code that's more prone to errors, more difficult to debug and more difficult to maintain. So in a way I agree with you. > Both methodologies are 100% viable they just detect different things > at different times in the process. They each have pros and cons, > which different people will weigh differently and thats okay. But > you seem personally against partial decryption and hunting around > for any and every flimsy excuse for why it is a bad idea. Neither is 100% viable as statistically with an extremely low probability they both can result in a wrong interpretation (collision). My objections to partial decryption aren't related to the theory but to coding, it makes the code more complex and while it may result in a performance improvement, that will be negligible in most circumstances. If you want to implement it, I don't care. Peter Surda Bitmessage core developer

[chan] bitmessage
Oct 16 06:46

Of course you need the whole payload to verify the MAC. You also need the whole object to verify the checksum in the protocol header. It is quite stupid IMO to begin processing before doing these checks as you increase your attack surface which is why I never mentioned nor recommended skipping them. After you have done those checks, then you can then do decryption one block at a time, validating as much as you can before decrypting the next block. You repeat this decrypt then validate sequence until you get to the end or detect something that triggers a bail out. MAC verification and partial decryption are not mutually exclusive - they can both be done. To take your issue of message encoding, if that field does not provide sufficient information to make a bail out decision, then why are you stopping and complaining you could have done more? Don't stop, keep going until you either process the entire message or have enough information to decide it's not worth continuing to process the rest of the message. OP asked about the possibilty of partial decryption, not the difficulty of it. Just because something is difficult for somebody doesn't mean its not possible or should be discouraged. Impracticality is subjective - what one considers hard another considers childs play. OP has provided scarce little information about himself, his circumstances, what issue he is trying to address, what his plans are, etc, etc, so I haven't wasted my time making a lot of assumptions about them and playing the game of what-ifs (I would strongly advise you not to waste your time either) because that could consume many multiples of our combined lifetimes to address every single possibility. If, and as, OP shares more information, we can tailor our responses to what he is doing rather than making a lot of assumptions about what he may or may not do and the implications thereof. That is why I posted a simple answer in the affirmative to his query about the possibility of only decrypting part of a message. Until he posts more information it is ludicrous to be more specific. But you went on to post your objections in such a way as to imply that the issues you raise are unavoidable. I've been trying to set the record straight that there are ways around the issues you brought up so OP does not get discouraged from pursuing what he wants to do. It is up to OP to weigh up the tradeoffs not us. Yes choices made early in the process can constrain what you do later in the process but this is a fact of life and not unique to the question at hand. It is in fact extremely rare that one is not constrained in some way by earlier decisions. If OP chooses to pursue partial decryption we can address the actual issues he faces based on decisions he has actually made as, and if, he encounters them.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Oct 16 10:19

> OP asked about the possibilty of partial decryption, not the > difficulty of it. Just because something is difficult for somebody > doesn't mean its not possible or should be discouraged. I submit that if the OP understood his own question correctly (s)he wouldn't ask. I mean, obviously, AES-256-CBC decryption can be done with partial ciphertext. I further submit that your replies probably unnecessarily confused him/her. > Impracticality is subjective - what one considers hard another > considers childs play. Relevance is also subjective. What one considers relevant, others might not. Peter Surda Bitmessage core developer

[chan] bitmessage
Oct 16 11:43

fukin aye righteeoh, mate

[chan] bitmessage
BM-2cWy7cvHoq3f1rYMerRJp8PT653jjSuEdY

Subject Last Count
BM slow suddenly? Oct 20 10:19 3
How long until streams work? Oct 19 20:35 1
demanded difficulty of messages Oct 19 13:41 11
Python host to run bitmessage Oct 19 11:21 5
chanbot Oct 17 18:01 3
Ukraine Kiev Now Oct 17 13:47 2
how to resend pubkey Oct 17 08:02 4
What's a status of DevTalk pseudo-mailing list? Oct 17 00:54 10
Question on message decryption Oct 16 11:43 22
How they are trying to derail Bitmessage development Oct 16 07:32 4
Question on message decryption ( Edge Case Best config ) Oct 15 16:21 2
new BM mod via 0install Oct 14 21:53 4
pyBM eats too many CPU cycles Oct 14 18:14 43
Sending ACKs from hidden messages Oct 13 16:25 12
Using whatsapp, anybody? Oct 13 13:52 1
Message to Julian Assange. Oct 13 00:47 18
Future, philosophy and guns (was: Re: Message by Julian Assange) Oct 12 09:04 1
Message by Julian Assange. Oct 12 02:24 2
bitmessage implementation in any other programming language Oct 10 03:45 29
Message to a friend, with copy to Julian Assange. Oct 8 17:20 1
Advantage of using namecoin? Oct 8 01:16 3
ISS Space Station - Augmented Virtual Reality Oct 7 20:54 8
shadowchat vs. BM comparison Oct 7 13:54 14
why not use Lazarus to make a BM GUI ? Oct 5 16:02 5
unicode support in bitmessage (total msg size) Oct 4 17:33 5
Node list fuckery, mitigations? Oct 3 18:14 23
unicode support in bitmessage Oct 3 17:50 11
PGP integration with bitmessage Oct 2 19:08 23
Why getopt? Oct 2 14:42 5
monkeys with typewriters Sep 30 23:26 7
RFC: HTTP/S-based secondary peer wire protocol (proposal) Sep 30 23:07 4
Secret ANTIFA Handbook Exposes Real Agenda of AntiFa Sep 29 15:57 9
Building instructions for Windows Sep 29 07:29 25
tor browser sandbox 0.0.20 r48240 Sep 29 02:16 1
BM GUI via API using monkey studio Sep 29 01:22 19
addon to pyBM : otp crypter -- soon to be integrated into BM for extra safety ! Sep 28 22:39 2
I stick with pyBM 0.6.0 Sep 28 12:52 4
( WAS ..addon to pyBM ) Announce Sep 28 08:23 3
alternative to Qt-Designer ? none it seems Sep 27 23:44 2
(no subject) Sep 27 23:37 1
pyBM eats too many CPU cycles Sep 27 23:33 4
Why Bitmessage has waves of online activity? Sep 27 23:16 5
beamstat.com is being cached by google Sep 27 23:15 7
turn MiNode into a full client - simple task ! Sep 27 00:32 2
BitText XHKhFPCDzj: ultimate bitmessage forum Sep 26 21:53 2
GET XHKhFPCDzj Sep 26 21:44 1
28 days Sep 25 07:18 3
peer rating Sep 25 06:44 5
TTL Tweaks Sep 25 06:34 13
How to.. Sep 24 16:43 2
BitText Error Sep 24 16:32 1
BitText LIST Sep 24 16:16 1
HELP Sep 24 15:49 2
BitText ADD confirmation Sep 24 15:34 1
use MiNode py3 app to route a BM via "stream 7" Sep 24 14:07 1
BM GUI via API using KDevelop Sep 23 18:21 1
Email client integration Sep 23 16:34 10
got green light Sep 23 10:59 2
Git pull error Sep 23 08:49 13
Kdevelop + qt-designer for python Sep 22 21:47 1
NATO member Turkey boast that Russian S-400 SAMs can take out American B-52s, F-22s and Tomahawks Sep 22 12:24 1
bug? pyBM eats 17% of my 6core CPU cycles SOLVED :-) Sep 22 11:41 1
bug? pyBM eats 17% of my 6core CPU cycles Sep 22 11:37 1
monkey studio Sep 22 11:06 1
MX.forum.cool Sep 22 10:56 1
so stream 7 cannot work ? Then what did I do ? Sep 22 10:44 1