I will note for the record that I draw a heavy line between Manning and Snowden. The former I would like to see executed, the latter I'd like to have a beer with. Anyone interested in the civil liberties of US citizens would understand the fundamental distinction between the two named persons.
As a very happily married man with a wife whose posterior is quite round, I'm continually confused by the prevalence of jokes about big butts which assign a negative value to that trait. Apparently, many women think most men want to date twigs.
Hi, former Navy guy here. Unfortunately, the US military hasn't executed anyone since 1961, although plenty of service members have committed capital offenses since then. I say this as someone who is a staunch opponent of capital punishment in the civilian sector, but has no patience or forgiveness for those convicted of espionage or treason while wearing a uniform.
You're completely out of your depth here, as you apparently aren't aware of the numerous and nasty cases of service members walking around with TS clearances who got into financial trouble and decided it was somehow a good idea to attempt to sell classified materials to foreign powers to make up for their losses.
I'm speaking as someone who served, and someone who was in service when a particular submariner was caught doing exactly what I just described. He's far from alone in his transgressions, and such offenses have occurred on both the enlisted and commissioned sides.
Stop talking about things you have no experience with.
I'm not interested about my ego -- I'm an AC, remember?
I find that many ACs tend to be more interested in their egos than signed-in users, especially the ACs that habitually check for replies to their anonymous posts.
I still think that self-signed certificates are an excellent way of getting encryption, packet integrity,/and/ verifying that it is still the same server. I cannot find anything in your posts that would refute that fact or why it would be misinformation.
You must have missed the bits about the absolute importance of determining who you're talking to the first time you make a connection.
(Your assumption seems to be that the attackers already control the infrastructure during the initial connection. My tinfoil hat is not/that/ tight. Besides, how would a "real" someone-else-vouched-for-me certificate help at that point?)
You seem to be placing an inordinate amount of trust in network operators, trust which is sorely misplaced, as I've seen firsthand. You've also handily demonstrated an utter and complete lack of understanding of how PKI encryption operates.
I certainly don't disagree with out-of-band cert verification and would try to offer a method to do that. Running an own CA would be a step up but mostly useful for larger projects only (Debian does it) -- hardly so for a hypothetical forum with only a single access point.
If you think only large projects run their own CAs, you're smoking some strong stuff. Every single employer I've worked for operated a CA for both internal and external purposes. I happen to operate three for various purposes. Be sure to inform your forum members that you don't shit two shits about their privacy.
I probably shouldn't be replying to a troll, but what the hell, this one is just too hard to pass up. Thousands of companies around the world, including many of your favorite Fortune 500s, use Perl for tasks ranging from mission critical systems programming, to application integration, to enterprise reporting and sure, web applications. You must be living a pretty sheltered life; if you truly work in an enterprise environment, have you bothered taking a look at what powers your company recently? Hint: there's an awful lot of Perl (and Python, too) driving it, probably in places you don't even know exist in your infrastructure.
Son, I've been doing this professionally for fifteen years. Have a nice day!
Unless you know what you're doing and have a very good reason to use the modules under the Crypt namespace directly, you should generally be using Crypt::CBC with them, at least for most common purposes.
The actual Blowfish cryptography core of Crypt::Blowfish is written in C. You can verify this by downloading the tarball and looking at the source. There is a pure Perl version available as well, but it's slower.
The cores of Crypt::DES, Crypt::Rijndael, etc are also written in C.
Re:Why do we even go to these orgs anymore...
on
Did NIST Cripple SHA-3?
·
· Score: 4, Interesting
I do most of my work in Perl, and I happen to heavily utilize Blowfish and Twofish. Perhaps you should think about what your application pipeline requirements actually need in terms of crypto and then look into the various modules that interoperate under the umbrella of Crypt::CBC.
If investors actually pay any attention at all to this news, the price will go up. IBM has essentially proven to its shareholders that they can once again go up against the federal government in cases like this and come out paying virtually nothing in fines, while not being required to take any meaningful action as far as policy revision goes. That's called "enhancing shareholder confidence."
The method you've described for determining trustworthiness is worthless with self-signed certificates that you haven't already verified out of band (or chosen to trust the local signing CA for the cert) or in cases where the chain of trust for a certificate has been compromised. The people operating the shop on East Street could be honest merchants, and without being able to fully trust the PKI chain that verifies exactly who you're speaking to, a man in the middle could silently intercept (and potentially modify in transit) every byte of your communications with the East Street shop. After you've transmitted your credit card number, billing address, shipping address, etc, the MITM could simply log that data for later use.
A well known tactic of skimming/carding operations (both online and at brick and mortar stores) is to capture cardholder data and sit on it for a few weeks or months, then sell a large batch of such data to other criminals. Months down the road, unless you've used a unique card number everywhere you've shopped, you're going to have an extremely hard time determining where the compromise originated, and all the while the East Street merchant did nothing wrong.
You should care very much whether or not the web shop I'm connecting to is on East Street or West Street, and you should do your best to research merchants before transacting business with them. The usefulness of "web of trust" models is best realized under circumstances where groups of people with an interest in transacting such business communicate with one another regarding the trustworthiness of those they wish to do business with, along with those responsible for ensuring the cryptographic integrity of such communications.
In addition to my last reply, more astute readers might notice that the filenames for images served from screen.palegray.net might be cryptographic hashes. Indeed, they're Whirlpool hashes, which means in addition to the content being served over HTTPS, someone who really cared about verifying that the content hadn't been altered in transit could simply compare the Whirlpool hash of a downloaded file to its name. There's even a handy Perl Whirlpool module for such purposes.
That has nothing to do with the server at screen.palegray.net, which is a Debian VM running nginx to serve screen capture images. You're probably using Internet Explorer, and you're probably being prompted for whether or not you want to download the image file. The only thing being served from that link is in fact a PNG image (transcript from a simple curl test in a terminal on a Mac).
Calling someone an arsehole is pretty dumb when the "problem" at hand isn't even a problem, and instead arises from ignorance on your part.
You are the worst brand of stupid, the kind who is more interested in preserving his own ego than dealing with problems effectively. If you'd bother to spend ten seconds thinking about the core problem here, you'd realize that people have far more to worry about at the network edges of their destinations than they realize. Have you considered the possibility that those edges might be inclined to probe inward and check the trust chain associated with the destination, and maybe just maybe take selective action based on that information? Do you have any idea what sort of ramifications that scenario holds aside from dirt simple logging of the packets in transit, things like modification of the payload for whatever purposes the attacker desires?
I'm sick of being nice about this. Just shut the fuck up.
You stated, and missed the point of, the entire problem here, namely initial connection verification. OpenSSH should be treated in exactly the same manner, as it relies upon PKI in the same manner. Out of band fingerprint verification is essential to ensuring the integrity of such communications, which I'll reiterate you utterly failed to mention in your post while you were busy espousing the virtues of self-signed certs without any further guidance on the concerns associated with them. I verify every single key I accept via highly trusted out of band means. I'm fairly certain if I asked you how you'd manage to perform such verification, you'd spend fifteen minutes madly Googling answers and likely winding up parroting various one-liners you found on half-baked newbie forums (with self-signed certs, natually) to attempt to prove your expertise.
To address your second point, I'm not saying the feds haven't compromised large scale commercial CAs through friendly visits, but that's really not at all the most efficient means of intercepting and decrypting comms at wire speed. I say this as someone who could build you the infrastructure required to do that.
In short, stop talking and start learning. Shut your mouth for a few years to avoid dispensing horribly misleading "advice" to others in the general community, and have a nice day.
No, a self-signed certificate is not sufficient for what you're describing, or anything requiring actual security, unless you've set up your own CA in advance and added the corresponding root CA cert to your local PKI store (in the case that you're the operator of the forum), or added the root CA cert the forum is using (if any formalized CA infrastructure is being used at all on their end, given it's a self-signed cert) via an out-of-band source that you have reason to trust, or have a trustworthy out-of-band means of verifying the digital fingerprint of the certificate you're being presented with in the first place. The fundamental issue is simply that otherwise, the first time you visit the hypothetical forum site to register an account, you have no means of determining whether you're speaking directly to the forum server or a man in the middle. Men in the middle can be your ISP, the feds, whoever, and can have shall we say rather persistent presences in Internet architecture.
Please, please, please stop spreading misinformation like this. Please educate yourself, starting with Applied Cryptography. If you're not willing to speak intelligently on this topic, kindly stop misleading others and make your own mistakes in silence.
Let's just set aside the fact that inverting and/or flipping images isn't exactly rocket science, as it takes at most three clicks of a mouse to perform such operations. The simple fact is the GP is right; this is essentially the same technique I used eight years ago to defeat a fingerprint scanner. The technique works quite well, and has been employed using many a beer glass in the past for CID purposes.
In an attempt to reassure yourself that you're somehow smarter than those around you, you kind of ignore the fact that there are people here who have actually done what is being described. Nice try, though. Sweet dreams, cupcake.
"ScheisseFS" wasn't a disparaging reference to ReiserFS, which is actually a very solid and capable filesystem. Instead, the joke was the link between the imaginary "ScheisseFS" and the phrase "shitty solution." Apparently, you were too dense to get that, along with whatever mods docked the original comment. Have a great day!
Slashdot Mirror
Worse, he was a USMC Lieutenant Colonel.
I will note for the record that I draw a heavy line between Manning and Snowden. The former I would like to see executed, the latter I'd like to have a beer with. Anyone interested in the civil liberties of US citizens would understand the fundamental distinction between the two named persons.
As a very happily married man with a wife whose posterior is quite round, I'm continually confused by the prevalence of jokes about big butts which assign a negative value to that trait. Apparently, many women think most men want to date twigs.
Or, gee, I dunno, encrypt the email itself (along with its attachments) with PGP/GPG. I only have eight accounts with keys assigned to them.
Hi, former Navy guy here. Unfortunately, the US military hasn't executed anyone since 1961, although plenty of service members have committed capital offenses since then. I say this as someone who is a staunch opponent of capital punishment in the civilian sector, but has no patience or forgiveness for those convicted of espionage or treason while wearing a uniform.
You're completely out of your depth here, as you apparently aren't aware of the numerous and nasty cases of service members walking around with TS clearances who got into financial trouble and decided it was somehow a good idea to attempt to sell classified materials to foreign powers to make up for their losses.
I'm speaking as someone who served, and someone who was in service when a particular submariner was caught doing exactly what I just described. He's far from alone in his transgressions, and such offenses have occurred on both the enlisted and commissioned sides.
Stop talking about things you have no experience with.
I'm not interested about my ego -- I'm an AC, remember?
I find that many ACs tend to be more interested in their egos than signed-in users, especially the ACs that habitually check for replies to their anonymous posts.
I still think that self-signed certificates are an excellent way of getting encryption, packet integrity, /and/ verifying that it is still the same server. I cannot find anything in your posts that would refute that fact or why it would be misinformation.
You must have missed the bits about the absolute importance of determining who you're talking to the first time you make a connection.
(Your assumption seems to be that the attackers already control the infrastructure during the initial connection. My tinfoil hat is not /that/ tight. Besides, how would a "real" someone-else-vouched-for-me certificate help at that point?)
You seem to be placing an inordinate amount of trust in network operators, trust which is sorely misplaced, as I've seen firsthand. You've also handily demonstrated an utter and complete lack of understanding of how PKI encryption operates.
I certainly don't disagree with out-of-band cert verification and would try to offer a method to do that. Running an own CA would be a step up but mostly useful for larger projects only (Debian does it) -- hardly so for a hypothetical forum with only a single access point.
If you think only large projects run their own CAs, you're smoking some strong stuff. Every single employer I've worked for operated a CA for both internal and external purposes. I happen to operate three for various purposes. Be sure to inform your forum members that you don't shit two shits about their privacy.
It's been a couple of days since you made this unwarranted accusation. Adults apologize when they screw up. Are you an adult?
I probably shouldn't be replying to a troll, but what the hell, this one is just too hard to pass up. Thousands of companies around the world, including many of your favorite Fortune 500s, use Perl for tasks ranging from mission critical systems programming, to application integration, to enterprise reporting and sure, web applications. You must be living a pretty sheltered life; if you truly work in an enterprise environment, have you bothered taking a look at what powers your company recently? Hint: there's an awful lot of Perl (and Python, too) driving it, probably in places you don't even know exist in your infrastructure.
Son, I've been doing this professionally for fifteen years. Have a nice day!
Unless you know what you're doing and have a very good reason to use the modules under the Crypt namespace directly, you should generally be using Crypt::CBC with them, at least for most common purposes.
The actual Blowfish cryptography core of Crypt::Blowfish is written in C. You can verify this by downloading the tarball and looking at the source. There is a pure Perl version available as well, but it's slower.
The cores of Crypt::DES, Crypt::Rijndael, etc are also written in C.
I do most of my work in Perl, and I happen to heavily utilize Blowfish and Twofish. Perhaps you should think about what your application pipeline requirements actually need in terms of crypto and then look into the various modules that interoperate under the umbrella of Crypt::CBC.
If investors actually pay any attention at all to this news, the price will go up. IBM has essentially proven to its shareholders that they can once again go up against the federal government in cases like this and come out paying virtually nothing in fines, while not being required to take any meaningful action as far as policy revision goes. That's called "enhancing shareholder confidence."
You probably shouldn't have sold those shares.
This is a good idea.
The method you've described for determining trustworthiness is worthless with self-signed certificates that you haven't already verified out of band (or chosen to trust the local signing CA for the cert) or in cases where the chain of trust for a certificate has been compromised. The people operating the shop on East Street could be honest merchants, and without being able to fully trust the PKI chain that verifies exactly who you're speaking to, a man in the middle could silently intercept (and potentially modify in transit) every byte of your communications with the East Street shop. After you've transmitted your credit card number, billing address, shipping address, etc, the MITM could simply log that data for later use.
A well known tactic of skimming/carding operations (both online and at brick and mortar stores) is to capture cardholder data and sit on it for a few weeks or months, then sell a large batch of such data to other criminals. Months down the road, unless you've used a unique card number everywhere you've shopped, you're going to have an extremely hard time determining where the compromise originated, and all the while the East Street merchant did nothing wrong.
You should care very much whether or not the web shop I'm connecting to is on East Street or West Street, and you should do your best to research merchants before transacting business with them. The usefulness of "web of trust" models is best realized under circumstances where groups of people with an interest in transacting such business communicate with one another regarding the trustworthiness of those they wish to do business with, along with those responsible for ensuring the cryptographic integrity of such communications.
In addition to my last reply, more astute readers might notice that the filenames for images served from screen.palegray.net might be cryptographic hashes. Indeed, they're Whirlpool hashes, which means in addition to the content being served over HTTPS, someone who really cared about verifying that the content hadn't been altered in transit could simply compare the Whirlpool hash of a downloaded file to its name. There's even a handy Perl Whirlpool module for such purposes.
That has nothing to do with the server at screen.palegray.net, which is a Debian VM running nginx to serve screen capture images. You're probably using Internet Explorer, and you're probably being prompted for whether or not you want to download the image file. The only thing being served from that link is in fact a PNG image (transcript from a simple curl test in a terminal on a Mac).
Calling someone an arsehole is pretty dumb when the "problem" at hand isn't even a problem, and instead arises from ignorance on your part.
Avoid what? A PNG file?
Also, anybody who doesn't get the irony of what's shown in that screen capture (in the context of this story) didn't look at it long enough.
You are the worst brand of stupid, the kind who is more interested in preserving his own ego than dealing with problems effectively. If you'd bother to spend ten seconds thinking about the core problem here, you'd realize that people have far more to worry about at the network edges of their destinations than they realize. Have you considered the possibility that those edges might be inclined to probe inward and check the trust chain associated with the destination, and maybe just maybe take selective action based on that information? Do you have any idea what sort of ramifications that scenario holds aside from dirt simple logging of the packets in transit, things like modification of the payload for whatever purposes the attacker desires?
I'm sick of being nice about this. Just shut the fuck up.
You stated, and missed the point of, the entire problem here, namely initial connection verification. OpenSSH should be treated in exactly the same manner, as it relies upon PKI in the same manner. Out of band fingerprint verification is essential to ensuring the integrity of such communications, which I'll reiterate you utterly failed to mention in your post while you were busy espousing the virtues of self-signed certs without any further guidance on the concerns associated with them. I verify every single key I accept via highly trusted out of band means. I'm fairly certain if I asked you how you'd manage to perform such verification, you'd spend fifteen minutes madly Googling answers and likely winding up parroting various one-liners you found on half-baked newbie forums (with self-signed certs, natually) to attempt to prove your expertise.
To address your second point, I'm not saying the feds haven't compromised large scale commercial CAs through friendly visits, but that's really not at all the most efficient means of intercepting and decrypting comms at wire speed. I say this as someone who could build you the infrastructure required to do that.
In short, stop talking and start learning. Shut your mouth for a few years to avoid dispensing horribly misleading "advice" to others in the general community, and have a nice day.
No, a self-signed certificate is not sufficient for what you're describing, or anything requiring actual security, unless you've set up your own CA in advance and added the corresponding root CA cert to your local PKI store (in the case that you're the operator of the forum), or added the root CA cert the forum is using (if any formalized CA infrastructure is being used at all on their end, given it's a self-signed cert) via an out-of-band source that you have reason to trust, or have a trustworthy out-of-band means of verifying the digital fingerprint of the certificate you're being presented with in the first place. The fundamental issue is simply that otherwise, the first time you visit the hypothetical forum site to register an account, you have no means of determining whether you're speaking directly to the forum server or a man in the middle. Men in the middle can be your ISP, the feds, whoever, and can have shall we say rather persistent presences in Internet architecture.
Please, please, please stop spreading misinformation like this. Please educate yourself, starting with Applied Cryptography. If you're not willing to speak intelligently on this topic, kindly stop misleading others and make your own mistakes in silence.
I can't help but find this a little ironic given the context of this story.
56 Marietta is a nice facility, though.
To get firmly back on topic, what you're suggesting is unworkable for many reasons. I've seen a few of those reasons firsthand.
Let's just set aside the fact that inverting and/or flipping images isn't exactly rocket science, as it takes at most three clicks of a mouse to perform such operations. The simple fact is the GP is right; this is essentially the same technique I used eight years ago to defeat a fingerprint scanner. The technique works quite well, and has been employed using many a beer glass in the past for CID purposes.
In an attempt to reassure yourself that you're somehow smarter than those around you, you kind of ignore the fact that there are people here who have actually done what is being described. Nice try, though. Sweet dreams, cupcake.
Since I love awful puns, I think that's funny :).
"ScheisseFS" wasn't a disparaging reference to ReiserFS, which is actually a very solid and capable filesystem. Instead, the joke was the link between the imaginary "ScheisseFS" and the phrase "shitty solution." Apparently, you were too dense to get that, along with whatever mods docked the original comment. Have a great day!
I could tell by the pixels.
I guess nobody got the joke.