|
Antillie posted:Well Sourceforge is the official place to get Veracrypt and Veracrypt isn't abandoned so I don't think there is anything wrong with getting it from them. Sourceforge was never the official place to get GIMP. Also the results of the code audit of TrueCrypt prove that it and by extension its open source derivatives in fact can be trusted. Stop spreading FUD.
|
#
?
Nov 20, 2015 22:34
|
|
|
|
| # ? Jan 19, 2025 00:21 |
|
|
Thanks for the advice OSI bean dip. I was just giving VeraCrypt a try out and pretty impressed until you said TrueCrypt wasn't trustworthy :/ I liked the PIM function, which does a similar thing to what I mentioned earlier about using CPU intensive iterations to make it hard for an attacker to quickly decrypt. This is basically what I'm looking for, I think: an alternative to hashing that stresses the CPU and RAM.
|
|
#
?
Nov 20, 2015 22:35
|
|
|
DeaconBlues posted:What you've mentioned there, dougdrums and Antillie, were my concerns about just using a hash. Particularly about the thief knowing about hashing and trying various hash algo's during the brute-force attempt. wyoak fucked around with this message at 22:41 on Nov 20, 2015 |
|
#
?
Nov 20, 2015 22:38
|
|
|
OSI bean dip posted:
Could you maybe explain it to those of us who are interested? Or is this thread just for people who are already so smart they don't need to actually discuss anything because holy poo poo you guys are gooning it up so loving hard.
|
|
#
?
Nov 20, 2015 22:43
|
|
|
Antillie posted:Well Sourceforge is the official place to get Veracrypt and Veracrypt isn't abandoned so I don't think there is anything wrong with getting it from them. Sourceforge was never the official place to get GIMP. Also the results of the code audit of TrueCrypt prove that it and by extension its open source derivatives are solid and can in fact be trusted. Stop spreading FUD. I too have read the report and actually believe that the cryptography is likely sound. I have no reason to refute that as there were many talented people going over its code to see what flaws there were. Minus some minor ones that can be and have been corrected, overall it's fine. However, you were quick to cite that report and then fail to look at what is outside of the cryptography which is how it works within the OS. Here are two vulnerabilities released this past September: https://code.google.com/p/google-security-research/issues/detail?id=538 quote:The Windows driver used by projects derived from Truecrypt 7 (verified in Veracrypt and CipherShed) are vulnerable to a local elevation of privilege attack by abusing the drive letter symbolic link creation facilities to remap the main system drive. With the system drive remapped it’s trivial to get a new process running under the local system account. https://code.google.com/p/google-security-research/issues/detail?id=537 quote:The Windows driver used by projects derived from Truecrypt 7 (verified in Veracrypt and CipherShed) are vulnerable to a local elevation of privilege attack by checking process of impersonation token which allow a user to inspect and potentially manipulate other users mounted encrypted volumes on the same machine. These were not included in the original audit as they did not pertain to the cryptography. The original TrueCrypt developer(s) said that the software likely had some unfixable vulnerabilities and whether or not that can be confirmed, it can be confirmed that we have some code sitting within that is likely to rear its ugly head as more people descend on it. For this reason, I cannot put my faith in TrueCrypt (and its derivatives) not because of "FUD" but because we already have enough evidence to support that position. Oh. And here's another security tool that was taken over by SourceForge.
|
|
#
?
Nov 20, 2015 22:47
|
|
|
Wiggly Wayne DDS posted:Are you loving serious? Back up those claims. I was incorrect about VeraCrypt. It is in fact hosted at codeplex. However I did back up my claim about TrueCrypt with a link to a summary of the audit results. So yes. I am loving serious.
|
|
#
?
Nov 20, 2015 22:49
|
|
|
OSI bean dip posted:Good info about TrueCrypt. Interesting. Still those are things that can be fixed. Serious flaws are found in software all the time. I don't see how finding OS level flaws in TrueCrypt makes it harder to trust than Firefox or Chrome. Even Bash has had serious issues over the years.
|
|
#
?
Nov 20, 2015 22:53
|
|
|
Inspector_666 posted:Could you maybe explain it to those of us who are interested? Or is this thread just for people who are already so smart they don't need to actually discuss anything because holy poo poo you guys are gooning it up so loving hard. wyoak fucked around with this message at 22:59 on Nov 20, 2015 |
|
#
?
Nov 20, 2015 22:53
|
|
|
Antillie posted:I was incorrect about VeraCrypt. It is in fact hosted at codeplex. However I did back up my claim about TrueCrypt with a link to a summary of the audit results. quote:Also the results of the code audit of TrueCrypt prove that it and by extension its open source derivatives in fact can be trusted. Stop spreading FUD. Antillie posted:Interesting. Still those are things that can be fixed. Serious flaws are found in software all the time. I don't see how finding OS level flaws in TrueCrypt makes it harder to trust than Firefox or Chrome. Even Bash has had serious issues over the years.
|
|
#
?
Nov 20, 2015 22:55
|
|
|
Inspector_666 posted:Could you maybe explain it to those of us who are interested? Or is this thread just for people who are already so smart they don't need to actually discuss anything because holy poo poo you guys are gooning it up so loving hard. RSA like many other ciphers rely on large prime numbers. When we talk about large prime numbers within RSA, we're talking taking two that are very, very far apart. In this code example, the smallest prime number is 4507 and the largest is 9533. They're both not what RSA is looking for nor are they very far apart--when we talk "large prime", we're talking of a prime that would of more or less 150 digits (the larger the better). We know based on this PHP array that there are only 570 prime numbers to choose from, meaning that there would only be something like <1,000,000 possible keys (I am doing ballpark numbers here and it would be between 100,000 and 1,000,000 so take it as it is). It wouldn't take long to run through all possible keys to decipher what was encrypted regardless of what key sets you're using. I think that this article is probably worth a read: http://doctrina.org/How-RSA-Works-With-Examples.html Lain Iwakura fucked around with this message at 22:59 on Nov 20, 2015 |
|
#
?
Nov 20, 2015 22:56
|
|
|
Right but why is 9521, 9533 the last pair in that guy's code? (Is it something hilarious like him using a variable type that can't handle 5-digit numbers or something?) EDIT: Or did you just mean that having the range all be so close makes it so dumb as to be entirely pointless and not worth thinking about at all.
|
|
#
?
Nov 20, 2015 23:00
|
|
|
Inspector_666 posted:Right but why is 9521, 9533 the last pair in that guy's code?
|
|
#
?
Nov 20, 2015 23:01
|
|
|
Wiggly Wayne DDS posted:Well when the dev backs away from the project going "Don't touch this with a 10 foot pole" it changes the situation somewhat. The TrueCrypt devs simply said that they were done. They never said why. Maybe they just got tired of working on the project. Maybe there is some horrible as yet unfound bug. Some bugs have been found and fixed. This is no different than any other software project. There might be some terrible remote code execution bug in Chrome right now but that isn't going to stop me from using Chrome. I guess it just comes down to how paranoid you are. Antillie fucked around with this message at 23:05 on Nov 20, 2015 |
|
#
?
Nov 20, 2015 23:02
|
|
|
Anyway this is neither here nor there but it kind of boggles my mind that computers can figure out if a 150 digit number is probably prime within a matter of microseconds and also that the 'probably' apparently isn't important.
|
|
#
?
Nov 20, 2015 23:06
|
|
|
Inspector_666 posted:Right but why is 9521, 9533 the last pair in that guy's code? It's because the developer didn't know what they were doing and decided to choose from a static list of primes <10,000. The prevailing thought in some circles for why the NSA is able to break so much cryptography isn't because they're looking for backdoors in the algorithms but instead poor implementations of prime numbers. PHP isn't a language suited for doing such tasks anyway.
|
|
#
?
Nov 20, 2015 23:06
|
|
|
OSI bean dip posted:It's because the developer didn't know what they were doing and decided to choose from a static list of primes <10,000. The prevailing thought in some circles for why the NSA is able to break so much cryptography isn't because they're looking for backdoors in the algorithms but instead poor implementations of prime numbers. On the subject of the NSA breaking crypto; Take a look at this paper. Specifically section "4.2 Is NSA Breaking 1024-bit DH?". It looks like most 1024 bit DH implementations use only two or three common sets of prime numbers. And it is plausibly within the capability of the NSA to have performed number field sieve precomputations for at least a small number of 1024 bit DH groups. Since most DH implementations use the same sets of primes the NSA could easily break IPSec, SSH, or TLS sessions protected with such a common 1024 bit DH exchange. You guys probably already know about this but in the circles I tend to move in most people aren't aware of it. Antillie fucked around with this message at 23:16 on Nov 20, 2015 |
|
#
?
Nov 20, 2015 23:13
|
|
|
Antillie posted:On the subject of the NSA breaking crypto; Take a look at this paper. Specifically section "4.2 Is NSA Breaking 1024-bit DH?". It looks like most 1024 bit DH implementations use only two or three common sets of prime numbers. And it is plausibly within the capability of the NSA to have performed number field sieve precomputations for at least a small number of 1024 bit DH groups. Since most DH implementations use the same sets of primes the NSA could easily break IPSec or TLS sessions protected with such a common 1024 bit DH exchange. Yeah. It was linked to in the article I shared. wyoak posted:Anyway this is neither here nor there but it kind of boggles my mind that computers can figure out if a 150 digit number is probably prime within a matter of microseconds and also that the 'probably' apparently isn't important. It's not exactly that instantaneous.
|
|
#
?
Nov 20, 2015 23:28
|
|
|
OSI bean dip posted:Yeah. It was linked to in the article I shared. Now that I have had time to read it I see that. Very nice. This is actually the reason why I am pushing for clients to use ECDHE instead of DHE (in addition to traditional RSA) on their HTTPS web sites as the devices we use for TLS termination do not support DHE exchanges larger than 1024 bits. The fact that ECDHE is also much faster is just a nice bonus. In fact I generally recommend the following cipher suite order when asked: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA I know 3DES is getting pretty long in the tooth but some people still need to support TLS clients that can't do AES because Antillie fucked around with this message at 23:50 on Nov 20, 2015 |
|
#
?
Nov 20, 2015 23:44
|
|
|
Related to not rolling your own crypto, V8's Math.random() has some gnarly collision issues. Includes a graphical representation of noise generated by Safari's Math.random() vs. noise generated by V8's Math.random(). Patterns are immediately visible in the V8 one, while the Safari one is much more random.
|
|
#
?
Nov 21, 2015 02:02
|
|
|
Antillie posted:I thought this was a thread were we could discuss whether or not it should be best practice to disable TLS 1.0 on web servers that also support TLS_FALLBACK_SCSV. Or maybe what a good lifetime value would be for a HTTP Strict Transport Security header and the pros and cons of including the preload option in said header. But for some reason we are talking about a new form of advertising tracking that is supposedly only being used in India. infosec is a much larger and broader topic than you think it is. it entails not only application and network security, but privacy, cryptography, anonymity, and more. stick around and you might learn something. also: 3 keybase invites left, root[a]reverie.pw since i don't have plat anymore RISCy Business fucked around with this message at 03:15 on Nov 21, 2015 |
|
#
?
Nov 21, 2015 03:11
|
|
|
Kazinsal posted:Related to not rolling your own crypto, V8's Math.random() has some gnarly collision issues. Includes a graphical representation of noise generated by Safari's Math.random() vs. noise generated by V8's Math.random(). Patterns are immediately visible in the V8 one, while the Safari one is much more random. Firefox's is good too, but I bet it's slower by a few microseconds, so the V8 team will be nuh-uh.
|
|
#
?
Nov 21, 2015 04:58
|
|
|
Math.random() isn't supposed to be secure or good. That it's so obviously your basic pseudo-random number generator is probably good in the long run.
|
|
#
?
Nov 21, 2015 06:07
|
|
|
DeaconBlues posted:What you've mentioned there, dougdrums and Antillie, were my concerns about just using a hash. Particularly about the thief knowing about hashing and trying various hash algo's during the brute-force attempt. who the gently caress do you think you are that a real concern is someone breaking into your house, stealing poo poo, and then focusing on breaking your encrypted files get real
|
|
#
?
Nov 21, 2015 16:17
|
|
|
Kazinsal posted:Related to not rolling your own crypto, V8's Math.random() has some gnarly collision issues. Includes a graphical representation of noise generated by Safari's Math.random() vs. noise generated by V8's Math.random(). Patterns are immediately visible in the V8 one, while the Safari one is much more random. i'm the guy running a betting site relying on random numbers who's too stupid to understand the difference between a random number and a unique identifier. this is an enormous article to explain his tentative grasp on random numbers and never once touches on why isn't he just using UUIDs of some form. quote:ENGINEERING THE DISRUPTION OF
|
|
#
?
Nov 21, 2015 16:24
|
|
|
I didn't actually read what his situation was, I just assumed it was the gambling equivalent of bitcoin and was curious as to how he hosed everything up.
|
|
#
?
Nov 21, 2015 20:38
|
|
|
OSI bean dip posted:Any basic understanding of prime numbers would be enough to not let you wonder about why these are the largest pairs. I am not going to explain what is wrong in this code because if you're asking this then you shouldn't dare think about writing such. How can nerds be so smug.
|
|
#
?
Nov 22, 2015 06:59
|
|
|
Wrong thread, I'm sure. But this has been bothering me for at least 15 years. Why were dictionary/brute force attacks ever possible? What is the use in letting a client attempt 1,000,000 passwords? Why would it even let you try five?
|
|
#
?
Nov 23, 2015 22:46
|
|
|
Simple, that requires state and adds complexity to the code.
|
|
#
?
Nov 23, 2015 22:48
|
|
|
via posted:Wrong thread, I'm sure. But this has been bothering me for at least 15 years. Why were dictionary/brute force attacks ever possible? What is the use in letting a client attempt 1,000,000 passwords? Why would it even let you try five? If the software doesn't have any detection and just keeps allowing password attempts, then that is the reason why. It used to be common that someone would just hammer some basic accounts (usually service-related) on a UNIX server, log in, grab the passwd file, log off, and then later come in with an account that has more permissions as they've run a dictionary against the passwords. Clifford Stoll's "The Cuckoo's Egg" is worth a read if you're curious how things used to be.
|
|
#
?
Nov 23, 2015 23:03
|
|
|
via posted:Wrong thread, I'm sure. But this has been bothering me for at least 15 years. Why were dictionary/brute force attacks ever possible? What is the use in letting a client attempt 1,000,000 passwords? Why would it even let you try five? People still brute force ssh servers, I guess people still use guessable ones.
|
|
#
?
Nov 24, 2015 02:45
|
|
|
OSI bean dip posted:Any basic understanding of prime numbers would be enough to not let you wonder about why these are the largest pairs. I am not going to explain what is wrong in this code because if you're asking this then you shouldn't dare think about writing such. As for Truecrypt forks, if we're going to apply that level of paranoia consistently, what can we use? We can't do public code reviews on commercial, closed source FDE tools like Bitlocker and PGP. We can't rule out government intereference in Truecrypt, nor can we rule it out with commercial offerings (MS removed the Elephant diffuser from Bitlocker  ), or undisclosed vulnerabilities that malicous actors are also exploiting etc etc
Mr Chips fucked around with this message at 12:51 on Nov 24, 2015 |
|
#
?
Nov 24, 2015 10:35
|
|
|
via posted:Wrong thread, I'm sure. But this has been bothering me for at least 15 years. Why were dictionary/brute force attacks ever possible? What is the use in letting a client attempt 1,000,000 passwords? Why would it even let you try five? Typically, people just didn't think about preventing it, or simply didn't bother. Preventing brute-forces requires at least a little extra effort above and beyond just implementing the authentication. It's not that there's any particular use in letting a client attempt 1,000,000 passwords, it's that it takes extra work to put something in to prevent them from doing so, and not everyone does that extra work.
|
|
#
?
Nov 24, 2015 14:22
|
|
|
Main Paineframe posted:Typically, people just didn't think about preventing it, or simply didn't bother. Preventing brute-forces requires at least a little extra effort above and beyond just implementing the authentication. It's not that there's any particular use in letting a client attempt 1,000,000 passwords, it's that it takes extra work to put something in to prevent them from doing so, and not everyone does that extra work. It seems like when people get to brute force passwords these days it's because they were able to get the hashes via a compromised account and download the table, rather than somebody hammering a webserver or something.
|
|
#
?
Nov 24, 2015 14:48
|
|
|
via posted:Wrong thread, I'm sure. But this has been bothering me for at least 15 years. Why were dictionary/brute force attacks ever possible? What is the use in letting a client attempt 1,000,000 passwords? Why would it even let you try five? I see SSH, RDP, and FTP servers get hit with brute force attacks all the time. Mostly because most people, including many sys admins, are bad a picking good passwords and/or don't bother to turn on account lockout policies. Systems with port 22, 21, or 3389 open to the world and poor passwords are low hanging fruit. And they are common enough for it to be worth letting a script look for them. Brute force attacks are very easy to prevent. But the "it won't happen to me" mentality is quite common among the general sys admin population so there are a lot of systems out there that don't have any of the basic brute force mitigation methods configured. The same goes for web applications with badly written SQL queries and people installing Wordpress (and random Wordpress plugins) and then never updating it.
|
|
#
?
Nov 24, 2015 15:53
|
|
|
Mr Chips posted:Can you explain the mathematics for the first bit for everyone else who's interested in understanding why? In terms of why a large prime number is needed or how all of RSA works here? I am not a cryptographer so explaining RSA properly is not going to go well here--I do understand it and can give an explanation here but it's like me trying to explain my house's electrical system as if I have a plumber's perspective. I do recommend reading this page to see how it all works. If we're talking about large primes here, it's quite simple: computers can't quickly factorize numbers. The problem that classical computers face right now is that calculating the factors of a number is quite intensive and that as numbers get larger the ability to determine all factors takes significantly longer (see this Wikipedia article for further elaboration). This is why finding prime numbers has over time taken longer, but if you want to see the problem first hand without a computer, see how long you take to count completely in primes and you'll start to understand that you're running into a similar problem. [edit] Just read this post: http://forums.somethingawful.com/showthread.php?threadid=3750534&pagenumber=2#post453102981 quote:As for Truecrypt forks, if we're going to apply that level of paranoia consistently, what can we use? We can't do public code reviews on commercial, closed source FDE tools like Bitlocker and PGP. We can't rule out government intereference in Truecrypt, nor can we rule it out with commercial offerings (MS removed the Elephant diffuser from Bitlocker If your concern is that you cannot do commercial code review of your closed source FDE (such as Bitlocker), why are you using Windows overall? Truthfully I am more worried about how the OS and FDE interact rather than the cryptography. If you're at this level of paranoia, use Linux with dm-crypt. Lain Iwakura fucked around with this message at 17:06 on Nov 24, 2015 |
|
#
?
Nov 24, 2015 16:00
|
|
|
Mr Chips posted:As for Truecrypt forks, if we're going to apply that level of paranoia consistently, what can we use? We can't do public code reviews on commercial, closed source FDE tools like Bitlocker and PGP. We can't rule out government intereference in Truecrypt, nor can we rule it out with commercial offerings (MS removed the Elephant diffuser from Bitlocker For the truly paranoid the only real option is to roll your own solution. But I think we all know how well that tends to work out if you aren't an expert in cryptography and number theory. However the second major audit of TrueCrypt, which includes more than just the cryptography functions audited previously in April, was recently completed. Ars Technica has a nice summary. The important part is that you have to realize what TrueCrypt and its derivatives are for. Securing data while it is at reset. That is, when the encrypted volume is not mounted. Wiggly Wayne DDS and OSI bean dip will probably disagree but I feel that VeraCrypt is a reasonable alternative assuming you aren't in a position to spend millions of dollars to develop your own solution. And honestly I feel that titaniumone makes a very good point. If someone breaks into your car or house and steals your laptop they aren't going to try and break any crypto, even terrible crypto, to try and find information about you. They are going to hawk it at the nearest pawn shop who will in turn throw a fresh Windows install on it and put it up for sale. Now I suppose if someone broke into my car in the office parking lot and stole my laptop there is a small chance they might be someone looking for information on our company or our customers (such as private keys for TLS certificates, passwords for internal systems, ect...) and they may look around on my laptop for such information. I think that VeraCrypt would be perfectly capable of thwarting any such attempt. It might have some hidden flaw that would prevent it from keeping the NSA from extracting information from my laptop. But groups with the resources of a nation state aren't my main adversary. That said, I think that TrueCrypt/VeraCrypt, if properly used, would still give the NSA a serious headache. Antillie fucked around with this message at 16:39 on Nov 24, 2015 |
|
#
?
Nov 24, 2015 16:12
|
|
|
Mr Chips posted:Can you explain the mathematics for the first bit for everyone else who's interested in understanding why? As for why it's a problem, the security of RSA relies on it being "slow" and "difficult" for computers to factor composite numbers into their prime factors. But while computers are "slow" at doing that, they're still able to do it pretty well for numbers of sizes that we can comprehend. Eight-digit RSA keys are effectively trivial to factor. Back in the 90s, RSA-768 keys with 232 digits (116 digit prime factors) were considered secure. But an RSA-768 key was factored in 2009 and at some point (if not already) they will be factorable by folks with sufficient funding (governments, etc.). RSA-1024 (~300 digit keys) is still considered secure, but uncomfortable, with RSA-2048 (~600 digit keys) being recommended (to the extent folks still recommend RSA). Wolfram MathWorld has a page on RSA Numbers, discussing different key sizes and when the RSA Factoring Challenge keys were broken.
|
|
#
?
Nov 24, 2015 16:22
|
|
|
ExcessBLarg! posted:Prime numbers exist above 10,000, so the claim that 9533 is the largest prime is pretty laughable. As for why, I'm not a Mathematician so I won't explain it in a rigorous way, but intuitively there's nothing particularly special about "10,000" to think that there aren't prime numbers larger than that. This is far better than what I had posted. 
|
|
#
?
Nov 24, 2015 16:24
|
|
|
So its not just one, but three rouge root certs that Dell has been installing on every laptop that it has sold for the past while. What really floors me is that they also included the private key so anyone can sign TLS certificates or executable code with this root cert and Dell PCs will trust the result automatically. Hooray for OEM stupidity.
|
|
#
?
Nov 24, 2015 16:51
|
|
|
|
| # ? Jan 19, 2025 00:21 |
|
|
They're doing the same thing as Lenovo and saying it's not a security problem, too. Burn it. Burn it all.
|
|
#
?
Nov 24, 2015 18:00
|
|