Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Apart from Let's encrypt, what other options exist to obtain free SSL certificates? - Page 4
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Apart from Let's encrypt, what other options exist to obtain free SSL certificates?

124

Comments

  • @joepie91 said:
    And there we go again with the expert-sounding bullshit. The Infineon incident had absolutely nothing to do with TLS/SSL.

    Except that is was everything to do with ssl/tls...

    If you'd bothered to do even a modicum of research, you'd know that it concerned a bug in a hardware implementation of RSA.

    ... says clueless big snout joepie who evidently considers arstechnica as relevant and even a reference (somewhat like "I read popular mechanics. I'm a rocket scientist!").

    As even simple reading obviously is intellectually out of reach for you, I'll make it easy and quote the relevant phrase directly for you -> "The flaw resides in the Infineon-developed RSA Library version v1.02.013,...". Library, not chip. Slight difference.

    A closer look and understanding the hints ("Coppersmith attack") shows that rsa was cluelessly and carelessly implemented - and certified as secure! - and now the security reduction of rsa doesn't hold anymore ("factorization of sufficiently large n \elem N is NP") on many devices, id cards, etc.

    rsa being one of the two basic modules available in ssl/tls PK (the other one being ecc) and ssl/tls using it since decades and fucking obviously still very often using and being based on it, it's really rich to say there is no connection whatsoever.

    But then, you are a clueless big snout. qed.

  • joepie91joepie91 Member, Patron Provider
    edited October 2017

    bsdguy said: As even simple reading obviously is intellectually out of reach for you, I'll make it easy and quote the relevant phrase directly for you -> "The flaw resides in the Infineon-developed RSA Library version v1.02.013,...". Library, not chip. Slight difference.

    Almost every dedicated hardware crypto device (in end-user form factor, not as an acceleration chip) uses a generic processor architecture running custom code. This doesn't change anything about what I've described. Their library was designed specifically for their own/customers' hardware.

    bsdguy said: rsa being one of the two basic modules available in ssl/tls PK (the other one being ecc) and ssl/tls using it since decades and fucking obviously still very often using and being based on it, it's really rich to say there is no connection whatsoever.

    Since you apparently have trouble reading; what I stated was "no direct connection". And this remains true; RSA is an independent cryptographic primitive that can be (and is!) used in a wide variety of applications, and one of those applications happens to be TLS (which, by the way, supports a wide variety of cryptographic primitives in various permutations, far more than the "either RSA or ECC" you're claiming).

    Not only that, but the issue here was an implementation issue on Infineon's end, and not a design issue in RSA. To bring out the tired car analogy; your claim is analogous to claiming that cars (TLS) are a flawed concept because one car manufacturer somewhere (Infineon) used the wrong tolerances on a drive shaft (RSA implementation).

  • Here we go again. He knows little but barks a lot.

    "it concerned a bug in a hardware implementation of RSA" vs. "The flaw resides in the Infineon-developed RSA Library" ... and after been shown bloody obviously wrong joepie, the clueless terrier just declares that, oh hell, chip, library, what's the difference.

    As for the "wide variety of cryptographic primitives", the ssl/tls sectarian cerberus wannabe terrier once more simply didn't understand. My statement was explicitly talking about PK (a common abr. for "public key (crypto)"), but, oh well, how should a joepie know about crypto lingo...

    Please, feel free, to tell me about all those currently available PK algorithms in ssl/tls that are not rsa or ecc based.

    End btw, even the last statement was wrong and shows how clueless you are. If a design allows an implementation to use ill-advised/weak values - as rsa does - then it's not simply an "implementation problem".

    Boy, it's obvious that you are not even remotely near the crypto community. Plus, it's obvious that you are utterly clueless, even stupid in your fanatic sectarian attempt to "defend" your pro ssl/tls belief system. Let me give you a hint that even beginners wouldn't need but stupid terriers do: Anything and everything in crypto it is consistently rattled, shaken, and attacked - that's part of how we work; that's how we make sure that - unlike sectarian idiots - what we say stands on solid legs. After all, it would be worthless to state that ABC is secure unless we ourselves have tried our very best to crack or considerably weaken it.

    Accordingly, when I "attack" ssl/tls I simply follow good professional habits. And btw, there have been plenty creepy ssl/tls and related problems and there is a point where designers must ask themselves whether they did something wrong when all those bad implementations come up. The current case is one more of such cases; it strongly hints that the design isn't stringent enough and basically invites lousy implementations.

    Keep in mind that the guys at Infineon are not incompetent idiots and be sure that they can cite the standards and guidelines in half-sleep. This case shows two weak points: a) complexity (which is solidities enemy) and b) we need a more stringent rsa "standard" (incl. in fips, eal etc); parameters there were good enough decades ago aren't good enough any more. Something pretty much inviting Coppersmith's attacks (not exactly new either btw.) isn't good enough.

  • WSSWSS Member

    Just use rot13 twice.

    Thanked by 1JackH
  • joepie91joepie91 Member, Patron Provider
    edited October 2017

    bsdguy said: "it concerned a bug in a hardware implementation of RSA" vs. "The flaw resides in the Infineon-developed RSA Library" ... and after been shown bloody obviously wrong joepie, the clueless terrier just declares that, oh hell, chip, library, what's the difference.

    "Hardware implementation" here refers to "implementation in a hardware device", which can be either software-defined or an actual custom IC. You're intentionally misinterpreting what I'm saying just so you can feel like you have a point. At no point did I claim a custom chip, those are your words entirely.

    bsdguy said: As for the "wide variety of cryptographic primitives", the ssl/tls sectarian cerberus wannabe terrier once more simply didn't understand. My statement was explicitly talking about PK (a common abr. for "public key (crypto)"), but, oh well, how should a joepie know about crypto lingo...

    Please, feel free, to tell me about all those currently available PK algorithms in ssl/tls that are not rsa or ecc based.

    Fair enough, I overlooked the "PK" in that phrase.

    bsdguy said: End btw, even the last statement was wrong and shows how clueless you are. If a design allows an implementation to use ill-advised/weak values - as rsa does - then it's not simply an "implementation problem".

    This is utter nonsense. Yes, a specification should be designed to be hard to implement incorrectly. No, a specification isn't poorly designed merely because it can be implemented wrong. Any specification can be implemented wrong, even formally verifiable ones if you skip the verification step; that's inherent in how programming works.

    By your standard, literally every primitive ever will always be poorly designed. This is obviously not reasonable.

    bsdguy said: <yadda yadda ego-stroking snipped>

    You can leave out all the noise about how fantastic and professional you are. Unless it's a technical argument, I don't care. And you're getting those consistently wrong.

    bsdguy said: And btw, there have been plenty creepy ssl/tls and related problems and there is a point where designers must ask themselves whether they did something wrong when all those bad implementations come up. The current case is one more of such cases; it strongly hints that the design isn't stringent enough and basically invites lousy implementations.

    And there have indeed been design problems in SSL/TLS in the past. Which is why we're now at TLS 1.3, and many previous versions have been deprecated. If you truly understood that process of "consistently rattling, shaking and attacking", then you'd understand that this is precisely what is happening with TLS, and that spreading FUD about an entire protocol family based on the flaws in past, already-deprecated versions is completely unreasonable.

    As for broken implementations: I challenge you to find me a widely used cryptographic protocol of which there provably exist zero (publicly used) broken implementations. You're not going to find one. Programmers are going to make implementation mistakes, regardless of the design of the protocol; unless you can show concrete scientifically valid evidence that TLS makes it easier than average to implement it incorrectly, this is a moot point.

    And no, "look at all these news articles" is not scientifically valid. I'm asking for a concrete, objective assessment of TLS and its competitors, looking at their respective featureset, design issues, and so on.

    bsdguy said: Keep in mind that the guys at Infineon are not incompetent idiots and be sure that they can cite the standards and guidelines in half-sleep.

    What are you basing this on? Do you work at Infineon and control its (hiring and training) processes, or are you just assuming this to be the case?

    bsdguy said: This case shows two weak points: a) complexity (which is solidities enemy) and b) we need a more stringent rsa "standard" (incl. in fips, eal etc); parameters there were good enough decades ago aren't good enough any more. Something pretty much inviting Coppersmith's attacks (not exactly new either btw.) isn't good enough.

    As far as I am aware, RSA with a sufficiently large exponent and a good random source is not vulnerable to any of this. What FIPS says is out of scope for both TLS and RSA; from a cryptography perspective, it's nothing more than a recommendation from an arbitrary third party.

    Thanked by 1TheLinuxBug
  • @joepie91

    I have a new lesson for you: Just barking, making up things, and stubbornly asserting something doesn't get you the attention you so urgently seek. See a psychologist; at least he gets payed for responding to your barking.

  • Was there ever a discussion thread in the history of internet security that didn't devolve into an ideological religious like debate?

  • @bsdguy said:
    @joepie91

    I have a new lesson for you: Just barking, making up things, and stubbornly asserting something doesn't get you the attention you so urgently seek. See a psychologist; at least he gets payed for responding to your barking.

    Since I have no useful counterargument to the argument proposed, I will instead attack the author.

    Thanked by 2MasonR luissousa
  • raindog308raindog308 Administrator, Veteran

    bsdguy said: clueless big snout joepie

    bsdguy said: intellectually out of reach for you

    bsdguy said: clueless big snout

    bsdguy said: you are utterly clueless

    Is it possible for you to discuss without ad hominems? @joepie91 is (mostly) attacking your ideas, while you are mostly attacking him.

    bsdguy said: I have a new lesson for you: Just barking, making up things, and stubbornly asserting something doesn't get you the attention you so urgently seek. See a psychologist; at least he gets payed for responding to your barking.

    Ironically, @joepie91 actually publishes code while our only source for your expertise is your own claims.

    Now I happen to think you're actually an expert. But when your main weapon is ad hominems, skepticism is inevitable and your credibility suffers.

  • bsdguybsdguy Member
    edited October 2017

    @raindog308

    Just have a look. That dick returned and immediately and out of nowhere ran an attack on me as a person (in this thread that was pretty much sleeping since days). -> https://www.lowendtalk.com/discussion/comment/2440742/#Comment_2440742

    And btw, no, my own claims are not the only source for my expertise. I talk enough about crypto and I make enough statements that will allow anyone with some expertise in the field (where code is but one of many criteria) to judge me. But frankly, I do not even care about being recognized as an expert here. Here at LET ones standing is determined by contributions and hopefully a readiness to help out in this field here. And bringing up joe terriers open source is meaningless anyway; relevant would be the question of its quality.

  • joepie91joepie91 Member, Patron Provider

    bsdguy said: I talk enough about crypto and I make enough statements that will allow anyone with some expertise in the field (where code is but one of many criteria) to judge me.

    And I have, as have others. And you continue to ignore those judgments and instead try to attack the people making them.

  • @WSS said:
    Just use rot13 twice.

    Nah, dude, that's not secure enough.

    What you have to do is: rot13 --> gzip --> uuencode --> rot13. This is so non-obvious that not even the Russians would think of this!

    Thanked by 1JackH
  • WSSWSS Member

    But you have to use rot13 twice in sequence for the benefit.

    Thanked by 1JackH
  • raindog308 said: We don't know the extent of the NSA's capabilities, and there is an excellent, well-known case where they did backdoor perhaps the most prominent cipher in American history using technology that wasn't known in the public until 20 years later: DES's S-boxes.

    Meanwhile, much of the world is letting some random Ukrainians analyze all their text for grammar errors on some remote cloud with ambiguous data handling practices...

  • @WSS said:
    But you have to use rot13 twice in sequence for the benefit.

    A real crypto expert would subtract 3 at the end, you pretty but amateur cunt.

  • @WSS said:
    But you have to use rot13 twice in sequence for the benefit.

    Nah, I've read something about cryptology, using rot13 twice in sequence is now considered too weak (this has been proven), if you want something reasonably secure, you have to apply rot13 four times, but to be super secure I would add gzip and uuencode and rot13 to that. In sum:

    rot13 --> rot13 --> rot13 --> rot13 [this is reasonably secure]

    rot13 --> rot13 --> rot13 --> rot13 --> gzip --> uuencode --> rot13 [this is super secure]

  • WSSWSS Member

    @angstrom said:
    rot13 --> rot13 --> rot13 --> rot13 --> gzip --> uuencode --> rot13 [this is super secure]

    But then you leave yourself to a MitM (Minecraft in the middle) zombie attack if you don't keep the rot14 process in RAM and use that data output before going through gzip. Gzip uses deflate, which is a known open source tool written in C, and therefore it is pure garbage. uuencode has also been deprecated in favor of inline base64. cpio is still used rather than tar, as tar is still unproven as it has different implementations and none of them are correct.

  • @angstrom, @WSS

    Amateurs all over the place. Subtracting 3 after dual rotl-13 is level 4 secure, of course only when the crypto is properly done. If you want to enhance that you must use dual rotl-13 - rotr-13 before subtracting 3.

    If you need level 7 security, though, you need rsa-32 implemented in javascript and preferably as a browser plugin.

  • angstromangstrom Moderator
    edited October 2017

    @WSS said:

    @angstrom said:
    rot13 --> rot13 --> rot13 --> rot13 --> gzip --> uuencode --> rot13 [this is super secure]

    But then you leave yourself to a MitM (Minecraft in the middle) zombie attack if you don't keep the rot14 process in RAM and use that data output before going through gzip. Gzip uses deflate, which is a known open source tool written in C, and therefore it is pure garbage. uuencode has also been deprecated in favor of inline base64. cpio is still used rather than tar, as tar is still unproven as it has different implementations and none of them are correct.

    Dude, we can use zip instead of gzip -- wasn't zip closed source at one point? Or rar if not tar. The point about uuencode is that no one thinks of it anymore, so that makes it a good crypto strategy, you follow me? And don't tell me about MitM zombie attacks -- you're confusing Minecraft with zombie here. Like I said, I've read something about cryptology cryptography.

  • @bsdguy said:
    @angstrom, @WSS

    Amateurs all over the place. Subtracting 3 after dual rotl-13 is level 4 secure, of course only when the crypto is properly done. If you want to enhance that you must use dual rotl-13 - rotr-13 before subtracting 3.

    If you need level 7 security, though, you need rsa-32 implemented in javascript and preferably as a browser plugin.

    Man, you're just using fancy words to try to impress us. But @WSS and I, we know better than to fall for that!

    Thanked by 1TheLinuxBug
  • raindog308raindog308 Administrator, Veteran

    @bsdguy said:

    @WSS said:
    But you have to use rot13 twice in sequence for the benefit.

    A real crypto expert would subtract 3 at the end, you pretty but amateur cunt.

    if the algorithm was good enough for the emperor of the Roman Empire, it's good enough for anyone!

  • WSSWSS Member

    @bsdguy said:
    If you need level 7 security, though, you need rsa-32 implemented in javascript and preferably as a browser plugin.

    Personally, I just use the older known backdoored Stronghold. Who the fuck needs LE certificates when anyone can request them? If you use something that is easy to crack in a 32 bit world, everyone in a 64 bit world will have to slice off half their data lines to crack it!

    @angstrom said:
    Dude, we can use zip instead of gzip -- wasn't zip closed source at one point? Or rar if not tar. The point about uuencode is that no one thinks of it anymore, so that makes it a good crypto strategy, you follow me? And don't tell me about MitM zombie attacks -- you're confusing Minecraft with zombie here. Like I said, I've read something about cryptology cryptography.

    We'd have to use zoo. Nobody remembers zoo, much like uuencode, but even less likely to be discovered. Then we use an Amiga and lha the uuencoded copy. But the Amiga must be an LC020 so it does floating point math so we can completely handle every step of the encoding step by step in a debugger.

  • @WSS said: @angstrom said: Dude, we can use zip instead of gzip -- wasn't zip closed source at one point? Or rar if not tar. The point about uuencode is that no one thinks of it anymore, so that makes it a good crypto strategy, you follow me? And don't tell me about MitM zombie attacks -- you're confusing Minecraft with zombie here. Like I said, I've read something about cryptology cryptography.

    We'd have to use zoo. Nobody remembers zoo, much like uuencode, but even less likely to be discovered. Then we use an Amiga and lha the uuencoded copy. But the Amiga must be an LC020 so it does floating point math so we can completely handle every step of the encoding step by step in a debugger.

    That's good crypto thinking, man. The only practical problem is that if we need an Amiga both to encrypt and decrypt, this could be tricky in practical terms: I mean, how many Amigas are left in the world? So I would suggest that we stick to the familiar platforms for practical reasons, you get me? This still leaves us with a lot of crypto possibilities.

  • WSSWSS Member

    We could port UAE to the Pi! Wait, scratch that - it's already been done. Maybe a 128k Mac with SeaTools?

  • @angstrom said:
    Man, you're just using fancy words to try to impress us. But @WSS and I, we know better than to fall for that!

    "subtracting" is just mildly fancy (for real crypto people). If I had wanted to brag I'd have mentioned "nodejs".

    @raindog308 said:
    if the algorithm was good enough for the emperor of the Roman Empire, it's good enough for anyone!

    Well he is said to have used a single rotl-13 only, but then they only had PDP-11s at that time or maybe, at the very maximum, a simple 6502, so single rotl-13 was damn good enough.

    @WSS said:
    Personally, I just use the older known backdoored Stronghold. Who the fuck needs LE certificates when anyone can request them? If you use something that is easy to crack in a 32 bit world, everyone in a 64 bit world will have to slice off half their data lines to crack it!

    Bloody right. Plus an expensive brand name rsa-512 certificate from diginotar to keep them "cool" 64-bit wannabes at bay.

  • "Funny" interlude:

    As I am a friendly guy I try to provide windows versions of my stuff, too. After many years of using an xp VM (I know, I know, but hey, it's just windows shit, so what) I have decided now and am currently in the (%%"§$!&##) painful process of installing everything new (with win81). And utterly incredible things happen. If I ever had doubts for a single split second about which OS to use everyday, anything, really anything done in windows will quickly remind me ...

    It's just fucking incredible, how shitty windows is. For a start, I needed to get some extra thingy (classic shell) to get rid of the new "clicking isn't exiting enough. Nowadays the idiots want to click on coloured tiles" pestilence "interface". Next replacements for some basic tools which the windows team in over a decade failed to bring up to par. A halfway decent file manager, a simple small editor, etc. In between a zillion times their "security" popups. It seems one can do absolutely nothing in windows without being molested by those; and, of course, they are utterly useless (like most in windows) and about as sensible as a "civilised greeting" button when dealing with a crocodile on crack.

    But now, the hammer. As microsoft doesn't have imbecile loser departments and looney bins only but also (probably tucked away in some basement) a couple of people with a brain who design and build really nice things like vcc (c verifier), dafny, and some others there are actually some things from microsoft that I do like. But then, microsoft wouldn't be microsoft if that was easy to get and use. Nope, one needs to install their megabloat-monster visualstudio. 10 GB or so for a compiler! Did they include whole movie dvds as easter eggs or what?

    Wait! It gets even better. Trying to build vcc with the megabloat monster fails. Reason: some env variable and some python pestilence. It turns out that I need to download yet another C compiler specifically for python! Fucking incredible. They really dare to shit some 10 GB of vs compiler on my drive and then have the chuzpah to demand that I download another C compiler which I'll never again use, btw; it's for installing something only.

    And people actually pay for being tortured by microsoft! I'm amazed.

  • MaouniqueMaounique Host Rep, Veteran
    edited October 2017

    raindog308 said: Is it possible for you to discuss without ad hominems? @joepie91 is (mostly) attacking your ideas, while you are mostly attacking him.

    I wish you would be this "moderatory" regardless of the target and perpetrator of such attacks and their opinions.

  • WSSWSS Member

    @Maounique said:

    raindog308 said: Is it possible for you to discuss without ad hominems? @joepie91 is (mostly) attacking your ideas, while you are mostly attacking him.

    I wish you would be this "moderatory" regardless of the target and perpetrator of such attacks and their opinions.

    Low hanging fruit is still just that.


    @bsdguy why didn't you stick with 7? 8 is the worst, but 8.1 is purely vile. 10 is actually fairly usable with classic shell, but I won't use it myself. XP/7 depending on if I need 16 bit support or not for automotive/compatibility use only.

    I can't see any reason to use 8.1 over 7 at this point. It's not dead yet.

  • bsdguybsdguy Member
    edited October 2017

    @WSS

    Frankly, the reason is pure ignorance and the (probably naive) assumption that with 8.1 I'll be good for another couple of years.

    Once everything is installed, it's OK. Of course, to use windows is torture for anyone with a brain but one gets used to the flow, in particular as I use only very few and always the same programs. All I need is to compile (not design and develop, god beware) some stuff and to test that it works OK in windows.

    Funny side remark: My real OS (FreeBSD) uses by far less resources although I have a quite rich set of tools installed. Hate is not big enough a word to describe what I feel for microsoft for their windows crimes.

  • MaouniqueMaounique Host Rep, Veteran
    edited October 2017

    WSS said: I can't see any reason to use 8.1 over 7 at this point. It's not dead yet.

    Hear, hear...

    And what is wrong with XP? Isolated in a VM used for compiling stuff and all, properly placed after 2 firewalls...

    I still use it for games, even, because of the low footprint i nLited years ago and my crappy machines which are slow on native OS not to mention VMs, also because i have tons of licenses.

Sign In or Register to comment.