Hacker News new | past | comments | ask | show | jobs | submit login

The linked article is all about protecting data in flight like in the TLS case. PGP is all about protecting data at rest. The two applications are fundamentally different.



I think you're misunderstanding the general complaint or maybe not the complaint but how general, rather than specific it is.

At the top of the thread someone says 'PGP has all this ancient cruft and also isn't good for email/email is maybe unsecurable anyway'. The PGP-enthusiast response to that is 'No problem! You see, PGP is so flexible, you can build anything out of it, including maybe an actually-secure system of some sort'.

This is a fundamentally inadequate response and we've realized it's inadequate and don't really design secure systems like that anymore. In fact, this class of concern has permeated almost all aspects of contemporary software systems design rather than being something narrowly limited to 'crypto algo agility is bad'. Here's an example/illustrative timeline that doesn't have anything to do with 'data at rest'.

1998 Netscape: Behold our cross-platform, cross-language super-toolkit for building super-extensible Enterprise Groupware apps. Also one of them is a web browser!

2015 Mozilla: [belated forehead slap] This is a terrible way to architect a web browser that has any hope of offering end-user security.


How do you do a downgrade attack on, say, an encrypted backup?


I guess I don't understand how that's a response to anything I've written in this thread.

Edit: I'll expand the quote from the original thing a bit if it helps:

(Open)PGP is first and foremost a flexible packet format (and other specs), and GnuPG is more of a CLI "library" to interface with it -- all of it. You can build something that hides metadata, you can have forward secrecy, and encryption always-on by default with PGP (and GnuPG). You can use it for whatever trust model you want, neither OpenPGP (the specs) nor GnuPG prescribe a certain model. It provides building blocks.

This is a huge 'nope'. It's, by this point, an uncontroversial, well-understood nope. A known-nope, if you will! The only people who don't seem to think so are PGP people and that, in itself, is rather telling.


You can't just "Nope" this issue. You need to come up with some sort of rational argument. The PGP people have been dealing with the data at rest issue since forever. It is a bit presumptuous to just write off all that acquired wisdom without reason.


I have come up with a rational argument, you just refuse to address it at all. Your argument boils down to 'the PGP people are smarter than everyone else' which I think isn't really even a rational argument.


There is no reason to appeal to authority here when a simple koan can provide enlightenment. I will repeat it one more time:

How do you do a downgrade attack on, say, an encrypted backup?


No. We've got a threadful of arguments here in which you simply refuse to engage. You don't get to superciliously demand Socratic satisfaction, wave around your list of logical fallacies and mumble oracularly about koans and enlightenment. You have to make an argument otherwise what you're doing is simply rude preening. It's fine if you have nothing to say. You don't get to (at least, publicly) pretend you've actually said anything and that it's everyone else who has to meet your precise terms of discussion. Sorry.


This all started when you said something to the effect that "packet oriented formats" were bad. When asked to clarify you switched the topic to how flexibility in cryptography was bad because it could lead to downgrade attacks. I pointed out that downgrade attacks were not really possible in a data at rest application and that the article you linked to was about data in flight applications.

That's it. That's the actual arguments to this point. Then you just said nope.

You are not claiming that logic and facts are irrelevant here, are you?


you switched the topic to how flexibility in cryptography

I never said that. You're replying to someone else.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: