Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519
David Goulet writes: > [ text/plain ] > On 15 Nov (16:29:33), George Kadianakis wrote: >> Nick Mathewson writes: >> >> >> >> Hello, >> >> I worked some more on prop224 client authorization. I have a draft >> torspec patch at prop224_client_auth_3 in my repo: >> >> https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop224_client_auth_3 > > I personally like this very much. Apart from minor syntax issues and spacing, > I think this scheme is getting to a point where it's simple and efficient. > > I think the introduce auth section (INTRO-AUTH) needs to be edited more though > because we are still mentionning password and ed25519 authentication but I > understand that waiting until we all agree on the client auth mechanism is > wise. > >> >> I ended up using the x25519 scheme described above by Nick. >> >> I also ended up dodging the UX questions raised on this thread, by only >> specifying the Tor protocol level details, and leaving the out-of-band >> HS<->client protocol mostly unspecified. I believe that this out-of-band >> protocol and configuration details can be figured out in the future, and >> we should not block on them right now. > > Yes, I believe this is fine. Note that tor-keygen tool is getting another > _very_ important use case here that is the key generation on client side. > >> >> I also added some more high-level details on client auth in the intro >> section, which should be useful to people who read the proposal for the >> first time. >> >> In the appendix, I added a section with some rough ideas on how the >> torrc configuration could work, and how a control port interface could >> work. This is just a sketch so far, and we can get more specific as we >> get closer to implementation fot this feature. > > Looks good to me. The naming will _most_ probably change as we already have > those names in torrc with a different API but the format to me is simple and > easy to use. > > And the control port commands are _very_ important as it would allow TBB to > easily add client auth with some UI instead of hot hacking torrc file. And > this would be a giant step foward in usability of client auth. > >> >> Finally, I've been assuming AES128 for the STREAM() cipher so that the >> size computations performed earlier on this thread are still >> accurate. If we want to pump it to AES256, the IVs and the descriptor >> cookie ciphertexts will double in size for each authorized client. If we >> actually want to go with AES256, we need to peform new computations >> about the padding and max descriptor size. If you people like the rest >> of the patch here, I can do the calculations again. > > Which might also change our maximum size of 40k we put there. > > One note. I haven't seen a maximum value of client we allow. Did I miss it or > it's also maybe too early to put there as we are still discussing the > specifics. Which makes me think that maybe that 40k limit is also a bit > arbitrary for now based on that. > Hello, I understand your concern, and hence I performed the descriptor size calculations again based on the encoding format of the latest branch (prop224_client_auth_3). You asked for it! First of all, in the end of this email I inline a real prop224 HS descriptor based on the prop224_client_auth_3 torspec branch, and _without any encryption_. Use that descriptor as a guidance, or to double-check my calculations. To cut to the chase, here are my current recommendations regarding descriptor padding and maximum size: - The superencrypted blob (between "superencrypted\n-BEGIN MESSAGE-" and "-END MESSAGE-") should be padded with NULs to the nearest multiple of 10k bytes before it gets encrypted and base64ed. This is the same as what is specified in prop224_client_auth3. - Max total descriptor size accepted by HSDirs is 50k bytes. We should also control this with a consensus parameter, in case it ever ends up being too small or too big. In prop224_client_auth_3 it is suggested that the max size should be 40k bytes, but actually I think 50k bytes is a better number given the new scheme and the 10k padding. Please see below. - We always add fake "auth-client" entries to reach the nearest multiple of 16. Now here are some observations: a) The superencrypted blob gets padded to nearest multiple of 10k bytes before it gets base64ed. If you base64-encode 30k bytes you get back 40k base64 bytes, which is basically the max size of superencrypted blob we can support if the max descriptor size is 50k bytes. The remaining 10k bytes are left for the unencrypted header (and footer) of the descriptor which in the example below is 400 bytes. b) Every new intro point block adds about 615 bytes to the blob, whereas legacy intro points add about 870 bytes to the blob. For the sake of calculations, let's average that to 750 bytes per intro point. Every authed client adds 75 bytes to the superencrypted part of the descriptor.
Re: [tor-dev] Browsers, VMs and Targeted Hardware Bit-Flips
On 2016-11-18 00:03, teor wrote: Hi all, There have been a series of recent attacks that take advantage of "rowhammer" (a RAM hardware bit-flipping vulnerability) to flip bits in security-critical data structures. VMs sharing the same physical RAM are vulnerable, and browsers and mobile apps are remote vectors with proof-of-concept implementations. Rowhammer summary: https://en.wikipedia.org/wiki/Row_hammer An attack that flips targeted bits in another virtual machine on the same physical RAM, targeting OpenSSH public keys, GPG public keys, and Debian package sources: https://www.vusec.net/projects/flip-feng-shui/ A similar proof-of-concept Android app: https://www.vusec.net/projects/drammer/ A JavaScript-based in-browser remote proof-of-concept: https://arxiv.org/pdf/1507.06955v1.pdf It seems like a short step from these existing attacks to targeting Tor Browser users remotely. I wonder whether it might be possible to target relays (or clients) using OR cells or directory documents with specific content, but this seems much less likely. I have been thinking about how we could make Tor (and browsers, and other processes, and OSs) less vulnerable to these kinds of attacks. In general, some of the process-level defences against one or more of the above attacks are: * sign or checksum all security-critical data structures, * implement and check cross-certification, * don't rely on cached checks (or checks performed at load time) continuing to be accurate, * minimise time between checking validity and using the data, (this includes signatures, checksums, data structure consistency) * make the content of memory pages (including loaded files) less predictable, * make sure the hamming distance between trusted, valid inputs and untrusted, valid inputs is large, in particular: * register domains that are one bit-flip away from trusted domains, (or, alternately, mandate SSL, and pin certificates, and fix broken CA roots) Some of the OS-level defences are: * turn off memory deduplication, * write and verify checksums on each page, Some of the firmware/hardware defences are: * increase the RAM refresh rate, * improve RAM design, * use ECC RAM. T We've been keeping track of these attack classes on hypervisors: https://www.whonix.org/wiki/Advanced_Attacks https://www.whonix.org/wiki/KVM#Unsafe_Features Its great to design software that's resistant to adversarial conditions anyhow. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Distributed RNG Research
New research on Distributed RNGs is published: "Scalable Bias-Resistant Distributed Randomness" eprint.iacr.org/2016/1067 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
