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.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
SHA1 is Shattered
This discussion has been closed.
Comments
I assume there was a trivial DNS poisoning attack?
That's what many call a religious argument. Fact is that eff says that they are and seem to be the good guys (who just happen to have rather strange cross connections to known soros and cia front-ends).
Moreover people thinking "ABC is the good guys" is largely the result of a social operation. But that's not really the information we're interested in. What we really want to know is whether LE is technically sound designed and implemented.
Maybe they actually are the good guys, maybe not. But even if they were the good guys that doesn't mean that LE are good guys, too, let alone that LE's mechanism is sound.
I don't believe in replacing what once was the papal throne with eff. I prefer science and sound proof.
https://crt.sh/?q=24ba82659f808f6c5af1816857701bf970cf6ec5751357fea42ef8c4140a4caf
Of course, someone registered the domain in question yesterday..
LE says:
What do you mean by that?
Thanks for the share. I did read the discussion doesn't look like LE is in the wrong. Squarespace has registered a domain and released it after getting a certificated from LE. It's not an attack on LE. It can happen with traditional certificate authorities too.
I am not a fanboy of LE but I believe in opensource. if we can corner LE, we can corner any certificate authority too. I would like to know a single CA who doesn't operate under any pressure from government and free to operate at its own will.
If anyone is interested in reading the discussion it's here
The ACME is available for your anyone's review. If you find any security flaws you can report it that's the very nature of FOSS.
C is ambigous. But that's not said to bash C. Again, I use it myself sometimes, although in unusual ways and a weird toolset.
While most other languages are somewhat better in that regard, we actually have extremely few languages that lend themselves to and support provably correct code.
@MrKaruppu
"Religion" again. That said, I'm in no way opposed to open source; I think, however, that "it's foss!" doesn't cut it, that's not good enough. And I think that we should start to discern between fairy tales and facts.
Example: "1000 eyes" - that's provably bullshit. Frighteningly often it's not even 4 properly working and knowlesgable eyes (-> heartbleed)
And it demonstrates quite well what I'm saying. "1000 eyes" is half a social statement and half a statistical assumption (and wrong one).
The response to "is this realiable safe code?" isn't "1000 eyes" but mathematical proof.
But again: I don't want to missionize you in any way or bash foss. But I'm not content with fairy tales and religion.
It's a solid point which you had posted here. I do agree FOSS doesn't mean safe and secure. I meant to say, It gives you an opportunity to check it yourself. if anyone is wary of the tool that they use they can check it and anyone can check it.
If you are wary of LE you can find out it's flaws and report it.That would be the scientifically satisfying proof which you will need.
a) Sure, but I can as well consider it tainted and avoid it. The way I see it it's not me to prove that LE isn't good - it's their task to prove that they are.
b) Nope, it's more complicated than looking at the code. Code is just a part of it. If one were to examine it one would also need to examine the premises, the spec, the model, and the contextual assumptions and interactions. The code is but the implementation and one could have a perfectly good and safe implementation of a flawed and insecure model.
c) I strongly dislike LE also because they put lots and lots of cement into the current PKI system which is rotten and flawed to the core. Funnily the very same foss community that praises LE - which is in full acceptance of and cementing current PKI - at the same time tries to compensate the grave flaws of the current PKI in different ways (e.g. cert pinning).
For me that alone demonstrates amply enough that LE is not about generosity and security but about something quite different.
That said, again: I have no interest in missionizing. If you feel foss/LE is great and good and noble go ahead; I won't disturb you (unless the matter happens to come up).
I could disagree with some of your wording for the sake of disagreement, but I've just realised Civ 6 is out on Linux, so I'll have to put everything on hold for 6 months.
Well, CA is broken and I do not think there can be such a model which is not. Absolutely safe communication validated by a third party cannot exist.
It will work for regulator approved stuff, such as banks and the like, because there is nothing else out there and the regulators specifically trust what they regulated (the CA issuers) which are supposed to follow a clear set of rules.
As long as there is no way to regulate secure communication which does not depend on a third party, we are fucked. Me and you can use own certificates or use other means of encrypting, but in the relation with an authority of some kind, it wont work, they will never agree to your encryption scheme, you will have to use theirs.
crc32 is even faster
tl;dr, sorry
I reinstalled a server of mine a few days ago. When I read about that recent news about SHA1 I checked my dm-crypt partition which was installed during installation process of debian jessie.. which uses SHA1..
Good that @willie mentioned that.
Non-collision is one of multiple important properties of a hashing function. Maps or dictionaries or whatever your languages calls them are a good example. You certainly don't want to see two different items have the same hash value.
And this property is what has been successfully broken. Some researchers succeeded to find (calculate) to different PDFs ending up having the same Sha1 value.
The property that is far more relevant for password storage and similar is irreversability. That means that having a given hash one can not possibly find the cleartext behind the hash.
This property has not been successfully broken.
Summary: While stronger hashing algorithms would certainly be desirable, using Sha1 does not equate to being utterly insecure.
Important hint: Unless you use an encrypted connection (e.g. ssh) your password is sent cleartext. Reason: It i only on the server that the cleartext password gets hashed and compared to the stored hash.
For FDE this isn't an immediate concern. Being able to cause a collision between two calculated values is a different ball park to being able to (more) easily break your key -- in this, they can change both values. In the case of your key, they can only change one.
This does however mean that sha1 is aging and alternatives should be used in future, where feasible.
No, it's genuine crypto and there are many real-world systems based on it. OTP is truly unbreakable cryptography, as in "information theory proven", or "secure against even adversaries with infinite computational power". The Wikipedia article gives more details, as well as problems.
https://en.wikipedia.org/wiki/One-time_pad
So why doesn't everyone use it? It's enormously cumbersome to implement. For example, if I want to send you a 4GB message, I need to have a 4GB key. Even more annoying, you have to have the exact same 4GB key, and we can only use it exactly once. If I reuse any part of the key, the entire system is quite trivial to break. And of course, keys have to be synchronized. Plus all the usual problems of generating high volumes of truly random data. And if I don't have a secure communication system, how do I get you that 4GB of key?
Now if you're the NSA designing a system for the US embassy in Moscow to talk with Washington and you can send a practically infinite amount of keyspace in diplomatic pouches and have battalions of Marines to guard everything, or if we're talking about a nuclear sub communicating with the pentagon, etc. - then yes, OTP is truly perfect. However, in real world applications, public key crypto is much, much easier to implement.
I linked to the Venona case, which is a famous case of an OTP system being compromised by key reuse (in this case, back in the pen-and-paper days of the early 40s when the Soviets were reeling under German invasion).
Or, you know, we can go back to listening on shortwave radios to find our latest code every time we want to login.
If you're as nerdy as I am and actually find this sort of thing intriguing- here's a great piece of YouTube where a numbers' station device was recovered and some hardware specs-
I honestly had no idea what an amazing pile of crap openssl was until I heard Ted Unangst's presentation on libressl:
Heartbleed is less "exceptional bug" and more "typical code" in openssl land...
Nope, at least not in the case of a submarine. Simple reason: usually very limited connectivity.
That's where high quality and verified/proven to spec pseudo random generators enter the game, or more precisely, a set of those. Well noted, I'm not talking about a pimped up mersenne twister.
Plus frequent and irregular shifting using another prng.
Example: You have, say 129 prngs, the first one feeding the driver, which is looking at each random string created and, based on some algo with good irregularity, choses one of the 128 other prngs to create the next x bytes of random.
As both sides have the same setup the decisive factor is a (true) kickstart random that is transferred at the start of a session (encrypted) so was to seed first the driver and then all the other prngs.
It's a classical space vs computation trade-off that makes sense for two reasons: a) practically (due to computing power being available) and b) in terms of OpSec as you want a good setup/payload ratio and small startup data exchange.
Where an OTP, albeit for other reasons, comes into play could be the encryption keys for the startup value. This at the same time offers some form of multiple factor crypto.
Depending on the universes of the prngs (typically larger than 2^1000) this provides near OTP security plus good ratio, low overhead, multi-factor and high flexibility.
I'm sorry, but this doesn't make sense to me.
First, you may be thinking of the old ELF days, where it could take 15 minutes to send 3 characters. Subs on VLF chat at about 300 baud today. That's...135KB an hour? That's a good sized document.
But regardless, what does the bandwidth matter? You're got to encrypt it with something, no matter how small it is. Since you already have a very secure means of key exchange (assuming we consider the US Navy to be secure) and the personnel to manage things (not to mention the NSA to design it all for you), there's no reason not to use an OTP scheme.
BTW, those limitations are underwater...submariners have been sending and receiving email for decades.
@raindog308
I didn't say that OTP is somehow bad. But you see, it's not just 1 transmission. As for the navy (or any military for that matter) don't ignore how they tick. They wouldn't like to be fixed to a single prepared OTP list, they want multi-factor and Plans B, C, and D. Also keep in mind that much traffic is needed alone for housekeeping and only a part can be information payload.
The most important argument, however, is that good pseudo-random is indistinguishable from a OTP (which is pseudo-random, just put in a list/file/whatever) but not fixing it offers quite some attractive advantages, some of which are extremely important, such as "even the officers aboard don't know the OTP".
I guess the decisive factor is the availability of plenty computing power in small packages.
That said, maybe you're right anyway. I was just thinking loud and considering some factors that are probably not unimportant.
I'm glad to see that Peter Gutmann, a well known expert, seems to think similar to myself re. "Sha1 is broken!!1!³"
Here's the meat:
Following that and explaining what the real meaning and danger is, he (like me) talks about collision related problems, showing it with a nice example of an obvious problem case.
link -> http://www.metzdowd.com/pipermail/cryptography/2017-February/031604.html
(As for the lesbian perspective I can't offer anything but I can recommend joepie91's source of wisdom, auroras blog. She collected nice colourful tables from the net, she calls "rainbow tables". How cunning!)
We went through the same thing when md5 was broken some years back. It resulted in a monstrous demo exploit (fortunately white hat): some researchers managed to forge a CA certificate. The md5 certificates are gone now, but it would take careful research to verify if there are none vulnerable to sha1 collision attacks. And no, it doesn't take a nation-state to round up a few hundred GPU's and run them for a number of months. Peter is right that lots of the first systems people think of aren't affected.
Bit cheeky. Finding a collision is fairly fundamental, and Google (in their wisdom) state
The expert you quote recommends the same.
So what we're saying here is that if I have a friend who has the technological and financial resources of Google, and I suspect we both have a document with the same information, but I don't want him to be able to verify it with SHA1, I should make sure we both don't store it in a PDF in same format that contains the same data Google used?
What they're more likely saying is, beyond the comprehension of the average person, SHA1 checksums can't be explicitly 100% trusted because there's a proven collision. Going forward, use something else and forget about it.