Reputation
26,424
Next tag badge:
100/100 score
17/20 answers
Badges
5 56 120
Impact
~1.9m people reached

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
awarded  Nice Answer
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?"
Mar
10
comment Why would an encrypted file be ~35% larger than an unencrypted one?
Owncloud is an enterprise file-sharing application (which will store arbitrary types of documents, which may be highly redundant or not). Their documentation says that "Encrypting files increases their size by roughly 35%, so you must take this into account when you are provisioning storage and setting storage quotas. User quotas are based on the unencrypted file size, and not the encrypted file size." So this isn't talking about their specific files, but user files being 35% larger.
Mar
10
revised Why would an encrypted file be ~35% larger than an unencrypted one?
added 101 characters in body
Mar
10
revised Why would an encrypted file be ~35% larger than an unencrypted one?
added 569 characters in body
Mar
10
comment Why would an encrypted file be ~35% larger than an unencrypted one?
This is true, but you can get around that by just encrypting the compressed collection of files. The fact that it increase by roughly 35% indicates its base-64 encoding with linebreaks to avoid sending passing around arbitrary binary files of encrypted data. If it had to do with compression, there's no reason to suspect it would always be 35%. (Instead of sometimes being 90% difference as in your example).
Mar
10
comment Why would an encrypted file be ~35% larger than an unencrypted one?
Possible duplicate of Why does openssl enc -aes-256-cbc -a -salt increase the file size?
Mar
10
answered Why would an encrypted file be ~35% larger than an unencrypted one?
Mar
9
revised Are hashing functions designed to be injective where the domain is limited to the codomain?
added 498 characters in body
Mar
9
revised Are hashing functions designed to be injective where the domain is limited to the codomain?
added 546 characters in body
Mar
8
revised Are hashing functions designed to be injective where the domain is limited to the codomain?
added 546 characters in body
Mar
8
revised Are hashing functions designed to be injective where the domain is limited to the codomain?
added 546 characters in body
Mar
8
revised Are hashing functions designed to be injective where the domain is limited to the codomain?
added 546 characters in body
Mar
8
answered Are hashing functions designed to be injective where the domain is limited to the codomain?
Mar
8
comment Are hashing functions designed to be injective where the domain is limited to the codomain?
The maximum length is mostly because hashing messages above that length with this type of hash is impracticable without some hash function that allows for parallelization. (Things of 2^64 bits is roughly the order of magnitude of facebook or google's total storage in all their datacenters.) The reason is one step of the hash function requires using the length of the message (so if the storing the length requires more than 64/128 bits it could become undefined how to extend; though you could simply take the low-order bits of the length to extend the algorithms to arbitrary length).
Mar
8
comment Are hashing functions designed to be injective where the domain is limited to the codomain?
Minor pedantic point, most cryptographic hash functions are defined with a maximum input length. E.g., md5, sha-1, sha-256 should not accept an input message with more than 2^64 - 1 bits ~ 2.3 million terabytes (so in practice arbitrary length as you said as practical hash inputs are smaller). (sha512 allows 2^128 - 1 bits as input; and sha-3 doesn't have a max input length). See: en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions (And your argument stands if you allow 257 = 2^8 + 1 bits as input as the pigeonhole principle can show there is at least one collision).
Mar
6
comment Will quantum computers render AES obsolete?
Well real quantum computers that can maintain the type of quantum coherence to factor large integers or do discrete logs over finite fields (incl elliptic curves) aren't available to anyone (unless secret unpublished quantum computing research has made huge advances -- talking decades -- ahead of published research).
Mar
6
revised Will quantum computers render AES obsolete?
added 464 characters in body
Feb
27
awarded  Good Answer