2ton_jeff

Hey to "r3xin" and others like him who have tried to get "out" of my sshtalk, :q and exit, :eq, etc don't work. Ctrl-C will boot you straight out always, and any key during the intro "old-school demo TUI stuff I did" automatically cancels it. If you're going to type anything to me, kindly have the courtesy to say g'day :-)

I really didn't expect for it to carry any social features or aspects, in fact the reason I built it was so that it was a ephemeral as I knew how to make it. Timestamps contravene this goal a bit... but if you are genuinely interested re: same, the mods to sshtalk would be quite trivial to add. Despite it being assembler, it is very easy.

I opted out of split-screen in favour of inline with formatting and different colours... I always found it difficult to follow the split screen chats way back then ... that and it makes multi-person windows more difficult with smaller terminal sizes :-)

While linux x86_64 only, this is precisely why I built sshtalk -- https://2ton.com.au/sshtalk, or just ssh 2ton.com.au to see for yourself, I leave it open as a public/free service

i was just surprised, can't restart firefox at all w/ mac os x, safari not much happier but at least it recovers... was just surprised that a 64MB file can so easily KO it..

Putty 0.63+ seems to at least DO it, still doesn't render all of the ACS linedrawing chars correctly. SecureCRT was the only windows client I could find that renders it all correctly. All linux terms and mac os x terms are happy-as with it though.

I was just badly berated by a colleague of mine for not providing a more technical response. My argument to him stands IMO, that your understanding of what constitutes a valid side channel attack is fundamentally flawed in any case.

First, lets start with: All of the library and showcase pieces are WAN material. If you bothered to look, you would have noticed that all of the necessary blinding is performed for all cryptographic operations as received, thus even for LAN access, thanks to blinding as widely accepted mitigation strategy, no timing information is leaked.

Second, if you bothered to actually peruse the implementation, you would have noticed that when it receives a bad HMAC, instead of reporting that differently to the would-be attacker, it randomizes the expected packet length, thereby rendering timing information based solely on the TLS and/or SSH state mechanism useless.

Third, padding related issues are treated the same, such that no attacker-perspective notifications are broadcast.

Fourth, the TLS Blacklist feature I added was only an additional, and IMO decent server-side mitigation technique insofar as during normal operations, decrypt operations do not fail, and if they do, why give an attacker the opportunity to perform 32M+ tests against my implementation?

In any case, as mentioned specifically on my rwasa page, I left the TLS Blacklist feature disabled for my own website due to the ssllabs.com security scans being incorrect if it is enabled.

In summary, my speed increases are not due to shortcutting security protocols or best practices, but the fact that my modular exponentiation routines in x86_64 assembler are indeed faster.

Please send me my private key to 2ton.com.au and I will take the whole lot down immediately.

No surprise, but no one has handed me my private keys. An interesting aside is that my library also happens to provide an excellent framework for performing timing attacks. It is intentionally easy to walk through, and I encourage anyone with constructive actual criticism of my implementation to step up.