I think the reason why you are confused is that there are different lengths:
- base64 wallet string length
- JSON length (the above wallet, but base64 decoded)
- ct (ciphertext) / data length (this is also base64 encoded again)
The overall wallet file length (and therefore also the JSON length, whose lengths are related) could sometimes contain additional JSON fields/lkeys (as mentioned above the "fee", or installed directory etc)... so it's perfectly normal if the length and file size isn't always the same (even with the same installer and running software). It doesn't matter too much.
the only real important thing to us for now is the "ct" length, but the hashcat module supports quite large range of "ct" lengths (from 128 to 512 base64 characters for now).
it would be interesting to know what that encrypted "contacts" lists would normally look like... it could maybe be longer if the user made a lot of transactions or somehow stored some contacts etc... but this of course can only be seen when trying a heavily used wallet (I guess). maybe there also exists a test network where you can make some transactions / contacts for free, without spending any coins/money. dunno
Maybe this information can also be found out on the internet or when reading the rippex source code (I didn't investigate this yet).
The attachment (diff.txt) was basically a test change (diff / patch) included as base64 string within a shell script (that's why I said it needs to be run by bash or a shell). I did some tests and for me it doesn't seem to make much of a difference even with the precomputed lookup table. Instead, on my systems the speed of my current github branch is slightly better/faster on my systems (yeah, diff.txt would need to be applied on top of the github branch, an additional change).
update, I've now analyzed the above new wallet and the encrypted text ("ct") contains these additional fields:
so yeah, this doesn't really matter too much (the only problem would be if the ct length would be really very, very long. like > 512 bytes)
- base64 wallet string length
- JSON length (the above wallet, but base64 decoded)
- ct (ciphertext) / data length (this is also base64 encoded again)
The overall wallet file length (and therefore also the JSON length, whose lengths are related) could sometimes contain additional JSON fields/lkeys (as mentioned above the "fee", or installed directory etc)... so it's perfectly normal if the length and file size isn't always the same (even with the same installer and running software). It doesn't matter too much.
the only real important thing to us for now is the "ct" length, but the hashcat module supports quite large range of "ct" lengths (from 128 to 512 base64 characters for now).
it would be interesting to know what that encrypted "contacts" lists would normally look like... it could maybe be longer if the user made a lot of transactions or somehow stored some contacts etc... but this of course can only be seen when trying a heavily used wallet (I guess). maybe there also exists a test network where you can make some transactions / contacts for free, without spending any coins/money. dunno
Maybe this information can also be found out on the internet or when reading the rippex source code (I didn't investigate this yet).
The attachment (diff.txt) was basically a test change (diff / patch) included as base64 string within a shell script (that's why I said it needs to be run by bash or a shell). I did some tests and for me it doesn't seem to make much of a difference even with the precomputed lookup table. Instead, on my systems the speed of my current github branch is slightly better/faster on my systems (yeah, diff.txt would need to be applied on top of the github branch, an additional change).
update, I've now analyzed the above new wallet and the encrypted text ("ct") contains these additional fields:
Code:
"preferred_issuer":{},
"preferred_second_issuer":{}so yeah, this doesn't really matter too much (the only problem would be if the ct length would be really very, very long. like > 512 bytes)