i commonly run vnc via ssh tunnel (whether or not via wifi). flashing cursors abound, eg firefox inputs, gmail compose, libreoffice, xterm, all within vnc, any of which may be left flashing for minutes or hours, which could, i'm thinking, be well more than enough of a predictably repeating sequence to crack ssh. for an even more rapidly repeating sequence consider the libreoffice marching cell outline after a cell copy. how often does/ought ssh change keys? perhaps every few seconds (unless no activity)? perhaps apps should shutdown cursor flashing or pattern marching without seeing clear indication the user is watching like large mouse movement. lots of apps to chase down tho. perhaps vnc ought have an option to shutdown output while there's no indication the user is watching. On 12 December 2014 at 08:03, Ryan Coleman <ryan.coleman at cwis.biz> wrote: > > If you have enough sample data you could, in theory, crack the cipher. So > the answer to your question is, technically, yes. > But we have rotating keys in WPA/WPA2 encryption now and this was far more > prevalent when we used WEP encryption. > > Cursor flashing: I believe this is done on the client side. I often have > a flashing cursor and no terminal session when my WAN connection fails and > I have an SSH session open. > > > > On Dec 11, 2014, at 9:27 PM, gregrwm <tclug1 at whitleymott.net> wrote: > > a security advisory i read within the last couple months was all about > how someone on a cafe wifi could fairly easily get into supposedly secure > connections by repeatedly injecting crafted contents and thus cracking the > cipher, something like that, can anyone clarify this with a pointer? not > sure but i think ssh was involved. which got me to thinking, couldn't > predictably repeating contents, eg a flashing cursor via ssh/vnc, also > similarly provide a fairly easily crackable sequence, with no need for an > observer to even inject anything? > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20141212/9fd27e9c/attachment.html>