Symbian app installation files have ".sis" extension. Why can't we have ".bro" for parity?
-13 karma · joined March 4, 2016
You can downvote me as much as you can but you will still not be able to escape the truth.
The most interesting projects are the ones that can fit into a gist, so check them out: http://gist.github.com/plugnburn/
Didn't get what does the exit code 55 mean though.
Whether OTP is practical or not, entirely depends on real-world conditions.
P.S. Tell all this to the OP, not me. I'm not building an OTP system.
If I had a license and enough money to buy Gryada-3 module, I certainly wouldn't look into any pure-software solutions.
I see it as this: if the randomness source cannot be one more time put into the same conditions that it would start repeating the same sequence, and its output is random enough (i.e. passes the tests), it may be considered safe for OTP key data production.
Also, I wonder why they don't allow to define own keyboard macros for external commands on the buffer at any time, not just insertion.
But nevertheless, you still have just a decent text editor (with syntax highlighting) in the first place, not an OS inside an OS (like in Emacs or Atom), and not archaic controls for arrowless keyboards and useless rot13 plugins (like in Vim).
Here's your starting point: http://www.nano-editor.org/dist/v2.4/nanorc.5.html
> One-time pads are impractical. You need a key that's as long as your message. Pre-shared.
Need in a key as long as your message (pre-shared) doesn't mean that OTP is impractical.
Let's imagine a conversation between two users that exchange tweet-sized messages in Latin-1 encoding (i.e. each plain message weighs no more than 140 bytes).
Let's consider we've produced exactly 4 GiB of random key data and distributed it between the two users (on a pendrive or somehow else).
When the message is received, its encrypted length is the same as the raw length, so we just move the key pointer for the message length on each send and reception.
So how many 140-byte messages can be sent with 4 GiB of key data? Math.floor(4 * 1024 * 1024 * 1024 / 140) = 30678337.
So, 4 GiB of pre-shared key data allows us to send over thirty millions of tweet-sized messages for both sides. How in the world is this impractical? Especially at our days when a 16 GiB file is a norm.
And yes, pre-sharing these key data can involve a simple SSC, BSC etc. It might be hard for an attacker to figure out when to stop when he constantly gets a random garbage out of the same-looking random garbage.
I.e. don't make any prejudiced conclusions before you get any single answer.
I am too in a doubt that the OP sees the diference between OTP and SSC, but he has to answer himself.
Cryptography was my primary speciality in the university, and I know for sure that "information-theoretic security", i.e. degree of randomness, of a bit sequence, isn't a rocket science. For it to exist, the sequence must pass a row of tests. It's not so hard to achieve. Finding the actual entropy source is much harder. Without a dedicated chipset (have you ever heard of Gryada-3 (Гряда-3, roughly translated as Ridge-3) RNG module? Probably not, it's a Ukrainian invention), human interaction (mouse movement etc) or using external sensors (temperature deviations, for example) the only entropy source I can think of is RDTSC timestamp gathering.
For us mere mortals, even /dev/random will do. But the most interesting question for me is how the hell (which you shouldn't rush into before your father) the OP is going to distribute and sync the random pile of data. That alone is quite a hard problem, especially if the pile is distributed between more than two users.
So let's be patient and wait for the answers.
What's your algo supposed to do?
One-time-pad, you know, is just a system of distribution and usage synchronization of truly-random key data. The key data itself cannot be generated with any algorithm. If they are, it's not a one-time pad, it's a stream symmetric cipher.
So, if you are going to really write an OTP implementation, I have to ask the first question one more time: what is your algo supposed to do?
The second question: how do you create a random keystream in order for it to be truly random, not pseudorandom?
And the third question: how are you going to distribute and synchronize that random pile?
Answers to these three questions would certainly increase the interest in reviewing your algorithm and implementation.
Thanks in advance.
Update! Actually I get this JS error: SyntaxError: in strict mode code, functions may be declared only at top level or immediately within another function
Why did you use that stupid strict mode? It has no real benefits...
This config is used IRL and really saves me from a PITA.
I bet she never faced real discrimination if she considers that phrase about chair offending.
P.S. No, temporarily disabling the option is not a solution, it's another workaround for the problem created out of nothing.
Instead of handling non-zero exit statuses in a correct way,the article suggests to interrupt the script right in the middle, with probably some temporary files and processes hanging around which can't be cleaned up if something goes wrong.
The same BS goes though the entire article.
Has the author actually written anything bigger than echo "Hello world!" in Bash?
Btw, I can post my nanorc just in case anyone wonders how to get more editor space on such a screen on a smartphone.
Language doesn't make Web slow and bulky. People do.
And right now I see yellow outline around this textarea, which is WebKit's default and they didn't even bother to remove it to make this textarea look the same in all browsers, let alone adapt it for mobiles.
Why not a checkbox to turn off HTML? It would be just as "useful"...
I do need JS to achieve all my goals that can be achieved with JS. For those things that can be achieved without JS but often mistakenly involve it (hamburger menus, animations etc), I use plain markup and CSS3. But I'm not going to ruin the UX on mobiles, where in developing countries traffic still matters, just for some paranoid freaks' sake.
In my honest opinion, the only possibility browser vendors should disable these days is the possibility to turn JS off.
Don't trust polls-on-payroll.
But besides, judging a language based on available tooling is akin to judging a CPU based on the computer casing looks.
For a real programmer, GNU Nano with appropriate highlighting should be enough. If a language calls itself "high-level" but makes the coding process hard without tooling, it deserves no attention at all.