dr jimbob
Reputation
26,444
101/100 score
 8h comment Should RSA primes p and q should differ in length by “a few digits”? @gtrwoot - My guess is it was clear to Rivest et al, that if p and q were too close together there are ways to quickly factor N and undermine the security. They made the recommendation to ensure p and q differed in length by a few digits, so if p is the larger prime and is say 3 (decimal) digits longer you have `p - q ≈ p - p/1000 ≈ .999 p ≈ p ≈ sqrt(N) >> N^(1/4)`. Hence Fermat factorization based on p being near q won't work when p and q differ in length. That said just randomly picking two n/2 bit primes will with high probability result in them being O(sqrt(N)) apart. 8h comment Should RSA primes p and q should differ in length by “a few digits”? 8h comment Should RSA primes p and q should differ in length by “a few digits”? Who said this? It's customary for say 2048-bit RSA to choose two 1024-bit primes that have the same length. That said there are efficient attacks on RSA if p-q is too small. See: en.wikipedia.org/wiki/Fermat%27s_factorization_method or trial division starting from the nearest odd integer to sqrt(N). (This technique is very efficient when |p-q| < O( N^(1/4) ) Apr 30 comment Why is 128bit AES considered very strong but 160bit SHA depreciated? @acidzombie24 - Yes, the security of accepting a particular hash function as part of a validly signing a certificate fundamentally relies on the infeasibility of collision attacks. There's no such thing as "nonsecure bits", it's just a 160 bit hash function takes roughly 2^80 effort to generate a collision to break. This is roughly comparable to the effort to brute-force a block cipher with an 80-bit key. Apr 30 comment Why is 128bit AES considered very strong but 160bit SHA depreciated? @LieRyan - Totally agree. If you look at the edit history the whole idea was introduced by an edit that someone else approved. (Originally I wrote "If say p1 was a certificate for a domain you own and can verify ownership to a CA, you can get a CA to sign it" but was changed to "If say p1 happens to identify any free domain (like phpsdfpspfopo.tv) that you can buy any minute, then you can verify ownership of p1 to a CA and you can get a CA's signature of p1." Granted, changing the domain/subdomain seems a pretty simple way to explain changing `p1` without going to fine details. Apr 28 comment What is the problem with multiple encryption and how do you know if you have decrypted a cipher? If two 128-bit keys (`K1`, `K2`) are used to encrypt a message like `c=E(K1, E(K2, m))` then to brute force `c` to recover `m`, you would need to check all the possible combinations of the two keys with a space of (2^128) * (2^128) = 2^(256) possibilities. This is equivalent to brute-forcing a 256-bit key. (Note you said (2^128)^128 which is equal to 2^(128*128) = 2^16384 -- this mistake was originally brought up in another answer by a user named Joe.) Apr 26 comment Why aren't ransomware deployers arrested? @Cestarian - The described doesn't seem foolproof solution against Ransomware. If you accidentally execute malware on any of your machines connected to the NAS and your machine has write privileges to the NAS, then you can be screwed. A good backup policy does (e.g., a privileged account does daily version controlled backups that no one else can write to). Apr 20 comment Does MAC address filtering provide security? I don't see how MAC address filtering reduces the attack surface. OP is clearly asking about wifi (see the wifi tag + wlan0 in example) when the machines being filtered out are directly talking to the router with MAC address filtering. The biggest problem with MAC address filtering in this scenario, is it's easy to find the allowed MAC addresses (by just listening as they are in the unencrypted header of each packet) and it's also easy to change your MAC address. IP address filtering is different, as its not easy for non-network admins to change their IP to allowed ones (at least with TCP). Apr 19 comment Security risks of using MongoDB ID vs a counter in URL? Where in the OPs question did they specify if they are using HTTP? I see them leaving the protocol off of the URL. Apr 16 comment I anonymously submitted a security vulnerability, but it was not resolved. What now? Laws are vague and if you can demonstrate you've accessed information. E.g., one US federal law (18 U.S. Code § 1030) says if you obtain information from a protected computert (US gov't computer; used by financial institution; used in interstate/foreign commerce) that exceeds your authorized access its a crime. ( law.cornell.edu/uscode/text/18/1030 ). Mar 26 comment Is MAC address filtering effective on a wifi router? @Cerveser - Your MAC address is not secret information -- it's necessary public info for wifi cards to identify packets intended for them. Every communication to any wifi router broadcasts the MAC to everyone with a wifi card in wifi radio range from you and this only needs to be eavesdropped once for just one device (e.g., wireless printer, smart TV, tablet, smart watch, internet camera, laptop, chromecast, smartphone). If by default wifi is off, then you are fine with or without MAC filtering -- there's no wifi to access as you turned it wifi off at the router. Mar 17 comment Could I use a TimeStamp also as IV? For GCM (Galois Counter Mode) mode it's fine, for CBC a predictable IV (with substantial overlap with previous IVs) is insecure. Mar 14 comment Why would an encrypted file be ~35% larger than an unencrypted one? @warren This question is "Why would an encrypted file be 35% larger than an unencrypted one?" and the other is "why does increase the file size ?" It doesn't matter if its different products using encryption (though owncloud calls openssl functions through PHP's `openssl_encrypt`), both boil down to "Why does this encryption increase file size by about 33.3-35.4%?" Because of base64 encoding the ciphertext. Lots of apps use base64 encoding after encryption, it would be silly to keep repeating the same question in every separate case. Mar 14 comment How can I test a domain that I don't own for unencrypted communication vulnerabilities? @Enigma - The login credentials at that site are POSTed in plaintext over HTTP. Mar 12 comment Why would an encrypted file be ~35% larger than an unencrypted one? @IMSoP - While 0 and false have the same value, they have different semantic meanings. I understand options is now a bit mask and the LSB of options being 0 means base64 encode. I just think the design and documentation is poor. The documentation should state default behavior (b64 encode and PKCS#7 padding). You should never have to consult the language's source code to understand how the parameters of a built-in functions works. Maybe add a new constant `OPENSSL_BASE64_PKCS7` (value 0) and document the difference between zero padding and PKCS7 padding. Also rename password to key. Mar 11 comment Why would an encrypted file be ~35% larger than an unencrypted one? @IMSoP When openssl is called from command line to encrypt with base64 encoding (-a flag), it inserts `\n` every 64 chars (see: `openssl enc -aes-128-cbc -a -in file2encrypt`). I expected a function named `openssl_encrypt` with flags set to base64 to act similarly. I don't have a problem maintaining backward compatibility, but the lack of documentation explaining the options=false means base64 encoded is a problem. The only documentation is `options can be one of OPENSSL_RAW_DATA, OPENSSL_ZERO_PADDING` which gives no indication of what happens when options=false unlike raw_output=false. Mar 11 comment Why would an encrypted file be ~35% larger than an unencrypted one? @MobyDisk - Maybe using binary files caused issues (e.g., used across firewalls that block random binary blobs)? Or just initially used as base64 is the default for PHP's openssl_encrypt/openssl_decrypt? There's a ticket to migrate to binary encryption from Sep 2014, though it's still open. Going to binary just requires switching `false` to `true` at L208 and L574 of crypt.php though backward compatibility makes it harder. Mar 11 comment Why would an encrypted file be ~35% larger than an unencrypted one? Playing around with `openssl_encrypt` in a PHP fiddle, it seems to base64 encode the data (and not insert linebreaks every 64 characters), but as php.net calls this an undocumented function, it wouldn't surprise me if this changed between PHP versions (if it's not 100% clear, I am not a PHP fan). Without the linebreaks, I'd expect encrypted files to be consistently 33.33% larger up to 1-3 blocks for padding, an IV, and a MAC. So saying 35% may just be rounding up for safety safe (and I shouldn't have assumed line breaks). Mar 11 comment Why would an encrypted file be ~35% larger than an unencrypted one? @DeerHunter - I've never used OwnCloud. Briefly looking at their source code it seems they use the poorly documented PHP function `openssl_encrypt` to do the bulk of their encryption work. The fourth parameter `\$options` is hard-coded to false in owncloud's source code. The parameter `\$options` used to be called `\$raw_output` and when it's set to false it base64 encodes the ciphertext output. Mar 10 comment Why would an encrypted file be ~35% larger than an unencrypted one? Well this is sec.se not crypto and I read and answered the question in the title "Why would an encrypted file be ~35% larger than an unencrypted one?". Though I guess you fairly answered the question in the body "From my understanding of encryption, file sizes should be more-or-less identical (perhaps some padded 0 bits at the end to make it a multiple of the key size). Is that incorrect?"