Slashdot Mirror
Linux Crypto Packages Demolished
SiliconEntity writes "Cryptographer and security expert Peter Gutmann has demolished several Linux security software packages in a recent posting to the cryptography mailing list. He says, 'It's possible to create insecure 'security' products just as readily with open-source as with closed-source software. CIPE and vtun must be the OSS community's answer to Microsoft's PPTP implementation. What's even worse is that some of the flaws were pointed out nearly two years ago, but despite the hype about open-source products being quicker with security fixes, some of the protocols still haven't been fixed.'"
I wish I could make this my signature (damn 120 char limit):
"Whenever someone thinks that they can replace SSL/SSH with something much better that they designed this morning over coffee, their computer speakers should generate some sort of penis-shaped sound wave and plunge it repeatedly into their skulls until they achieve enlightenment."
--Peter Gutmann
I only use the Cyrillic Projector code. No one ever will crack that.
Demolished? Where am I now gonna get my SSH and GPG from? :-(
Use ISO 8601 dates [YYYY-MM-DD]
What about the poptop project at http://www.poptop.org/. There is also a really good client package at for pptp servers at http://pptpclient.sourceforge.net/ I use both and they seem to be much better then vtun and cipe.
When I investigated CIPE for the first time two days ago, I read somewhere on the site that it didn't work yet, or that it provided no security. How can you critize a package for being insecure when they tell you it is?
Did I miss something?
he points to CIPE, a tool which hasent been updated since jun 02 and Vtun since aug. 2001. he says TINC was just as bad but was fixed when users complained. I think the obvious conclusion is that if people use the software and email the person who maintains it, it will get fixed. if the project goes stagnent because the author doesnt maintain it or people dont use it then of corse it will be vunerable after time as more flaws are discovered and not patched.
It's possible to create insecure 'security' products just as readily with open-source as with closed-source software.
This sentence can be reduced to "It's possible to create insecure security products" without losing any important content.
The question should be, is it possible to create a truly secure product when there's no opportunity for public code review? My answer would be "no". I shudder to think of how many critical holes would be found in most popular closed source network products if people like Michal Zalewski were allowed to review the source code.
All these years after Phil Zimmerman released the original PGP code, we STILL don't have anything which satisfies the need for a securing email. It would have these properties:
1. Be under a BSD-ish license, so it could be linked in to commercial and non-commercial products.
2. Be a LIBRARY, not a stand-alone executable, so it can be linked into anything at all.
Let's see, the Xiph people want their protocols to be used all over the place, so they make it a BSD-license LIBRARY that anyone can link to. Hmmm, seems to be working. The PNG backers want their format to be used all over the place, so they make it a BSD-license LIBRARY that anyone can link to. Hmm, seems to be working. The PGP/GPG people want their stuff to be used by people to send mail everywhere, so they make it either a non-Open Source license (PGP) or a GPL license (GPG) and also never ever make it a library for non-existant "security" reasons. Guess what! No one uses it!
Oh, and while I'm ranting about the horribleness of Open Source security stuff, why is it that there is STILL no well-integrated filesystem crypto in any of the Open Source operating systems, including the security-oriented OpenBSD? No, loopback crypto kludges don't count at all.
He's talking about CIPE and pals...
.. I found CIPE thinking it was an IPsec implementation.. a quick perusal through the source code and docs made it appear to me that it was basically somebody's homebrew project designed with little regard for security. IPsec has its problems, depending how you set it up, but this was worst.
I remember when I installed Red Hat I went looking for IPsec
The 32-bit CRC thing caught my eye as well. I'm no crypto export but I know enough about it to remember how CRC-32 is a weakness of the SSH 1 protocol.
I have since set up freeswan and am happy with it even though I really don't understand IPsec that well I think it has been more closely scrutinized.
So yeah, the author is probably right when he calls it the open-source PPTP... I don't see what it has to do with open-source or closed-source, although with open source it was easy for me (and the author) to gauge the quality of the code and avoid it.
One can browse a manual on the topic and write an implementation that technically works (when paired with a similarly shoddily-designed decoder), but be fully unaware that the pseudorandom generator is just that. Or that the ones-complement portion of the crypto engine fails when X=0, weakening the whole thing by sixteen bits while not producing garbage.
Unlike a crappily-designed game, it's a lot harder to spot when crypto goes wrong. And most of those thousands of eyes supposedly peering over the code aren't looking that hard.
I'd still contend that commercial crypto has had more and bigger flaws overall, but he's right that the open source process alone isn't going to give you good crypto.
I checked the wrong damn box.
I hate Mondays.
#1 Links to URLs not on standard ports stink. I'm stuck behind a very strict http proxy.
#2 Links to message lists stink to. The location of the content is not obvious. Maybe the offport link contains some valuable information.
#3 I did find the message that is the topic of this post. The material in the message seem very "dated".
No more Micro$oft bashing from me. Its like bashing at the special olympics.
Oh lovely.... so now because these are OSS components, people can't be critical unless they actually code the changes? Informing those that are suppose to care isn't enough? The author made a good faith effort and freely shared his knowledge but instead of saying thank you we'll get someone right on it... it's code or shutup?! *sniff* *sniff* me thinks me smell an ungrateful, eleetist something in the wind.... *Blech*
The time it takes to fix software is inversely proportional to the popularity of that software. I know 0 people that use CIPE and vtun.
Back in the day, whenever I'd bitch about how window managers lacked basic functionality, how the default IP tools didn't do multiple hot-switchable configurations, about the lack of decent documentation in the distro, about some aspect of the application that didn't work, shouldn't work that way, or had TOO MANY OPTIONS.... the response was ALWAYS "dude. The source is THERE. FIX IT YOUR OWN DAMNED SELF." With "That's a FEATURE, not a BUG." being a close second. To which I'd usually reply "I'm an ARTIST, not a CODER," resulting in a flamewar about the quality of the Gimp, but that's a different story.
:D
Things like this will get fixed when the people maintaining the packages start doing the gruntwork that gets those little bits enterprise grade- in other words, doing the hard, annoying, pain in the ass shit that you pretty much have to get paid to do, because nobody wants to do it in their free time. Big bonus points to open source software companies for making a BIG effort to do exactly that.
Unmaintained software........unmaintained.
In other news, Bear shits in woods.
I'm pretty sure there are some pretty pathetic, sad window managers out there too. Some of the text editors are rather less than impressive as well. There are all manner of dodgy MP3 managements systems. OSS creates all manner of bad software because ANYONE can code something up and release it.
The security and cryptography field just highlights the problem because there are so many opportunities to do something particularly stupid in those fields. Anyone can write a cryptosystem that they can't break themselves. Unfortunately a lot of people figure if they can't break it, then neither can anyone else...
Jedidiah
Craft Beer Programming T-shirts
Linux in general is more popular than this project. That popularity gives it more eyes to keep watch on it, and shorter turnarounds when problems are found.
As for this project (CIPE), I personally have never heard of it. Indeed, neither has the poster from that mailing list: A friend of mine recently pointed me at CIPE, a Linux VPN tool that he claimed was widely used but that no-one else I know seems to have heard of.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
This crap got modded up??? I felt sure when I first saw the comment that it would it -1 at mach 3. Especially in light of articles like this one.
Not only that, but if you think about it, blaster and slammer and all those thing... They were only single "attacks", writen presumably by one single person. The nature of the insecurities is what allowed these worms to be as disruptive as they were. You imply with your post that the security of a system is inversely proportional to the scale of the deployment of that system. I'd love to see some evidence of that.
noah
Vtun is still far from being useless.
Just turn off vtun encryption and use it via a ssh tunnel. That works very well (i use it for securing wifi) and uses a proven protocol.
I also believe this is good practice and should be a widely accepted policy - re-use of good and proven software is not lame - it is crucial for easy, fun and secure software development. There really is no need for re-inventing the wheel.
Now if only ssl were so integrated into the operating system that i could use select() on a ssl-socket created with socket(), and thus making writing of ssl-enabled apps as easy as non-ssl-enabled ones, that would be great!
-- Having problems sending big files over the net? Try out Efisto (http://efisto.org)
FreeS/WAN
The real "Libtards" are the Libertarians!
RTFA. He gave a list of what needs to be done to fix them.
If you are looking for a good vpn package for linux, try openvpn:
openvpn
It was created a while back when all the other linux vpn products were not that great, and it seems like thats still the case.
Of course it'll have a similar number of holes. After all, there's nothing about OSS that makes the software fundamentally more secure. BUT:
1) These holes are far less likely to be in the base operating system implementation, as the OSS mantra is generally to put as much logic in user-space as possible.
2) These holes won't be covered up and released only after the vendor has decided to let us know about them.
3) These holes will be fixed up very quickly (in general, anyway), in individual patches or point releases, without onerous licenses attached to them, and without fear that the release might break the rest of my operating system.
4) Because OSS products use open standards, if one particular package is simply too insecure, at least I can change to another product and have things interoperate (eg, switching from Sendmail to Qmail/Postfix/MTA-de-jour).
If you ignore automated worms and mail viruses, Linux/Unix has traditionally had far more attacks than Windows. Even a few short years ago, you could put a unpatched Windows box on the Internet and would be largely ignored. Not the case with something like RedHat Linux, which would be scanned and hacked within hours.
The "skript kiddies" like hacking Linux & Unix because it's "elite" and has usually has tons of tools like compilers installed. (Also, the Unix community was far ahead of Windows people with "open disclosure", which meant it was really easy to create hacks.)
Anyone else remember the t-shirt "My other computer is your Linux box". Little joke at the expense of the n00bness of most Linux users.
Oh, and RedHat already does nearly weekly security updates and has done so for years.
1.23 Can I use vtun over SSH ? Yes, via the port forwarding feature of ssh. Don't enable vtun's encryption as ssh does its own encryption. Also, make sure to select the tcp protocol as SSH can forward tcp but not udp. An example session might look something like this: home$ ssh -L 5000:localhost:5000 work.megacorp.com (authenticate if necessary) work$ vtund -s home_tunnel_config
Now, having said that, I use VTUN and haven't had any problems. But then again, I also have the boxen firewalled to hell and back, no services allowed but SSH from a few known hosts, no root SSH, etc. So even if you do crack my key, you're not getting much that will get you anywhere.
While I don't consider it the most secure tool, it does the trick well enough for now. Kudos to the VTUN team, and kudos to Peter for his examination.
PC moderators can suck my White pierced, tattooed dick. If you think pride == hate, s/dick/Aryan meat mallet/g.
"Whenever a programmer thinks, "Hey, skins, what a cool idea", their computer's speakers should create some sort of cock-shaped soundwave and plunge it repeatedly through their skulls." - Makali.
http://rocknerd.co.uk
Instead of making yourself look so great by "demolishing the security," why not offer the fixes?
If you read the article, his advice is almost every case is "Scrap this, go learn basic crypto, and try again." I don't know crypto at all, but I'm willing to bet that's good advice. And if so, why on earth should he take the job of re-writing CIPE? I think it's great that he's getting the word out that it's insecure. These are the things that should be public knowledge.
Package: libgpgme11 ...
Description: GPGME - GnuPG Made Easy
GPGME is a wrapper library which provides a C API to access some of the GnuPG functions, such as encrypt, decrypt, sign, verify,
Can I hump your skull now?
Open Source or Closed Source, its just as easy to write insecure software, either way.
The point is, that with open source you can see just how insecure or secure a particular product is by looking at the code.
Open source is inherently no more secure than closed source software. The difference is people like "Peter Gutmann" can see what is wrong and be at the ready with suggestions how to fix it.
Electronic Music Made Using Linux http://soundcloud.com/polyp
Rating: 8.35/10.00 (Rank N/A)
Vitality: 0.01% (Rank 4941)
Popularity: 2.72% (Rank 1001)
VTUN
Rating: 8.55/10.00 (Rank N/A)
Vitality: 0.02% (Rank 2787)
Popularity: 2.69% (Rank 1017)
Neither of these projects are dead, quite, but neither is terribly active, either. Sourceforge shows one developer for CIPE, for example.
As an earlier post said, crypto demands skills which aren't generally available, in an unusual combination. Many competent eyes make bugs shallow. Many competent coders make bugfixes quick. It looks as if those packages haven't drawn the competent eyes and coders yet.
Maybe Mr. Gutman's post will draw some good folks who are able to do the work to these projects. Or maybe it will inspire the maintainers to simply let them fade away. Either way, we're better off for his efforts.
A third possibility is that folks will just not care. Gutman tells us:
This kind of thing needs to be fixed or abandoned; bad security is worse than no securitySee what I've been reading.
VTun has been updated
in 2002 and 2003.
Check their homepage:
http://vtun.sourceforge.net/
Maybe only small update.
I'd go one step farther.
Sometimes the best thing a programmer in this situation can do is to just declare a piece of software broken beyond repair and just retract the sucker.
I mean, CIPE might have made sense before the widespread availablity of open-source, carefully crafted IPSec software. Now, your best mileage is to provide easy directions for how to build an existing, functional IPSec setup.
Gentoo Sucks
The first big difference between OSS and commercial products is often that commercial products want to either invent a new proprietary protocol, or, for marketing reasons, push an obsolete protocol as a new innovated protocol. Both of these leave end users insecure. However, since everything is proprietary, there is no way for the user to know the level of insecurity. And, if we may drop names like in the article, Scheier lists a new company nearly every month who tries to push crap as security, though he has gotten so annoyed that he has skipped months of late.
And to drop the name again, Schneier, has spent his time of late trying to convince people that security is so much more than protocols. The protocols must be implemented in code correctly and deployed correctly. Unless one is a huge national agency with a classified budget and decades of security experience, it is unlikely that one can create a secure product. It is much better to make the code public so that interested parties can investigate. It doesn't mean they will.
The two of these combine in interesting ways in closed software. There are claims of 1,000,000 bit keys. There are situation in which security by obscurity is used as the first line of defense. There are situation in which the DCMA is used as the first line of defense.
Which is just to say that conclusion #1 and #2 does not follow from the text. Just because one finds a few packages that are out of date in OSS, does not mean that finding a few updated packages in closed source software are more secure. Conclusions #3 and #4 are trivially valid, and applies to anyone writing software in any model. All programmer should take the advice to heart, especially if they want to design a right management system using closed protocols.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
It is eminently unfair to call these "Linux" packages.
.
Of course, none of them are GNU packages, either . .
OTOH, tinc does have a linux.org homepage, but then it seems to not be "Demolished" by any reasonable definition. He says "This is a terrible way to use RSA, and usually compromises the key." and I'm no crypto geek, but I think what he means by "compromises" is "provides and avenue of attack that is mathematically simpler than brute force against the key" not "reveals the secret".
So, two seemingly abandoned projects are suspect, and one relatively arbitrary (but Open Source!) package has a theoretical weakness.
All that said, my question is: What has been demonstrated (or demolished)?
-Peter
Of course, the author of that article went on to write CIPE, which is one of the problem protocols under discussion.
I use freeswan IPsec for securing wifi. The biggest problem with IPsec is that it suffers from "committee bloat" and is very complicated to use. Freeswan partially mitigates this complexity by implementing only a narrow subset of the RFCs (in fact, it is not even RFC compliant, because they deliberately removed some required features that might compromise security).
The good thing about IPsec, and freeswan in particular, is that they were openly developed with actual expert input and nobody has yet cast any doubt on the security of either.
Good lord. If he googled a bit more about vtun he would have seen responses in defense of it, as well as asking to go beyond theoretical garbage to proving the insecurity.
He says nothing new.
The key to using encryption with vtun is to use a strong password and to change it now and then. There's really nothing wrong with vtun's encryption approach otherwise.
Any potential software issues not relating to encryption do not make vtun any less secure than, say, SSH (see the latest patches).
This guy, obviously with more than a few clues about security, is able to examine the products, right down to the source level, analyse the security provided, freely publish his findings and suggest improvements (even if all he suggests is 'scrap it', and something about skull-fucking with sound-waves.)
This is great information, and while it might not reinforce the 'open source uber alles' message, it is very useful to anyone who might be considering working on these or similar projects, as well as anyone that uses them.
Even if Mr. Gutmann says these products can't be completely fixed, at least the authors can improve them now based on his comments, and just because this guy says it can't be done, doesn't mean it is gospel.
I say a big thank you to Peter Gutmann (a fellow kiwi, alright!) for taking the time to write this and help to improve the state of open source security products.
I gots ta ding a ding dang my dang a long ling long
Check out FreeBSD 5's GBDE system. It's still relatively new and needs some polishing, but is improving rapidly. It's already quite usable.
Oh my god! Which ones the intelligent one?! Which one's questioning open source!? Who's the troll?! I need an adult!
1. Make good point that open and closed source software can both be insecure.
2. Demonstrate point by showing out insecurity in some open source software.
3. Someone notices the good point and fixes the insecure open source software.
4. Close source software gets no such notification, still has holes.
5. Point one nullified.
First of all, I've got a tremendous amount of respect for Peter Guttman, and not just because he's the author of the coolest quote relating to computer security of all time (if you can't find it in that essay, you're not paying attention). But...he misses the point.
... TCP is terminated at the forwarder, addressed using SOCKS4 or SOCKS5(>3.7.0), and forwarded to the appropriate destination on the other side of the tunnel. It's TCP _only_, but it operates completely in userspace.
We do not have an effective method of running a stateless cryptosystem, but IP actually does require stateless operation. All these mini-systems that have sprouted up exist because of this.
SSH(which, incidentally, violates Guttman's rules by using "the same key for encryption and authentication") and SSL(which utterly falls apart when the cert gets compromised) both run over TCP. TCP is not IP. TCP adds reliability, through error detection, correction, order management, and congestion management. That's all well and good, but sometimes I really don't care when I drop a packet. Voice traffic is a fantastic example -- by the time the retransmission is complete, the data is stale and irrelevant. But TCP will not only stop to retransmit, it'll hold up everything else while it does so, and even slow down the connection to be sure a dropped packet doesn't happen again.
There are _many_ protocols which can accept these semantics. But there are many that cannot, and there's a bigger problem: By supporting those protocols that do not share the connection semantics of TCP -- DNS, VoIP, etc -- we end up being forced to carry either GRE or PPP packets over the SSL/SSH tunnel -- and inside these PPP packets, that are being carried by TCP, is more TCP.
This doesn't work very well at all -- effectively, both sockets attempt to simultaneously adjust to changing network conditions, and since neither knows about eachother, they both screw up badly.
All because we do not have a stateless cryptosystem that works. It may very well be that such a demand is impossible. Stateless cryptosystems can send a message and not only not prenegotiate a session key, but tolerate large number of dropped packets. Replay attacks need to be suppressed, but packets need to be able to survive high latencies. CPU load needs to be kept reasonable, but no message can rely on the asymmetric results of another.
In short, normal cryptosystems are built to be inflexible to attackers; we do not know how to make them simultaneously flexible for networks. The reasons why should be obvious -- anything that can go wrong on the network, will go wrong because of an attacker. So telling everybody to use SSH/SSL is ultimately code for, "We just don't have the crypto to secure IP." And we know IPSec is a failure; if it hadn't been for VPN's, it'd be as rare as multicast and a hundred times more expensive.
Solutions? I suspect short signatures will ultimately make the difference, as will better time-based protocols (at least for intra-admin-domain work.) But no matter how high my opinion is of Guttman, I cannot ignore he considers solved problems that fundamentally refuse to go away.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
P.S. There is an immediately available VPN solution that's free and doesn't suffer from TCP-over-TCP effects. Look up Dynamic Forwarding for OpenSSH
No, because GPGME is GPL, not LGPL, and all it does is make calls to the (GPL) GPG binary.
The problem with Einstein is that he was just an armchair physicist.
Why didn't he just shut up and do something?
Can someone tell me when expertise, perception and wisdom became "worthless"?
"Excuse me sir, but did you know that your door lock is faulty?"
"Hey, don't give me none of that talk mister. Just shut the hell up and fix my lock. OK?"
"Listen. . . asshole. I didn't design the lock, I didn't make it and, more to the point, I'm not the jerk who put it in your door. It's your design, your lock and your door. You fix. Now FOAD."
Open source is about sharing, not about making the other guy responsible for your cockups.
KFG
Peter Gutmann is a serious expert. I write security code for a living. (For IBM) Peter Gutmann has writen a few seminal papers such as "A Layman's Guide to ASN.1" which is required reading for anyone coming on the team.
Apparently your posting strategy went something like this:
Ironically, your post made for the better demonstration of the problems inherent in the Slashdot moderation system.
Do you have any idea at all what he was talking about? Lots of cryptographic algorithms depend on random numbers. A common mistake by newbie cryptographers is to use a pseudo-random number generater which gives predictable values, leading to encryption which is easily broken. Real cryptography software must work very hard to find sources of unpredictable randomness in a system (like, say, the timing of a sequence of keypresses, if the computer has a keyboard). He was making a good point.
Do you even know what ones-complement is? Again, he was making a point, but either you intentionally ignored it for the sake of your reply or if flew right over your head.
He made a good point: If a programmer produces a buggy game, it's not a big problem, even if millions of people play it. But if a programmer produces a buggy cryptography library, and millions of people use it, that IS a problem.
Wow - criticizes someone else's post without having a clue what it means! +5 Funny!
This is open source, figure out where to submit your patches or else you are nothing but an arm chair security expert.
Absolutely absurd. I can't believe you wrote this. People who are good at writing code donate code to free software projects. People who are good artists donate art to free software projects. Yet, somehow, when a noted cryptographer does a (somewhat acerbic) security analysis of *three* open source packages and lists fixes, somehow you feel that he hasn't contributed anything.
Incidently, I'm curious if you're aware exactly how much it would cost in consulting fees to get someone like him to sit down and review a given product. This guy contributed a lot more in terms of intellectual value to those three projects than the forty-five people that sat down and wrote five-line patches to remove gcc warnings (not that their work isn't appreciated, but still).
He deserves our thanks, not scorn.
May we never see th
- Extreme depression with the level of technical expertise demonstrated on Slashdot in particular and within the computer industry in general
- Sincere belief that Freenet is nothing more than two ROT13s and a Caesar cipher (using original Roman) fed by a PRNG believed by all to be a RNG
- Renewed dedication to feed only well-decorated bullshit into this site, because I'm sick of wasting hard-earned knowledge on schmucks like you who already think they know it all
You don't use a pseudorandom number generator (such as that provided by rand() under C or the deviceElectrical engineering comes into play when you're having a discussion about what to base a solid random number generator on. One such interchange I witnessed was regarding using entropy from network devices to feed into /dev/urandom (Linux's 'secure' random number generator, which attempts to gather 'randomness' from various sources that are unlikely to generate a recognizable pattern) -- it isn't necessarily a good idea, because on some machines network traffic is very periodic. There is a tradeoff consideration in determining which sources of entropy to use within computer hardware: how quickly do you want to be able to draw on the sources of entropy vs. how secure do you want the final entropic stream to be?
I mention the 1's complement because it's an example of a problem I personally encountered. I had a 16-bit 1's complement checksum I implemented that worked quite well, except for the fact that the software it interfaced to used a zero value to indicate no checksum was present on the packet. However, there were cases where the checksum would really BE zero, and the thing to do was to subtract one in that event (leaving 0xFFFF, which pulled double-duty for values checksumming to 0xFFFF or 0).
I have it on good authority that similar errors have happened and are easy to make particularly in cryptographic implementations, while not necessarily making themselves evident to the implementor in the output. Feeding data through an encrypt -> decrypt phase isn't proof-positive your implementation is correct just because data comes back out unscathed -- maybe you forgot an XOR in two spots or are only putting blocks through 7 of the 8 S-Boxes because of an off-by-one error. Testing is non-trivial.
I mention games because they also combine several disciplines, and the evidence of poor design and implentation is much easier for the layperson to notice. If you think closer attention is paid to cryptography, you haven't been reading Crypto-Gram.
In conclusion, I don't normally give a sizeable rebuttal because that's usually the work of a terminal trollbiter, but frankly I'm kind of shocked at your response given your impressive choice of field in school and Open Source projects (going by your Slashdot description) and think maybe you'll benefit from the details.
Peter Gutmann contacted us (the tinc developers) on September 15th, quoting the part of his writeup relevant to tinc. We exchanged a few emails since then. There are some points where tinc could certainly be improved (some of it already planned for 2.0), but we don't believe the "real problem" he mentions actually exists. We have told him our objections to his writeup, and asked if he could prove or make it more plausible that an attack on the authentication protocol is possible. He still hasn't convinced us.
In some more detail: the 32 bit predictable IV might make the other 32 bits of the first encrypted block more vulnerable, but the other 32 bits of that block only contain part of a MAC address which does not reveal any important information. It does not compromise the other blocks AFAIK, and in fact a sequence number instead of an unpredictable random number is more secure according to Jerome Etienne, who has done a much more detailed security analysis of tinc in the past.
The messages encrypted with RSA are indeed not padded, but padding is, AFAIK, only necessary when the message is shorter than the RSA key. In our case, the message is exactly as long as the RSA key.
Peter Gutmann believes there is a possible MITM attack ("Chess grandmaster attack"), but hasn't shown us how, just that he believes it's there.
Peter Gutmann also believes tinc has to be configured identically on each endpoint, but that is not true at all.
We're still in discussion, and if we believe there is really a problem we will fix it. In his conclusion Peter says that everyone should be using SSL or SSH. We could, but I don't believe SSL is necessarily the be-all and end-all of encryption.
When I start selling you my project as shinola, you can tell me that it's a shitty product. Until then, you're welcome to contribute. If you just want to criticise, then I'll thank for your input, but advise you to calm down and take a chill pill.
Well, Peter Gutmann did provide useful insight for the programmers involved in these open source projects. What frustrated him was some of them ignored him, or simply did not know enough about security to understand his comments. That is the kiss of death for these projects IMHO.
He contribued far more insight to these projects than dozens of inexperienced programmers did previously.
Anybody using my project is liable to be doing so because they enjoy playing with it as much as me, not because they're relying on it for a critical application.
Sorry, I don't just use open source software for fun and enjoyable, I use it to get things to done in the real world. You are basically taking a cop-out, either your project (at the current time) is secure or it is not. If it is not secure, don't pretend that it is.