The opposite of a woman is a wereman.
A man is just a human.
The opposite of a woman is a wereman.
A man is just a human.
And for a 10 Mbps connection you drop the max MTU and split the packets. Routers in the middle of a path can do this.
Video Streaming Service A sends a 64 KB packet to ISP B over a 100 Mbps link, ISP B knows Customer C is on the Shit Tier package and can handle 10 Mbps, and decides to split up the 64 KB packet into 4 KB or whatever packets, Customer C gets their shit.
4 KB / 10 Mbps 64 KB / 100 Mbps, no additional jitter. Without even inspecting the traffic to see if it's Netflix or Skype or their own VoIP service, they can control jitter to be no more than the source or no more than some baseline acceptable level.
64 * 1024 * 8 / 2 / 1000 / 1000 = 262 ms worst case, not 328 ms.
And routers should know the capability of the links and can split up the jumbo frames into multiple packets to let VOIP through ahead without wasting much bandwidth at all. Hell, my shitty D-Link does this - every boot it scans the link to determine connection speed and uses that in its QoS engine.
Further, the use case in the article is 8 Gbps in a studio environment. They can dedicate the entire link to video. 8 Gbps down a 2 Mbps pipe is never going to happen, so your example is ridiculous on the face of it. They're claiming a ten-fold improvement. So how about an MTU of 16K instead of 1500 or 64K?
Worst case is 66 ms additional delay on your 2 Mbps link.
If people would just accept a decent MTU none of this would matter.
The max is 64 K but we're stuck with 1500 (including overhead) because you can't be sure that every hop will support your MTU.
Internally you can enable jumbo frames and shit will work, but once you need to go out over the internet all bets are off, so you limit your shit to 1500 and your performance goes to all hell.
We're basically delivering UHD movies via telegram.
In mIRC, open the About window and type arnie
I am a known troll, but I'm also correct.
Choosing NetBSD over FreeBSD or OpenBSD is like being offered a free soda and asking for Shasta Cola over Coke or Pepsi.
In the real world, you go to work doing shit you don't want to do 90% of the time, but you do it because you like money.
The problem for Linux is people can get a better job elsewhere - less shitty work, less shitty working conditions, and better pay.
Just treat it like the job that it is.
Like we're going to listen to a 6-digit UID noob on fucking Slashdot for advice on how to run our shit.
If you can't commit to the hours required then perhaps you should seek out another hobby. And honestly, if you knew what you were doing you wouldn't be dealing with emails 7 days a week or being hit with "personal insults". Further, those "insults" ARE about the code, in your case they happen to be about the shitty fucking code you keep submitting.
I'm Linus Torvalds, fuck you.
P.S. Why are we losing developers? 2016 is on track to be the year of the Linux desktop and we need more developers for when the masses adopt Linux and all he bugs and security holes are forced to the surface.
That "very definition" is used incorrectly by so many people, including you. When you're slapping it into a call to an encryption/decryption function, it's ALL effectively "something you know". A thumbprint hash is just data, so is a keyfile, so is the output of an RSA clock at any time. Security "experts" tried to model this off of physical security principles, but they don't translate over. That doesn't stop them all form parroting "something you know, something you have, and something you are hurr derp", though.
Something you HAVE and something you ARE need to be verified by some authority that controls access. It's like buying pseudoephedrine at the drug store. They ask for something you HAVE (your driver's license), and they verify it to a reasonable extent. Without an active arbiter, you can only use something you KNOW. Imagine buying pseudoephedrine on Amazon. That something you HAVE becomes something you KNOW because all you can do is type in your driver's license number, state, and expiration date. At the drugstore, they expect a physical card with a photo that looks like you and a magstripe that swipes with valid data. They can also physically see if you look like a tweaker who's got the shakes because they need another hit.
You can try to use automated arbiters, but they're vulnerable. A thumbprint scanner can be tricked into scanning a fake thumb or someone else's thumb, or it can be bypassed completely if you know the output it gives for your target thumb. A car with a breathalyser can be tricked by having someone else, or a raccoon, blow into it (that story was fake by the way - http://www.inquisitr.com/24605... ). Or, again, if you know what the breathalyser outputs on a good blow you can bypass it entirely.
You can try to use remote arbiters. A typical example is a security camera and a remote person monitoring and unlocking doors and shit. You can attack the camera, dress up as the target, put a photo of the empty hallway over the camera so that's all it sees, whatever. For an apartment gate/door with an intercom and a "buzz me in" system, you can pretend to be anyone to anyone who can buzz you in, or you can click the button a bunch and make the sound distorted and someone will just fucking buzz you in to make it stop, or you can always attack the gate.
Something you KNOW is the only thing you can use without an arbiter, because the mere knowledge of that thing is what constitutes valid access.
Something you ARE and something you HAVE require an arbiter for verification, otherwise the mere knowledge of those things can be used to masquerade/forge the thing that you ARE/HAVE. Automated and remote arbiters are better than nothing, but their automation/remote nature make them less able to verify the ARE/HAVE to the same degree an active and present arbiter can.
The most common "two factor" authentication systems in place are RSA clocks and one-time passwords sent via SMS.
No one verifies that you have and own that dongle with seed XYZ or that the specified phone number belongs to you. They verify that you know the code the dongle output or that you know the code they send you. Knowing either isn't very hard, and you can attack on either end.
RSA clocks: Attack the database that has the seeds and generate your own valid codes willy nilly. Steal the dongle. The easiest, however, is to pwn the target's device / MITM the target's network connection. When they're doing shit intercept the code and use it in your own attack (they all have pretty wide validity windows to account for clock skew, time for users to type it in, latency and processing time, etc.) This is why many places now require you two input two separate codes to disable the dongle - a victim will typically not provide 2 codes within a short time span. Of course this is pointless as the attacker can spoof a message to the victim saying the first code was rejected, try again. The user will do so immediately and the attacker now has 2 valid codes and can remove the dongle from the account.
SMS: You can attack the server that generates the codes, the service that sends out the SMS, steal the cell phone, or whatever. The easiest, however, is just downloading the SMS messages yourself - all you need to know is the target's phone number (SMS is incredibly insecure).
The RSA clocks are the better of the two since a successful attack requires either an active attacker or an undetected breach of the database containing the seeds. (Or breaking the algorithm.) But they are absolutely not "something you have" when you present the code. They are "something you know".
There is no such thing as two-factor encryption for cold data.
Using a keyfile and a password is the same thing as using a complex password. You just know one and you have the other and you chain them.
The same for using a password and thumbprint hash. Anyone who has the encrypted data and knows how it's encrypted can feed it the password and hash.
These are functionally no different than a single complex password - there is nothing "two factor" about it. And in many cases this type of layering can make it much easier for attackers to break ur shit.
Consider someone using 7-Zip to encrypt their "Secret My Little Pony Costume Design" directory.
1 layer of encryption using "aj29dn(3nb1A3n+d,c^D" is much better than 4 layers using "aj29d", "n(3nb", "1A3n+", and "d,c^D". The smaller passwords will be cracked almost instantly, and each one gets them 25% of the way to your shit. The full password will take ages to crack and it has to be done all or nothing.
You only want to layer passwords if your password's entropy exceeds the length (in bits) of the output of your encryption algorithm (or really, length minus one bit).
It's far more common to increase the number of rounds than it is to layer, but if you suspect an algorithm may be compromised it may make sense to use multiple layers with different algorithms. Layering also makes it easier to slap on plausible deniability and steganography.
Temporal passwords (RSA clocks) require a verification step by an arbiter. These are vulnerable to DoS attacks and MITM attacks, as well as all the usual "LOL HACKED UR DB AND GOT UR SHIT" attacks. Anyone with the seed of your particular authenticator app / dongle can generate those temporary codes and get access from the arbiter.
These kinds of passwords aren't there to protect the actual stored data, but control access to it. Anyone who gets the data will be able to try to decrypt it as usual.
For a temporary password to be considered a secondary layer of encryption, the data must be decrypted (temp pw layer only) and reencrypted each time that temporary password changes, AND you must ensure all previous copies of the decrypted AND encrypted data are destroyed (you can't do this if you hand the decrypted file to the user for them to decrypt the inner layer). You generally don't do this for cold data, you do it for live communication across an untrusted channel, such as the itnernet.
KeePass IS better. It's far more functional and far more customizable.
Throwing a KeePass database on Dropbox is secure even if Dropbox exposes the database.
I find it hilarious that you bitch about people who don't understand that LastPass's breaches meant nothing, yet you go on to imply that Dropbox's breaches are a problem for people using it for KeePass databases.
"Never attribute to conspiricity that which is adequately explained by stupidity."
That's what they want you to think.
Instructions unclear. Decorative photos tastefully hung on wall. Please send help.
Wrong. Some barriers are good and some are bad. Having an opinion on which are good and bad doesn't make you a hypocrite, nor does following some and shitting on others.