|
Double Punctuation posted:Serious question: Why are the lovely NIST curves still above 25519? Most of the RFCs for it are either published or in the queue. The NIST curves are vetted and not exactly "lovely". 25519 has a strength roughly equivalent to P256 and when translating from asymm their comparable symm cipher would be AES128. Since the world is pretty well standardizing on AES256 since the overhead is proving a non-issue then you need equivalent strength key exchange.
|
#
?
Jul 11, 2017 17:52
|
|
|
|
| # ? May 30, 2024 13:10 |
|
|
BangersInMyKnickers posted:The NIST curves are vetted and not exactly "lovely". 25519 has a strength roughly equivalent to P256 and when translating from asymm their comparable symm cipher would be AES128. Since the world is pretty well standardizing on AES256 since the overhead is proving a non-issue then you need equivalent strength key exchange. The problem with the NIST curves is there are no public design documents. The NSA already backdoored one algorithm, so it's possible they put a backdoor in the curves as well. I understand the concerns about strength. I guess we need to wait for X448 support for a better option.
|
|
#
?
Jul 11, 2017 22:31
|
|
|
After deleting 22TB of old rear end logs ArcSight is finally crunching logs again. Nothing like not having proper storage threshold alerts setup on your systems. So glad I wasted an hour or three troubleshooting smart connector issues.
|
|
#
?
Jul 11, 2017 22:37
|
|
|
Diametunim posted:After deleting 22TB of old rear end logs ArcSight is finally crunching logs again. Nothing like not having proper storage threshold alerts setup on your systems. So glad I wasted an hour or three troubleshooting smart connector issues. Your first mistake was spending $texas on ArcSight.
|
|
#
?
Jul 12, 2017 01:20
|
|
|
I prefer ArcSight to every SIEM out there, but what I prefer more is paying people so I don't have to think about SIEMs at all.
|
|
#
?
Jul 12, 2017 13:00
|
|
|
Double Punctuation posted:The problem with the NIST curves is there are no public design documents. The NSA already backdoored one algorithm, so it's possible they put a backdoor in the curves as well. I don't have a very good answer since its a balance of multiple concerns and will depend on your use case. The ordering I am using is for general use computing and business operations where protecting ourselves against a conventional malicious actor vs the NSA. The design quirks of the NIST curves are at least somewhat justified from an efficiency standpoint, and keep in mind that these were designed in the late 90's and formalized in 99 I believe. CPU overhead from ECC exchanges was a much bigger deal back then, you only had one or two cores available in most standard servers, maybe 4 if you were willing to dump $15k in to the box. Windows was NIST curves exclusively up until 2016/Win10, Microsoft is slow to introduce new ones. If you are someone who is concerned with state-level monitoring and tampering then by all means run 25519 as your preferred. Brainpool curves are of a similar age with similar compromises to NIST and not as well supported so you can run those in front of your NIST curves if you want, but as you said what we really need is more vetting on this new generation of curves and acceptance by Microsoft. I am also investigating the viability of a full drop of DH/DHE ciphers. Way too many servers do weak (512/1024bit) DH exchange and having it enabled in Schannel means that's available for things like IE to use. While ephemeral sessions are great, I would prefer good ole RSA if it means not talking to a bad DH Implimentation. ECDH should have completely supplanted it at this point but that is more of a gut reckon, collecting data currently.
|
|
#
?
Jul 12, 2017 14:22
|
|
|
The new Apple controversy is them removing ad blockers that use VPNs. Because allowing an app to install a root certificate is totally secure guys.
|
|
#
?
Jul 15, 2017 16:22
|
|
|
Reminder, OpenSSL is poo poo and should be nuked from orbit/shot into the sun. From VC++ 5.0 hacks to BIG ENDIAN AMD64 support, it's really really REALLY bad. Worse yet? They ignored Tavis. https://github.com/libressl-portabl...7d1934c12510fee You can't ignore Tavis! You will regret this! Don't use OpenSSL if you can help it. Holy poo poo.
|
|
#
?
Jul 16, 2017 18:58
|
|
|
ratbert90 posted:Reminder, OpenSSL is poo poo and should be nuked from orbit/shot into the sun. So bad, the link is broken, too. 
|
|
#
?
Jul 16, 2017 19:03
|
|
|
Absurd Alhazred posted:So bad, the link is broken, too.
|
|
#
?
Jul 16, 2017 19:15
|
|
|
i mean if they haven't even renamed it openTLS then yeah they're probably scrubs
|
|
#
?
Jul 16, 2017 19:18
|
|
|
Why does it take VeraCrypt a solid 30 secs to mount a 15 GB volume (volume size seems irrelevant anyway)? That's on a latest generation laptop with an Intel i7 CPU. Somebody on this thread explained they do a bunch more rounds than TrueCrypt but it's ridiculously longer. Is there a secret setting I'm missing?
|
|
#
?
Jul 17, 2017 20:39
|
|
|
Furism posted:Why does it take VeraCrypt a solid 30 secs to mount a 15 GB volume (volume size seems irrelevant anyway)? That's on a latest generation laptop with an Intel i7 CPU. Somebody on this thread explained they do a bunch more rounds than TrueCrypt but it's ridiculously longer. Is there a secret setting I'm missing? It prevents brute forcing, iirc.
|
|
#
?
Jul 17, 2017 21:16
|
|
|
There is a "use PIM" option if you want to customize the number of iterations it does (and thereby make yourself less resistant to brute-force attacks).
|
|
#
?
Jul 17, 2017 21:37
|
|
|
Humble Bundle up with some decent books if anyone's interested. Don't think I saw this posted here yet. https://www.humblebundle.com/books/cybersecurity-wiley
|
|
#
?
Jul 18, 2017 05:05
|
|
|
Furism posted:Why does it take VeraCrypt a solid 30 secs to mount a 15 GB volume (volume size seems irrelevant anyway)? That's on a latest generation laptop with an Intel i7 CPU. Somebody on this thread explained they do a bunch more rounds than TrueCrypt but it's ridiculously longer. Is there a secret setting I'm missing? It makes brute-forcing a few orders of magnitude harder. https://veracrypt.codeplex.com/wikipage?title=Header%20Key%20Derivation Fake edit: that link also explains the details of how this option works: EssOEss posted:There is a "use PIM" option if you want to customize the number of iterations it does (and thereby make yourself less resistant to brute-force attacks).
|
|
#
?
Jul 18, 2017 05:20
|
|
|
PBS posted:Humble Bundle up with some decent books if anyone's interested. Don't think I saw this posted here yet. Snagged this. I didn't own a copy of Applied Cryptography so it was kinda a no-brainer
|
|
#
?
Jul 18, 2017 06:34
|
|
|
RFC2324 posted:It prevents brute forcing, iirc. I use 200 bits passwords, am I right there's no brute forcing that anyway?
|
|
#
?
Jul 18, 2017 07:14
|
|
|
Furism posted:I use 200 bits passwords, am I right there's no brute forcing that anyway? Are they all zeroes?
|
|
#
?
Jul 18, 2017 12:36
|
|
|
Furism posted:I use 200 bits passwords, am I right there's no brute forcing that anyway? anything can be brute forced with enough time and no lockout. This wait makes sure that the time is long enough to be impractical. (It forces 30 seconds between tries)
|
|
#
?
Jul 18, 2017 16:18
|
|
|
If you have privs to attach a debugger, can you memory patch that down to zero?
|
|
#
?
Jul 18, 2017 16:22
|
|
|
RFC2324 posted:anything can be brute forced with enough time and no lockout. This wait makes sure that the time is long enough to be impractical. (It forces 30 seconds between tries) I get what you mean but 30 seconds seems unnecessary long. Even one second between each attempt would make an attack against a 200 bits password impractical in any time-frame where the data is relevant. That was my thinking until now.
|
|
#
?
Jul 18, 2017 16:32
|
|
|
Subjunctive posted:If you have privs to attach a debugger, can you memory patch that down to zero? If you have a way to iterate through five hundred thousand rounds of SHA-512 in zero seconds, then sure, go ahead.
|
|
#
?
Jul 18, 2017 16:35
|
|
|
Furism posted:I get what you mean but 30 seconds seems unnecessary long. Even one second between each attempt would make an attack against a 200 bits password impractical in any time-frame where the data is relevant. That was my thinking until now. Security people are over paranoid by design. And i can think of a way to significantly reduce the time needed in about 10 seconds off the top of my head (clone the drive to a bunch of blanks, brute force in parallel).
|
|
#
?
Jul 18, 2017 16:50
|
|
|
mewse posted:Snagged this. I didn't own a copy of Applied Cryptography so it was kinda a no-brainer You may've read it already, but Cryptography Engineering has superseded it and is also in the bundle.
|
|
#
?
Jul 18, 2017 16:54
|
|
|
RFC2324 posted:anything can be brute forced with enough time and no lockout. This wait makes sure that the time is long enough to be impractical. (It forces 30 seconds between tries) With enough time, and enough dyson spheres. The entire output of the sun can't even count to 2^200 in a thousand years. The difference between a 1 nanosecond lockout and a 30 second lockout is only 2^35. Reduce a 200 bit password to 165 bits and it's still bulletproof. Something else will give out first.
|
|
#
?
Jul 18, 2017 17:00
|
|
|
Dylan16807 posted:With enough time, and enough dyson spheres. The entire output of the sun can't even count to 2^200 in a thousand years. Congratulations you just ensured the password will be found on the 3rd try.
|
|
#
?
Jul 18, 2017 17:15
|
|
|
Avenging_Mikon posted:Congratulations you just ensured the password will be found on the 3rd try. And it'll turn out the password was the name of the person's dog.
|
|
#
?
Jul 18, 2017 17:43
|
|
|
Powered Descent posted:And it'll turn out the password was the name of the person's dog. And the name of that dog was.. password1
|
|
#
?
Jul 18, 2017 17:46
|
|
|
Powered Descent posted:And it'll turn out the password was the name of the person's dog. Should use KeePass to generate your dogs' names.
|
|
#
?
Jul 18, 2017 17:47
|
|
|
Powered Descent posted:If you have a way to iterate through five hundred thousand rounds of SHA-512 in zero seconds, then sure, go ahead. Oh, I thought it was exactly 30 seconds, which would mean a timer to be processor independent. That makes more sense.
|
|
#
?
Jul 18, 2017 17:47
|
|
|
A dev broke one of our internal tools, and everyone's password field contents, stored in plaintext, was suddenly displaying as the username attribute 
|
|
#
?
Jul 18, 2017 17:48
|
|
|
CLAM DOWN posted:A dev broke one of our internal tools, and everyone's password field contents, stored in plaintext, was suddenly displaying as the username attribute 
|
|
#
?
Jul 18, 2017 17:50
|
|
|
ratbert90 posted:Reminder, OpenSSL is poo poo and should be nuked from orbit/shot into the sun.
|
|
#
?
Jul 18, 2017 18:13
|
|
|
Cugel the Clever posted:Anyone have input on the best alternative? I'm just a poor web deb with limited knowledge of the things my various tools have going on behind the scenes.
|
|
#
?
Jul 18, 2017 18:36
|
|
|
Cugel the Clever posted:Anyone have input on the best alternative? I'm just a poor web deb with limited knowledge of the things my various tools have going on behind the scenes. libressl.
|
|
#
?
Jul 18, 2017 18:36
|
|
|
LibreSSL, and throw libtls on top of it so you don't have to write a massive framework for dealing with all the legacy OpenSSL API poo poo. e: My bad, libtls is a core part of LibreSSL. No extra libraries needed, just grab the LibreSSL suite and call it a day. Kazinsal fucked around with this message at 18:47 on Jul 18, 2017 |
|
#
?
Jul 18, 2017 18:41
|
|
|
Cugel the Clever posted:Anyone have input on the best alternative? I'm just a poor web deb with limited knowledge of the things my various tools have going on behind the scenes. Schannel on IIS.
|
|
#
?
Jul 18, 2017 19:13
|
|
|
I'm trying to do a CTF with a PCAP decoding challenge, and I'm stuck on the first step. Is there a place (forum or whatever) where I could ask some people who are great at solving CTFs? If you want to give it a shot, then I have DNS trafic between a client and a server. There is a DNS tunnel using the DNS TXT field, and I need to parse the data to get the first flag. If I decode the TXT field from hex it looks something like this: code:
|
|
#
?
Jul 18, 2017 19:31
|
|
|
|
| # ? May 30, 2024 13:10 |
|
|
in dns tunneling you'll usually get data via base32 encoding into subdomain requests. it'll look like random characters. does that exist here? would help a lot. otherwise I'd try the obvious that I can't via a phone. use "042" as an xor otp, or "jml", or the last byte in one of those requests. you might also consider the dot in responses as immutable, as a separator between a subdomain and a domain. if you know the domain, you could probably derive the xor key using the bytes after the dot. really the most unlikely solution. Daman fucked around with this message at 07:09 on Jul 20, 2017 |
|
#
?
Jul 20, 2017 07:05
|
|