← | Results 251 ... 500 found in all logged channels for 'f:zx2c4' | →
(trilema) zx2c4: zmap came out in 2013
(trilema) zx2c4: ahh 2013 nice
(trilema) zx2c4: mircea_popescu: when did you first publish your research?
(trilema) zx2c4: oh. is your beef that you were masscanning the net first, and then these other people stole your idea and ran with it?
(trilema) zx2c4: nadia's research is quite real
(trilema) zx2c4: ahh looks like hanno has called y'all out on this?
(trilema) zx2c4: just messin
(trilema) zx2c4: MY GPG KEY IS IN HERE
(trilema) zx2c4: you found a gpg key with obvious primes or something?
(trilema) zx2c4: mircea_popescu: this sounds vaguely familiar
(trilema) zx2c4: ahh you saw this then
(trilema) zx2c4: enjoyable to read conspiracy theorizing from well qualified academics
(trilema) zx2c4: re:your ECC skepticism and RSA-love -- a while back the NSA changed the Suite B recommendations to partially remove ECC for new crypto systems and also removed P256 IIRC. There was a great paper analyzing what the possible motivations could be, i think called 'an enigma inside a riddle' or something goofy like that. Let me find it...
(trilema) zx2c4: mircea_popescu: by the way ive wanted to dig this up for you the last two weeks and keep forgetting
(trilema) zx2c4: and then got super busy
(trilema) zx2c4: oh, no, not at all -- just popped out fora few days
(trilema) zx2c4: mircea_popescu: so if the consulting demands suddenly disappeared forever, im quite sure great things would come
(trilema) zx2c4: mircea_popescu: sure i can save a little. but the point is that the more i hustle consulting, the less time i have for making more valuable contributions to the world, like developing new crypto
(trilema) zx2c4: but again, does not yield floweringsums
(trilema) zx2c4: mircea_popescu: interesting re:gentoo. im a gentoo developer
(trilema) zx2c4: mircea_popescu: yea consulting is what ive been doing for over a decade now
(trilema) zx2c4: mircea_popescu: well seems pretty clear that the future doing what im doing now is unlikely to yield aforementioned flowering sums of 2000btc (unless of course bitcoin tanks), unless a philanthropist comes along
(trilema) zx2c4: mircea_popescu: http://btcbase.org/log/2018-04-14#1799145 i dunno if i had any pull-y things in mind. im not making a product or anything. just designing secure protocols and implementations and hoping something comes out of it
(trilema) zx2c4: * shrug *
(trilema) zx2c4: your guess about secret government conspiracies is as good as mine? some people think they are vast; others think they are small. some think ecc; others think rsa; some think jfk; others think apollo. ...
(trilema) zx2c4: healthy assumption to live by. so again, my response to that kind of thing is, "meh"
(trilema) zx2c4: if secret government scientists are lightyears ahead of "entirely worthless" academics, and they have secret attacks on everything academia is currently okay with, then i guess it's game over, and we have to wait until we're at a ripe old age to read the history books on the secret mathematics of our present age. i dont really share this point of view though. and even aside from the factual validity of it, it doesn't seem like a psychologically
(trilema) zx2c4: then crypto is doomed?
(trilema) zx2c4: mircea_popescu: so from your mention of "criminal org" it seems to me that your concern is not so much the mathematical issues that are discussed in the literature, but rather a particular history that to you indicates there must be secret attacks that only the select few geniuses at the nsa know about, and everybody pushing ecc is either in on the conspiracy or just dumber than the nsa geniuses. i guess you're entitled to this opinion -- what's
(trilema) zx2c4: one man's hunch vs another man's? but there has been a lot a lot a lot of open academic analysis on ecc for many years now and this alleged smoking gun still has not been found. so, meh.
(trilema) zx2c4: lemme see if im remembering correctly...
(trilema) zx2c4: i think cloudflare has an ELI5 article from a few years back about "what all the key sizes doth mean"
(trilema) zx2c4: mircea_popescu: i take it now that mostly you're skeptical because the nsa was pushing ecc in the early years, before everyone else woke up to it
(trilema) zx2c4: mircea_popescu: ahh that ignorant and antiquated notion, that "key size implies security size". or do you think there will be some amazing GNFS-like algorithms that come out for ECC, requiring ECC to use absurdly huge keys in the same way as RSA?
(trilema) zx2c4: mircea_popescu: the keys in ECC are smaller. if your position is that this cant possibly mean it's more secure than RSA, then i suppose the actual claim you're making is that 'ECC with ECC-sized keys is less secure than RSA with RSA-sized keys'. what's the basis for this?
(trilema) zx2c4: claim, if that's the one you're implying
(trilema) zx2c4: all of them? some of the advantages are indisputable like key size and computation speed and implementation ease. im guessing you dont believe there's a security advantage over RSA? you're not soothed by the fact that many attacks against RSA dont work with ECC? okay, but that still doesn't discredit the indisputable advantages. so then maybe your position is that ECC has _weaker_ security than RSA for various reasons? that'd be a more interesting
(trilema) zx2c4: mircea_popescu: im curious -- why are you so bent on RSA? ECC has been around for quite some time now and has numerous advantages
(trilema) zx2c4: (quoted from your link)
(trilema) zx2c4: sha256 isnt an encryption function. also beware this construction, especially the second one where the string comes last -- length extension is a problem with sha2
(trilema) zx2c4: > For a functional example consider node A, whose "encryption" mechanism consists of sha256(string+"hurr"), and node B, whose encryption mechanism consists of sha256("durr"+string.).
(trilema) zx2c4: always swirling data around, so not only do you not know who's talking when, but you don't know who's talking to whom
(trilema) zx2c4: mircea_popescu: the more interesting approach to foiling that kind of traffic analysis is the general topic of mixnets
(trilema) zx2c4: oh, the most serene acronym, shoulda known
(trilema) zx2c4: tmsr? gossipd?
(trilema) zx2c4: (or even general purpose utilities that could ostensibly work over any link)
(trilema) zx2c4: mircea_popescu: and i think having that kind of thing always on -- constant chattiness -- would be a security step backwards, since it'd give up stealthiness. but of course if you still wanted it for a special use case, there's nothing in wireguard preventing you from having it pretty easily
(trilema) zx2c4: mircea_popescu: wireguard isnt a library. its a virtual network interface that tunnels ip packets. what im pointing out is that your suggestion implies that both sides must _keep_ talking always, since thats the only way to obscure termination messages.
(trilema) zx2c4: mircea_popescu: re:rand(20,200) - sorry. random number of bytes is all i was going for. (an ip header is 20 bytes, so you'd probably want to bound it at that. and 200 seems like a reasonable cut off. but of course we could keep engineering and designing that sort of thing and come up with different numbers.)
(trilema) zx2c4: mircea_popescu: if what you mean is rather than sending an empty packet, i should instead rand(20,200) zero bytes encrypted, then i wonder what this would accomplish. the other side now receives this. if it's a keepalive message (which it knows after decryption), then it goes silent. if it's not, then it either responds with whatever is appropriate to respond to that, or if it has nothing to say, it would have to send a keepalive too. in
(trilema) zx2c4: intervals relative to the amount of existing traffic. i wouldnt be surprised if something like this already exists.
(trilema) zx2c4: on that, instead preferring to be "stealthy" and "silent" when not in use. this naturally reveals when communications happen, but it also makes the endpoints undiscoverable when theyre not talking. also, it'd be easy to build that kind of 'always chatting' logic into whatever specific application you need to conceal. or, alternatively, simply write an additional utility that sits on top of wireguard that sends junk back and forth at quasi random
(trilema) zx2c4: otherwords, an attacker still knows that the protocol has gone silent, because one side will stop responding. it sounds to me like what you would prefer is for both sides always to be talking and chatting -- always, and with garbage when not with real data -- to trip of traffic analysis. that's a legitimate desire, and there are many other additional things can add to protocols to further trip up traffic analysis. wireguard distinctly isn't focused
(trilema) zx2c4: the time?
(trilema) zx2c4: mircea_popescu: let's take a protocol that just encrypts ip packets and nothing more. traffic analysis of the size of packets gives you something, especially in the case of TCP where there are necessary types of responses at various points. but i suppose you want me to consider "general purpose cases". so im thinking about a raw UDP protocol. in this case, it might be that at the end of an exchange, one side has nothing more to say, and so it says
(trilema) zx2c4: not reveal?
(trilema) zx2c4: nothing. alternatively, it sends a bunch of garbage data at random points to trip up traffic analysis. now introduce the wireguard final-confirmation keepalive. one side has nothing more to say, yet it just now received a message from the other side. rather than sending nothing, wireguard now sends a single length 0 message. after that, both sides are entirely silent. what does the sending of that length 0 message reveal that sending nothing would
(trilema) zx2c4: mircea_popescu: im trying to apply what you said to IP
(trilema) zx2c4: these are broad and hand-wavy. im trying to find some real meat here to analyse
(trilema) zx2c4: mircea_popescu: could you elaborate your argument on why you think the 0 response is different from the 16, 32, 48, etc response? spare me the hand-wavy "its always an invariant!" arguments. can you give some real security analysis of what you have in mind? am willing to take your concern seriously if theres a good case for it
(trilema) zx2c4: im being interrupted now, but ill be back in a while to continue this
(trilema) zx2c4: not sure i have the same interpretation of phaedo as you
(trilema) zx2c4: i enjoy plato most
(trilema) zx2c4: yea, sure, im pretty certain of what it'd take to be financially viable in either philosophy or jazz music. that's not something universally available and there's a lot of luck involved, however, and even then it's a pretty rough life. it's not even available to all types of philosophy study and all types of jazz music.
(trilema) zx2c4: i'm not saying everyone with leisure _does_ do something worthwhile with it. but you cant deny that leisure is in many cases a necessary precondition for many great aspects of civilization
(trilema) zx2c4: for example, i've spent my life studying greek philosophy and playing jazz music, and it doesn't pay anything. hence programming. but the economics of those activities doesn't really relate to their quality or importance
(trilema) zx2c4: i don't think so. plenty of people with the necessary leisure study or create literature, philosophy, music, art -- great aspects of civilization for which there isn't always an immediate economic incentive
(trilema) zx2c4: some rich kids seem to use their funds to pursue interesting things and deepen their character with those experiences. others waste away their time.
(trilema) zx2c4: great seinfeld episode
(trilema) zx2c4: not sure
(trilema) zx2c4: the point is that the grandson rarely has problems answering correctly to too many questions that necessitate correct responses
(trilema) zx2c4: one difference is that the ruins aren't people, not that they are, obviously. not sure i'm getting your rhetorical point...
(trilema) zx2c4: i know a lot of rich people with trust funds set up by their ancestors. they receive fixed income every month, and otherwise aren't hassled
(trilema) zx2c4: that seems fine
(trilema) zx2c4: how does that necessarily lead to "being stupid"? what if i just choose to raise a boring family and live a boring life?
(trilema) zx2c4: the reason is actually, "so that i can have a fixed income without any concrete labor obligations"
(trilema) zx2c4: but it clearly doesn't happen with _all people_
(trilema) zx2c4: i realize that's the classic trope -- it's the kind of thing you read about all the time
(trilema) zx2c4: i dont think it'd translate into any kind of significant "power beyond my means"
(trilema) zx2c4: i'm pretty certain no calamity would come of it...
(trilema) zx2c4: oh, i really don't think that'd be the case
(trilema) zx2c4: the latter point -- because you suppose i'd convert it to EUR and that'd harm BTC in general?
(trilema) zx2c4: to put differently, if 2000 BTC suddenly showed up in 1ASnTs4UjXKR8tHnLi9yG42n42hbFYV2um, I'd be quite happy and don't think i'd be worse off
(trilema) zx2c4: i'd be wary of any 'deal' that's different from: 'i'm given money. you're given warm feelings of having helped the internet.'
(trilema) zx2c4: but interesting read nonetheless
(trilema) zx2c4: i still dont see how this applies to my situation,
(trilema) zx2c4: mircea_popescu: this article is about making a company right? i'm not doing that. im just writing painstaking careful code and giving it to the world for free
(trilema) zx2c4: how come?
(trilema) zx2c4: proper funding would mean fewer "suckers"
(trilema) zx2c4: rare occurrence with FLOSS though
(trilema) zx2c4: which is why real funding for wireguard would be so much better
(trilema) zx2c4: large part of the student motivation is the mentoring, i suppose
(trilema) zx2c4: yea. it pays worse than real internships. so the pool of students willing to do it is smaller than what you'd wish
(trilema) zx2c4: mostly really under-qualified applicants. but if you already know students who are smart, or have some better means of reaching out to them than just the gsoc landing page, then it's possible to hand select people you'd like to work on stuff, and give them summer funding.
(trilema) zx2c4: mircea_popescu: for the most part, though trying to get some interns this summer via GSoC
(trilema) zx2c4: so, slightly more disappointing of a prospect
(trilema) zx2c4: i wasn't planning on immortality, but if you say so...
(trilema) zx2c4: i like systems programming in crypto
(trilema) zx2c4: mircea_popescu: some time, though of course not enough to support a whole project for a whole year. i'm wondering about great flowering riches
(trilema) zx2c4: my daddy is /proc/kcore and he's connected to a debugger.
(trilema) zx2c4: wondering - how might i achieve great wealth and donations for wireguard from you/trilema?
(trilema) zx2c4: it does go
(trilema) zx2c4: hello mircea_popescu
(trilema) zx2c4: mircea_popescu: asciilifeform: http://btcbase.org/log/2018-04-12#1797528 http://btcbase.org/log/2018-04-12#1797506 -- in case you're interested in the ecc stuff more, the formally verified fiat and hacl implementations are not the only ones we have. we also have constant time accelerated x86 adx and bmi2 implementations https://git.zx2c4.com/WireGuard/tree/src/crypto/curve25519-x86_64.h and also constant time accelerated arm neon implementations
(trilema) zx2c4: spyked: http://btcbase.org/log/2018-04-12#1797801 tamarin (and cryptoverif and proverif) spit out the proof too. tamarin has a nice mode that will draw diagrams and flow charts too to make it easier to digest the proofs. people even have scripts to convert the output into latex in case you want an academic paper for free...
(trilema) zx2c4: asciilifeform: http://btcbase.org/log/2018-04-12#1797645 it's based on chacha but was actually developed by aumasson and co
(trilema) zx2c4: asciilifeform: http://btcbase.org/log/2018-04-12#1797596 obviously aes has quite a bit of structure too, but there's a difference
(trilema) zx2c4: mircea_popescu: http://btcbase.org/log/2018-04-12#1797532 why stronger than i realize?
(trilema) zx2c4: alright, ttyl guys
(trilema) zx2c4: ooo scoped pointers. thats nice
(trilema) zx2c4: but ill idle in here for a while and will be back in several hours mostlikely
(trilema) zx2c4: i need to head out for a bit now
(trilema) zx2c4: ill give ada a look. ive long heard about it but never dived in
(trilema) zx2c4: hah i like that
(trilema) zx2c4: so most checking is runtime instead of compile time then?
(trilema) zx2c4: performance is good?
(trilema) zx2c4: sounds great
(trilema) zx2c4: linus has never been so happy about other languages in the kernel. for example, he rejected a C++ layer many years ago
(trilema) zx2c4: i dont have enough exposure to ada to say for certain. how come?
(trilema) zx2c4: unlikely that'd make it upstream if i did wireguard that way, but neat that that's possible
(trilema) zx2c4: ada kernel modules? cool
(trilema) zx2c4: that are userspace based
(trilema) zx2c4: we've also got implementations in Rust and Go
(trilema) zx2c4: kernel for performance and integration reasons
(trilema) zx2c4: it's written in C because its in the linux kernel, which is written in C
(trilema) zx2c4: you guys have invented lots of things here
(trilema) zx2c4: thats an interesting consideration
(trilema) zx2c4: i suppose your point is that you _could_ choose to obscure the lengths of the messages youre sending back? whereas with zero that isnt a possibility?
(trilema) zx2c4: with many TCP protocols you can infer what's behind it based on the length
(trilema) zx2c4: what is it?
(trilema) zx2c4: i havent seen v
(trilema) zx2c4: why do you think zero is a special case?
(trilema) zx2c4 shakes head no
(trilema) zx2c4: (that way you give nothing, except your mtu)
(trilema) zx2c4: this may indeed be too large of an infoleak and you'd prefer a different padding scheme like always filling the entire MTU
(trilema) zx2c4: mircea_popescu: padded protocols infoleak in multiples of the padding. you get to see if a given packet elicited a 0 reply, a 16 reply, a 32 reply, a 48 reply, and so forth
(trilema) zx2c4: mircea_popescu: see logs
(trilema) zx2c4: transport layer is all symmetric crypto
(trilema) zx2c4: the ecc is constant time. but anyway the transport layer doesnt use any ecc
(trilema) zx2c4: then thoes keepalives are in response to some message he received
(trilema) zx2c4: you might be misunderstanding. when nothing is being sent at all, keepalives arent sent. simply no packets are sent
(trilema) zx2c4: mircea_popescu: an attacker can also distinguish between a length 15 message and a length 31 message. i still maintain this doesnt give an attacker anything useful
(trilema) zx2c4: there _are_ attacks, on say voice compression algorithms, which can gather some information from having precise sizes alone, which is why things are padded to nearest 16. but i dont see what would be gathered by what youre suggesting
(trilema) zx2c4: what is the attack here?
(trilema) zx2c4: what do you get by knowing from inference that it's a keepalive?
(trilema) zx2c4: so you can do traffic analysis on 16 byte chunks
(trilema) zx2c4: thats right. the padding only happens in multiples of 16
(trilema) zx2c4: normally 8+16 (though wireguard pads to nearest 16)
(trilema) zx2c4: no, i dont think sending a random string would make it more secure
(trilema) zx2c4: when you encrypt a message of 0 bytes, you get 0 bytes of ciphertext + 16 bytes of authentication tag
(trilema) zx2c4: normally when you encrypt a message of 32 bytes, you get 32 bytes of cipher text + 16 bytes of authentication tag
(trilema) zx2c4: im not seeing the vulnerability youre speaking about
(trilema) zx2c4: in otherwords, the empty plaintext is still a valid value to be authenticated-encrypted
(trilema) zx2c4: yea. the plaintext is empty. but the ciphertext is not, since it's authenticated
(trilema) zx2c4: (usually said messages contain an IP packet)
(trilema) zx2c4: because all i need is the valid authtag/nonce. i dont have any actual content to put in there
(trilema) zx2c4: in this case, its important that you send me a keepalive, so that i know you at least got it. however, these keepalives arent persistent. if subsequently, i have nothing more to say to you, then we both go silent and dont say anything.
(trilema) zx2c4: every time i send you something, i expect to hear back from you. if i dont hear back from you, then something bad has happened,and i should start over with a new handshake. my way of hearing back to you might be in the natural sense -- i send a TCP SYN, you send me back a TCP ACK -- or it might be the case that you actually just have nothing to send back to me. you got my message just fine, but really just cant think of anything to say back to me.
(trilema) zx2c4: oh. good question
(trilema) zx2c4: empty message when heartbeat fails? huh?
(trilema) zx2c4: also, btw, when you're not using the payload parameter in a message, it's just set to empty, because the authentication tag used by it is still important for the protocol.
(trilema) zx2c4: i remember asking for this on the mailing list at some point
(trilema) zx2c4: which is why trevor explicitly spells it out
(trilema) zx2c4: pretty unlikely that somebody would design a protocol inadvertently that way
(trilema) zx2c4: important to then know what level of confidentiality you get there
(trilema) zx2c4: one thing to keep in mind is that Noise isn't a single ready-made protocol for every application designer to take. its instead a protocol framework for protocol designers to use. knowing explicitly what the payload param gives you in each message is really important, so that you dont screw up and put your stuff somewhere it shouldnt be. there are legitimate protocol use cases for using the payload parameter early on during the handshake. its
(trilema) zx2c4: because IPsec's null cipher mode is for transport data. what youre asking about with 7.4 is the payload parameter of the handshake messages
(trilema) zx2c4: its not about LoC either.
(trilema) zx2c4: this is not the case of the "null mode" in IPsec, which is obviously a complete disaster with no good justification
(trilema) zx2c4: there are valid use cases of sending information in the clear in the payload parameter. for example, perhaps you want to use it to advertise which aspects of the protocol are valid for subsequent messages. or you want to send a certificate along to authenticate yourself. the payload parameter certainly shouldnt be confused with transport messages, which are what are allowed after the handshake completes
(trilema) zx2c4: sorry, new here ;-)
(trilema) zx2c4: !!v CFFE7CEB6795F523B137AA9A9B0C8A20024FF0EED10EEF7C649C81591CF9DDE1
(trilema) zx2c4: its not an "unsecured mode" because this isnt a "mode"
(trilema) zx2c4: but there's certainly not any "null-ciphering" and this is only a misunderstanding of what the specification says
(trilema) zx2c4: this is spelled out explicitly in the section you mentiond
(trilema) zx2c4: noise defines several different handshakes. wireguard uses Noise_IKpsk2, which is 1-RTT. But there are other noise handshakes, some of which are 0-RTT, 1-RTT, 2-RTT, 1.5-RTT, and so forth. each handshake message can optionally contain a payload -- to contain things like, say, certificates or other data. the question is at which stage of the handshake do you use the payload parameter? if you do it too early in some, you get zero confidentiality. so
(trilema) zx2c4: oh, okay
(trilema) zx2c4: 0-RTT, 1-RTT, 2-RTT, and so forth
(trilema) zx2c4: but there are other noise handshakes
(trilema) zx2c4: which is 1-RTT
(trilema) zx2c4: wireguard uses Noise_IKpsk2
(trilema) zx2c4: noise defines several different handshakes
(trilema) zx2c4: oh, that's not quite what that's about
(trilema) zx2c4: a null cipher mode? it doesnt...
(trilema) zx2c4: Noise is from Trevor Perrin. I've been very involved in contributing to the project though (i mentioned at the end of the specification)
(trilema) zx2c4: oh good, okay
(trilema) zx2c4: well im still around here for another half hour or so, so feel free to lob anything more at me
(trilema) zx2c4: well, feel free to keep filling up my wallet, say, with thousands of coins O_o
(trilema) zx2c4: interesting
(trilema) zx2c4: i wonder if that verification worked i just posted
(trilema) zx2c4: !!v 613368773AD31E2D4F1A68F8F740BE5AE18F5C46924FB8C9C3CC2084E52C6D4D
(trilema) zx2c4: im guessing deedbot will send me a otp now
(trilema) zx2c4: lets see if that works
(trilema) zx2c4: !!withdraw 1 1ASnTs4UjXKR8tHnLi9yG42n42hbFYV2um
(trilema) zx2c4: interesting
(trilema) zx2c4: if you guys wind up using wireguard for part of your infra and want to support wireguard for a year, i'm always looking for large donations, etc. not sure if that's what deedbot is for exactly but that would be quite the nice deed
(trilema) zx2c4: horrah! thanks
(trilema) zx2c4: makes more sense
(trilema) zx2c4: oh, gotcha
(trilema) zx2c4: no, not at all. im also not quite sure what to do with these pgp encrypted blobs i cant decrypt
(trilema) zx2c4: asciilifeform: oh, okay. im happy to keep going though. and if you want to be uncivilized, ill gladly accept any harshness you want to throw my way. i dont scare easilyt
(trilema) zx2c4: mircea_popescu: no, thought it was quite productive actually
(trilema) zx2c4: ill try it in public here instead
(trilema) zx2c4: i tried registering my key privately to deedbot but it didnt respond
(trilema) zx2c4: we've been going at it for a while here
(trilema) zx2c4: hello mircea_popescu
(trilema) zx2c4: seems like lots of things these days have testimonials
(trilema) zx2c4: i havent compiled a list of Name+WrittenReview. maybe i should do that
(trilema) zx2c4: and then since several other colleagues and cryptographers have reviewed the system favorably
(trilema) zx2c4: then in the acknowledgement of the paper, a few others arementioned who reviewed it while it was being written
(trilema) zx2c4: i dont think they post the reviews? except that it was "accepted" to the conference
(trilema) zx2c4: yea usually there's lots of information on the conference and board and whatnot
(trilema) zx2c4: the paper was peer reviewed for NDSS'17
(trilema) zx2c4: its in a much better place than just raw md5
(trilema) zx2c4: not saying anyone should use it but
(trilema) zx2c4: i dont think hmac-md5 is anywhere near broken, actually.
(trilema) zx2c4: so it's received quite a bit of scrutiny
(trilema) zx2c4: blake2 came from blake which went through the sha3 contest as a finalist
(trilema) zx2c4: but anyway, the world has learned quite a bit since md5
(trilema) zx2c4: blake is also faster than md5 which is nice
(trilema) zx2c4: (noise uses blake with hkdf, which internally uses hmac)
(trilema) zx2c4: you know hmac-md5 still isnt broken
(trilema) zx2c4: its core is basically chacha ;-)
(trilema) zx2c4: similar criteria - well understood, simple to implement, fast on nearly all hardware
(trilema) zx2c4: i'd be surprised to see all 20 rounds of chacha broken
← | →
Download hourly DB snapshot | Get Source Code