Benjamin Diamond

@orignal can confirm that this works after building from source. BUT I still get segfaults, _only_ for RAW datagrams and _only_ after doing the static build given in [l-n-s /...

it WORKS after upgrading to openssl 1.0.2s, zlib 1.2.11, boost 1.61.0 and _also_ destroying the `lxc-testnet` folder and starting over. I think there might have been some stale files somewhere?...

I have one final question. I understand that RAW datagrams have no _from_ address. But could a _malicious_ server correlate the origins of two raw datagrams, if he _wanted to_?...

I see... Is there any way to prevent this? Since no response is needed, it seems like it should be possible to eliminate all identifying information.

@orignal what if the client includes `crypto.tagsToSend=1` in the list of `options` passed to [`NewRawSession`](https://bitbucket.org/benediamond/sam3/src/02821d226fb9a5d29003c4f562d3a10ceefc98b6/raw.go#lines-28)? i.e., ```go rs, err := sam.NewRawSession("RawserverTun", keys, []string{"inbound.length=0", "outbound.length=0", "inbound.lengthVariance=0", "outbound.lengthVariance=0", "inbound.quantity=1", "outbound.quantity=1", "crypto.tagsToSend=1"}, 0)...

I see, so would subsequent communications indeed be unlinkable in this case?

> so in the future it MAY be tolerable. Interesting. Just want to confirm though that under this circumstance it will become impossible to link even for a _malicious_ server.

> what if the client includes `crypto.tagsToSend=1` in the list of `options` passed to [`NewRawSession`](https://bitbucket.org/benediamond/sam3/src/02821d226fb9a5d29003c4f562d3a10ceefc98b6/raw.go#lines-28)? correction: `crypto.tagsToSend=0` is the right approach! after all, this list of tags is _in addition...

Конечно, я понимаю что скорость исполнения будет медленнее, но во многих ситуациях, полная анонимность во всех коммуникациях это оправдывает.

Похоже что в `kallevedin`'s `sam3` библиотеке нет поддержки для `TRANSIENT` keys + `SIGNATURE_TYPE` параметра. Наверно мне придётся написать это самому... I noticed another strange bug. When the process has both...