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
Safe chat software? Dec 13 12:39 15
the green light Dec 13 12:36 10
torIRC 2.33 Dec 13 11:02 2
anyone uses Nyx for tor ? Dec 12 15:22 1
torIRC TBB-9150 version via port 11009 as always Dec 12 15:16 2
please post your onion and uptime in UTC London time in this list Dec 12 10:22 1
update torIRC , TBB-9150 version via port 1801 instead of 11009 Dec 12 09:28 1
torIRC , TBB-9150 version via port 1801 instead of 11009 Dec 12 09:14 1
torIRC latest - TBB-9150 version via port 1801 instead of 11009 Dec 12 09:13 7
bm as hidden service with stem Dec 12 03:11 10
sent via API : torIRC9050.py Dec 11 12:59 1
run bm in cloud: https://mybinder.org Dec 11 09:12 6
BitText XHKhFPCDzj: ultimate bitmessage forum Dec 11 03:10 1
BitText LIST Dec 11 02:39 1
Jupyter BM notebook with py2.7 Dec 11 00:34 1
firewall vs. pyBM green mode Dec 10 09:33 8
BREXIT IS BULLSHIT Dec 10 02:34 3
run bm in cloud Dec 9 19:13 6
The Stallman Tax Dec 9 14:47 1
using eclipse for pyBM & github Dec 7 15:28 7
BM w/ GUI : Jupyter BM notebook Dec 7 15:19 10
BM in python3? Dec 6 17:52 8
Listen for incoming on Tor hidden service Dec 6 15:43 12
questionable attitude Dec 6 08:09 21
why are all the channels blank Dec 6 06:24 11
Feature idea Dec 5 23:53 5
include the mammoth into pyBM source code Dec 5 11:18 1
include the mammoth into pyBM source code Dec 5 11:15 2
running the 800+ chan super mammoth Dec 5 10:20 32
the myth of the "secret chans" on BM Dec 4 20:23 1
[chan] DevTalk Dec 4 20:13 6
Hacking Bitmessage Dec 4 19:11 3
The complete full mammoth "keys.dat" file - replace your KEYS.DAT in pyBitMessage with this 800+ chan text file -- run the super mammoth ! Dec 4 16:23 2
clean up pyBM github landing page Dec 3 20:28 14
audit - squash this lil bug Dec 3 20:04 1
Error Dec 3 18:47 1
34C3 Dec 3 18:44 3
48 Dirty Little Secrets Cryptographers Don't Want You to Know Dec 3 17:50 1
mailchuck = OK ; onionmail = problematic Dec 3 16:27 6
mammoth chan list .py Dec 3 06:53 3
SUPER MAMMOTH -- 806 unique BM chans in one keys.dat file Dec 3 01:39 1
questionable attitude web.archive.org/web/20171202215905/http://bitmessage.mybb.im/viewtopic.php?id=30%23p106 Dec 2 22:42 1
ACK : Persistence via Dead Letter drop clearnet access w/Op separation Dec 2 12:42 1
OMEGA release 39 is available for download Dec 2 05:15 1
I get no reply from mailchuck upon registration -- fixed ! all working again. Dec 2 02:13 4
beamstat.com is fucking fast to serve broadcasts Dec 2 01:47 1
27'000 users who use OnionMail - more than BM ? sure ... Dec 1 10:40 1
beamstat.com is fucking slow to serve broadcasts Dec 1 10:34 4
Patch 4 Dec 1 10:31 5
crowdfunding : whack Trump Dec 1 10:31 11
27'000 users who use OnionMail - more than BM ? Dec 1 07:16 10
dotsendack =True *** stealth mode Dec 1 07:16 5
Pubkey request Dec 1 07:15 6
NEW ! subscribe to this pml : BM-NB4TuMJmrHeo1p1FsfuMCrkZBUPGLjnq Dec 1 07:15 7
Bitmessage feature request for timing attack mitigation Dec 1 07:15 14
How to disable ack packets Nov 30 13:07 36
Easter egg Nov 30 12:13 2
I get no reply from mailchuck upon registration Nov 30 11:40 8
easy mailer , just add MX line in DNS Nov 30 10:59 2
Feature request Nov 30 08:44 3
Bitmessage to Shell Nov 30 05:01 4
Patch 3 Nov 30 04:36 1
Patch 2 Nov 30 04:32 1
Patch Nov 30 04:18 1
Long delay making connections Nov 29 09:44 25
onion mail Nov 29 00:56 1
Flatpak Linux Distribution for Bitmessage Nov 28 20:19 1
sue corporations like stman sues postal services Nov 28 13:11 1
backbone member Nov 28 13:10 9
pyBM light load even on old laptops Nov 28 07:37 2
BM now with ding dong Nov 27 03:05 3
encryptpad Nov 27 02:52 2
The Homosexual Perversion: A Jewish Criminal Simhke for the Postmodern Corporate Conformist Nov 25 03:04 1
where is latest mammoth BM chan list ? larger than beamstat.com ? Nov 24 12:21 3
wayback archive for beamstat Nov 24 01:35 2
Where is PyBitmessage git signing key fingerprint? Nov 23 23:10 16
pyBM eating too many cycles still ----- fixed ! much better ! Nov 23 22:06 1
I'm back. Nov 23 21:50 3
pyBM eating too many cycles still Nov 23 21:34 4
wikileaks vault 8 Nov 23 17:02 3
very few active chans Nov 23 01:10 17
audit BM via web GUI Nov 22 20:37 6
But I'm using Tor!! Nov 22 12:38 2
LUKS! Nov 22 12:12 1
New Bitmessage CLI Nov 22 00:22 2
mailchuck question Nov 21 08:52 2
Incoming connections Nov 21 02:18 5
(no subject) Nov 20 17:07 7
(no subject) Nov 20 13:14 4
BitMessage crash Nov 19 12:50 7
Alternative Bitmessage port for official assignment with IANA? Nov 19 08:28 5
Tor replacement Nov 18 23:04 5
codewordtest2 Nov 17 21:52 1