> At any rate, the mathematics table of predicting the output of each input,
> without compression or signing, would be very handy. Curious how you got
> the numbers from before.
AES is a 128-bit block cipher: it is incapable of producing outputs except in
multiples of 128 bits (16 bytes). ECB m
> The reason for asking (which actually isn't realted to GnuPG) was I wanted
> to know the amount of data transferred over the wire with SCP.
Then this isn't a question related to encipherment: this is a protocol
question. Once you start looking at the protocol layer, other things have
enormous
On 07/11/2011 04:59 PM, David Shaw wrote:
> On Jul 11, 2011, at 3:26 PM, Aaron Toponce wrote:
>
>> When encrypting a plaintext source, is there a way to predict the size of
>> the ciphertext output? I'm sure this depends on the cipher used, as well if
>> compression or hashing algos are used.
>
>
On Jul 11, 2011, at 3:26 PM, Aaron Toponce wrote:
> When encrypting a plaintext source, is there a way to predict the size of
> the ciphertext output? I'm sure this depends on the cipher used, as well if
> compression or hashing algos are used.
The single largest thing that affects your output is
> When encrypting a plaintext source, is there a way to predict the size
of
> the ciphertext output? I'm sure this depends on the cipher used, as well
if
> compression or hashing algos are used.
The short answer is "yes," but it's hard to give a more precise answer
without knowing a lot of specifi
Jerome Baum:
>> What I miss is a real use case for it. Is there someone implementing a
>> general purpose time stamping service? IIRC, there used to be some 10
>> years or more ago. Still any? I don't know.
>
> There are a lot of general purpose time stamping services, such as
> -- though that
