[tor-talk] A Pluggable Transport based on i2p?

m.ajiao at tuta.io m.ajiao at tuta.io
Sat Mar 25 03:14:17 UTC 2017


Unfortunately even after a lot of trying, I was unable to reproduce the seg fault, but I did discover that I2Pd's SAM protocol parser [1] is kind of broken.

[1] SAM protocol parameter parser: https://github.com/PurpleI2P/i2pd/blob/ace16d473f9c7a2eda1b0e6691f11ad2cfc9ba3b/SAM.cpp#L562

'NAMING LOOKUP NAME=zzz.i2p\x20\n' If you don't type a trailing space, the naming lookup command fails.

SESSION CREATE STYLE={STREAM,DATAGRAM,RAW} ID=$nickname DESTINATION={$privkey,TRANSIENT}

> The $privkey is the base 64 of the concatenation of the Destination followed by the Private Key followed by the Signing Private Key, which is 663 or more bytes in binary and 884 or more bytes in base 64, depending on signature type.

> If the destination is specified as TRANSIENT, the SAM bridge creates a new destination.

In this interesting case, if you type in the parameters exactly in that order, and use 'DESTINATION=TRANSIENT' but you forgot to add a trailing space, you will get a private key full of A's.

I don't know if a private key full of A's is secure. Fortunately i2p.socket SAM protocol wrapper places the parameters in a different order.

I reported to their dev forum and Orignal, the dev, replied:
> DESTINATION=TRANSIENT# sure gives you bunch of AAAA because it's considered as destination.
I agree I should return an error in this case.

Basically he meant as the opposite of the spec, I2Pd will try to parse the bytes 'TRANSIENT' as a private key, rather than regarding it as a keyword.

Detailed discussion here: https://zzz.i2p.rocks/topics/2266-seriously-why-are-there-so-many-a-s-in-my-destination

Cheers,
MJ

==========
Response format from I2Pd:

Session Creation Response
If the creation was successful:

<-  SESSION STATUS RESULT=OK DESTINATION=$privkey

The $privkey is the base 64 of the concatenation of the Destination [1] followed by the Private Key [2] followed by the Signing Private Key [3], which is 663 or more bytes in binary and 884 or more bytes in base 64, depending on signature type. The binary format is specified in Private Key File.

[1] Destination: https://i2p-projekt.i2p.rocks/en/docs/spec/common-structures#type_Destination
[2] Private Key: https://i2p-projekt.i2p.rocks/en/docs/spec/common-structures#type_PrivateKey
[3] Signing Private Key:  https://i2p-projekt.i2p.rocks/en/docs/spec/common-structures#type_SigningPrivateKey

==========
Here I attached two responses I got from I2Pd SAM protocol. To help you see special characters easily, I escaped the messages in python repr format.

I sent: 'SESSION CREATE STYLE=STREAM ID=This_is_another_test DESTINATION=TRANSIENT\n'
Here is a sample response I got from I2Pd:
'SESSION STATUS RESULT=OK DESTINATION=YXZhaWxhYmyRAAAAAAAAAPgAAEBsfwAA-AAAQGx~AAAAAAAAAAAAACEAAAAAAAAA8FwOQGx~AADwNgVAbH8AAEAAAAAAAAAAJAAAAAAAAAAAAAAAAAAAAP~~~~~~~~~~AAAAAAAAAAAxAAAAAAAAAEBBDkBsfwAAmAAAQGx~AAAAAAAAAAAAAAAAAAAAAAAAsAAAAAAAAAA0AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPL6MXZigrg5AbH8AAGCtDkBsfwAABAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACYDkBsfwAAAJgOQGx~AAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHNpq0-TtHaiDbgcPTpkPRgAAAAAAAAAAECYDkBsfwAAezQsqUpfqWvbp7mvgco8UYFopzAk24PEUQPYPL6MXZgeeGoHVCfDbI-AesMOSkaSKr79fw5lfrtfZqaH4er7H5t3qv~PUGmTQNATUE6aVcIFBgFaC2N~4VQF2Wa17yJ5QOQcKo-0dbnPZGbpgf4zKwm9wjCvCUBsfwAAIK8JQGx~AADgxQlA\n'

I sent: 'SESSION CREATE STYLE=STREAM ID=Test3 DESTINATION=TRANSIENT\n'
I got: 'SESSION STATUS RESULT=OK DESTINATION=bmdtYXF4aGU2NmU0cXdlY25uZXo1anVqN2xuaHV1ZWp6NWJxAAAAABECAAAAAAAAeAIAcBB~AAB4AgBwEH8AAGFsIGFkZHJlc3MgNzRkcjJuNGptNjJsdDJkam5nbWFxeGhlNjZlNHF3ZWNubmV6NWp1ajdsbmh1dWVqejVicSBjcmVhdGVkAAAAAAAAAAAAAAAAAAAAAABAhYWmEH8AAP~~~~8AAAAABF0AO6nHk0YAAH0jkfxTFGBvAHAQfwAA~~~~~~~~~~9dHB2egX5kn3BvAHAQfwAAAAAAAAAAAAB6-eruJYPKWNk5NHnmSmHzAAAAAIo45YH8uhiWgs5cqo-00U1ac~eO4GaFphB~AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcBB~AAAAAAAAAAAAAAAAAAAAAAAAJQAAAAAAAAAgUwBwEH8AAAAAAAAAAAAAAAAAAAAAAAAlAAAAAAAAAEBTAHAQfwAAAAAAAAAAAAAAAAAAAAAAACUAAAAAAAAAwFIAcBB~AAAAAAAAAAAAAAAAAAAAAAAAJQAAAAAAAAD1aj3DwnHyAvB8WQIAAAAAAAAAAAAAAAAlAAAAAAAAAKBTAHAQfwAAAAAAAAAAAAAAAAAAAAAAACUAAAAAAAAA4FIAcBB~AAAAAAAAAAAAAAAAAAAAAAAAJQAAAAAAAACQUABwEH8AAAAAAAAAAAAAAAAAAAAAAACxAQAAAAAAABgCAKyDN7MaY-R8zEC9aydTBCYIHhkW\n'



More information about the tor-talk mailing list