geal

We don't really like that kind of advertisement in our workplace.

He brought it there just to share the WTF moments. PCSoft never ceases to amaze us. A very bad language and an even worse marketing strategy, but the company still works...

In fact, the app ships with a bunch of RSA 2048 keys that are used for that part. But there is no revocation support.

I wrote that article, and I think you are right. That was not the right tone for a review of a new product, even if Telegram's attitude (in particular here https://news.ycombinator.com/item?id=6913456 ) has been of denial and arrogance.

I usually have no temper problem, but everytime someones proposes a new secure system and ignores the holes people point out, because that means I will need to spend months explaining to pepople that they should not use it, even if it is "hype".

So, yes, again, you are right, my apologies.

That would be a good idea. That way, everytime someones enters their key, the app can answer that it is not there, check its presence in the database, then get the money :p

It will never get the entire list anyway...

Yup, improving the screenshots would be a good idea. The result pretty much displays as is in the app (in fullscreen), with only one icon above.

What were the reasons for this lateness?

IIRC there were patent issues for some curves, but is that the only reason?

Increasing key length has been the main way to protect crypto from Moore's law. That law is somewhat predictable: we can now how much time a key can hold depending on ressources needed to crack it.

The real problem here: cryptanalysis advances like Joux's tend to create big leaps, much bigger than what we predict based on Moore's law.

And there's the problem that RSA 2048 is slow, and RSA 4096 is so slow that it's impractical...

Basically, Diffie Hellman is a key exchange algorithm, without authentication. So using just this algorithm would not protect from MITM.

But the OTR protocol can be effectively adapted to email. It would need a few emails to establish the original key exchange, but that's not too hard to do. In fact, TextSecure, an Android app (soon on iOS) already does OTR like that for SMS.

The real problem with a system like this is deciding how you would authenticate the person with whom you're communicating. Pre shared key? PGP-signed message?

Ok, so. When you need to write a load balancer and want to test different languages for the task, you don't do a benchmark like that one.

Writing a "ping-pong"? And not using the same client to test both servers?

It would not have been too hard to write a simple proxy in both languages. Not even worrying about parsing HTTP headers, just testing TCP, that is really easy.

Now, if you really want to test the performance, you have to implement it differently. Just two small features you would need in both:

* non blocking IO: right now, you're starting a new future in Scala, that's easy to write but not really efficient (it might work better with goroutines) * zero copy: if you're load balancing, you will spend your time moving bits, so you'd better make sure that you don't copy them too much. It is possible with Scala, but it looks like Go does not support it

Now, when you have reasonable testing grounds (that woudn't be more that a hundred lines in both languages), better get your statistics right.

"The client would make 100 concurrent connections and send a total of 1 million pings to the server, evenly distributed over the connections. We measured the average round trip time" -> that is NOT how you should test. Here, you would want to know what is the nominal pressure the balancer could handle, so you must measure a lot of metrics:

* RTT * bandwidth (per user and total) * time to warmup (the JVM optimizes a lot of things on the fly, you have to wait for it) * operational limits (what is the maximal bandwidth for which the performance crashes? same for number of users)

And then, you don't measure only the average values. You must measure the standard deviation. Because you could have a good average, but wildly varying data, and that is not good.

Last thing: the macbook may not be a good testing system.

Homomorphic encryption is interesting from a business standpoint (think: manipulating credit card numbers without being able to read them).

For anonymization systems, care must be taken: being able to manipulate encrypted data could very well create information leaks.

There have been some interesting theoretical uses of the Pallier cryptosystem in private information retrieval systems, though.

Encryption provides a good way to keep secrets. This has nothing to do with privacy. Privacy is minding my own business without anyone watching me or judging me.

If you need to rely on encryption to protect your privacy, then you have very little privacy, because everything that is not encrypted can be snooped on: where you are, who you talk to and about what (because GPG doesn't protect the username and subject), who are your friends (because you can't trust them to encrypt properly).

If you want to escape surveillance, encryption is just one tool. What you really need is good opsec habits. See for examples http://fr.slideshare.net/grugq/opsec-for-hackers

So many ideas :)

I have found that e-book writing is a nice way to get a product out of consulting engagement:

1- get a mission on an exotic platform or technology

2- read a lot about the subject, write your own documentation, format it nicely

3- you can sell it, but there's an even better side effect: you're now the guy who has written a book on the subject, which will get you more engagements...

I have not said it's awesome, I just said it is decentralized :)

How will your system cope with the augmentation of transactions? I see you use a consensus based system like Bitcoin, and these tend to take more and more time to converge when the number of transactions gets bigger.

Stomach breathing is used by musicians, to get enough air to maintain the notes. It is not necessarily easy to start breathing like that, because the natural feeling is that your lungs are more filled with chest breathing. It is wrong, though, you get much more air by playing with your diaphragm.

Ugly can also mean that you care to do the right thing for customers. I have seen pieces of code that were beautiful at first, but had to be tweaked in horrible ways to accomodate all the quirks of human interaction. Yes, the code is ugly, but if the clients love it, why should you complain?

That's awesome! I have played a lot with Scala and Android, and type safety, options, futures really improved the development on Android (less code, less bugs). I would be curious to try Haskell on that platform.

One tip: make it dead easy to set up. Look at the Text Secure app: you can first pair with just a click, and everything is handled automatically through SMS. Nothing to type. The verification part is a bit more involved, but easy to do with QR codes.

The real problem with end to end security and things like email is that you cannot automate it without a central authority. You will still need to exchange keys at one time, and making that secure is hard.

If you are ready to make compromises, you could set up email clients so that they always send their public key in a header somewhere (or a pointer to their public key). You would not be sure on the first exchange that it is really the person you are talking to, but you would get the assurance that future messages come from the same person.

It's nice to see that they have a sane configuration (even though they should disable RC4 nowadays). They should implement HSTS, though. It is very easy to do (just a HTTP header to set).

So, if I understand correctly, I can test if someone received a specific email just by testing the tracking link with known email addresses? Fun!

Correct me if I'm wrong, but the article begins by saying that a centralized system is bad, because you must use it to interact with the system's clients. Then it goes on to say "it would be awesome if everybody was using Ripple".

Beside the tongue-in-cheek comment, payment systems are already decentralized. You can send money to anyone just by knowing their IBAN number, independently of the bank you're affiliated to.

Break and continue are only an issue if you have large loop blocks. By separating the code in lots of small meaningful functions, break and continue will not reduce readability, and the whole code will be more developer friendly.

or emojis, that would be cool!

Well, you could try to improve the language by hacking on the parser. That would be quite easy to do :)

It calls scripts on the server side, and generates a UI from the results. Runnng the scripts with this app will be faster and easier because you don't need to type (and inmost of the free apps done naively,some requests are done for every character typed, so it's very slow). The scripts are all open source, and can be written in any language: https://github.com/Geal/PilotSSH-scripts

I plan to open source the app, once it is a bit well known. In the meantime, you can easily observe what the application does by replacing the shell on the server side. The database uses SQLCipher, which is open source, and for SSH, I used JSCH, which is open source too.

From what I see:

* everything is done server side -> trust issues

* no encryption, just indexed by a hash -> that means the messages are not store encrypted on the server

I would recommend people stay away from your solution, and instead use something like Zerobin: http://sebsauvage.net/paste/ It encrypts everything using SJCL, and if I am worried with the server sending me a modified version of the JS code, I can still keep the code on my own computer but use it to send to the server.

These are different platforms:

* UI design is a lot easier on iOS if you use XCode's interactive designer. Doing it on Android with Eclipse's designer is painful, but I expect that Android Studio will make that easier.

* UI design without the interactive designer is easier on Android, because iOS is quite verbose for this

* About the code, I have found that iOS's APIs are badly designed, and change too often. The API's of Android are much more stable, but they can require too much code sometimes (example: setting onclick listeners for elements).

* About the tests, it is a lot easier to test for every iOS device, because there are so few (and iOS versions are rapidly deprecated). Android devices have a lot of different OS versions, screen resolutions, CPU, etc. That makes it tougher to test exhaustively.

Nevertheless, I have found that Android development is a lot easier than iOS development (at least for me), simply because XCode spends its time fighting me. For Android, I can just bypass Eclipse and work directly in vim with a Makefile, or I can develop in Scala and use SBT. It's much more fun that way :)

And to answer the last question: apps are primarily developed for iOS because:

* it is believed that iOS users are more likely to pay for an app

* journalists are often more on iOS than Android (and you want to please them)

* CEOs are often more on iOS than Android

From the point of view of the freelance worker, gun.io has been amazing. Interesting work and very nice clients!

Saying that using random words is better than using a string of unrelated characters assumes that password crackers don't know how to combine words.

There are about 180000 words in English (but don't assume everybody knows 180000 words). That means that for three words, you have at most 5.810^15 options.

For a password with mixed case and numbers, you have 62 different characters. With, 9 characters, you have 1.310^16 options.

I can understand that people would prefer common words to remember them, but they are not that much stronger.

The best password is the password I don't need to remember: generate long random passwords, and store them in your browser, in Keepass, LastPass or whatever system of your choice.

Easy to see: despite all the whiners and the bad reputation, you can find good people to work with in France.