How to hide bit frequency of the inter-packet delays covert channel? I encode a hidden message as different delays between packets of another data stream.

My implementation now is that for each bit,

if the bit is 0, a inter-packet delay between min and middle is generated and
if the bit is 1, a inter-packet delay between middle and max is generated.

Here's my code in Python:

binary_string = ''
m_time = 0.5
min_time = 0.2
max_time = 0.9
csv_array = []
package_stream_array = []
last_timecode = 0
for c in secret:
    binary_string += bin(ord(c))[2:].rjust(7,'0')
for key, digi in enumerate(binary_string):
    if digi == '0':
        last_timecode += uniform(min_time, m_time)
        csv_array.append(last_timecode)
        package_stream_array.append("p({0:d},{1:.2f})".format(key+1, last_timecode ))
    elif digi == '1':
        last_timecode += uniform(m_time,max_time)
        package_stream_array.append("p({0:d},{1:.2f})".format(key+1, last_timecode))
        csv_array.append(last_timecode)
for memeber in package_stream_array:
    print memeber

After I plot a chart, I found the 0,1-frequency still can be observed.

Is there a better way to improve this?

With Steganography, we take a short message, and embed that into a much larger signal, with the goal being that someone seeing the larger signal cannot tell that there's the embedded message.  Now, this larger signal (which might be JPEG, a handwritten message, or in your case, interpacket delays) has a natural distribution; one way of viewing the goal of Steganography is that we want to generate an artificial signal; we pick it in such a way to mimic the natural distribution (so that someone cannot tell that we picked it artificially), however the precise signal we did pick encodes the message we want.

Usually, we do Steganography by taking a real signal, and tweaking it slightly to form the artificial signal.  The hope is that the tweaks do not move the signal significantly out of the natural distribution (at least, not enough to be detectable).  This means that we don't have to understand the entire natural distribution (e.g. if we were embedding our messages into JPEG files, which files would look plausible and which wouldn't); instead, we just need to understand it well enough to know which tweaks don't disrupt the distribution detectably.

However, that's not what you're doing.  You don't have a real signal (that is, there is no original interpacket delay source); you are individually crafting the interpacket delays yourself.  In that case, you really need to answer the question "what does the natural distribution look like"; that is, what do real interpacket delays look like?

Well, we could guess what these delays might look like (perhaps approximately normal distributed with a certain mean and standard deviation), however if you are serious about this, you will need to actually select a real packet source, and measure the delays.  This is more subtle than just measuring the distribution of delays; it also involves (at least) looking at the short term correlations between delays.

Once you have a reasonable model of the probability distribution of a real source, it should not be difficult to craft a way of selecting an element from that distribution.  However, until you have such a model, you really don't have much hope of fooling an intelligent evesdropper who is actively looking for a signal.


ECDH anonymous key exchange to avoid PKI I want to use TLS to encrypt the communication between peers in a P2P network.  Each peer has a well known 256bit peer identifier (the public key of a 256bit elliptic curve keypair). Both peers need to be authenticated against the ECC key.

Each peer has only one ECC key, no RSA key. During the key exchange step, I do not want each peer to generate a self-signed certificate with a bogus RSA key because that would render the authentication meaningless. The peers would have to blindly accept the self-signed RSA certificate because they would not be able to link the RSA key to the ECC key.

Since there is no PKI "authority" to sign each peer certificate, I am considering using ECDH in anon mode to perform the key exchange (TLS_ECDH_anon_WITH_AES_256_CBC_SHA). The anon mode of ECDH will not authenticate the peers at the TLS level, so I want to do the authentication at the application level, by sending/answering a challenge signed by the well known ECC key.

Is this a proper use of ECDH anon, and will a simple challenge/response scheme at the application level guarantee peer authentication?

Also, will this scheme provide forward secrecy?

I have figured out a way to use TLS with only a EC key by using DSA instead of RSA. I had not realized you could do DSA with a EC key. My mistake was trying to use RSA to sign the certificate.

Now I can generate my certificate and self-sign it only with the EC key. The peer will simply check to make sure the certificate was signed by the appropriate node ID (which is the same as the EC public key). And that the public key from the certificate is the same as the node ID.

In practice it simply boils down to using the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 with a custom trust manager.

Thank you both for taking time to answer my question.


Do deterministic secret sharing schemes exist? Are there algorithms for secure secret sharing such that the algorithm depends solely on the value being secured, relying on no randomness in its calculations.

If there aren't, is such an algorithm an impossibility? If there are, what are some examples?

I ask because I've come up with a secret sharing scheme (which is probably littered with flaws ;-)), and I'd like try and prove certain properties about it. If deterministic secret sharing schemes are a no-go, I'd very much appreciate a heads up.

I'm not entirely certain this question is well defined. If it is not, I would greatly appreciate any information on why it is ill defined and how to make it more rigorous if possible.

Any deterministic secret sharing scheme as in the question has the property that any participant can run the deterministic algorithm for a guess of the shared secret, and eliminate the guess if the share that the algorithm deterministically assigns him/her does not match his/her share. This implies that some information about the secret is leaked in his/her share, or that his/her share is pointless (in the sense that his/her share can be removed from any set of shares that allows to reconstruct the secret, while keeping that ability).

Likely that's why there is no seldom such beast in the literature. For a counterexample to this assertion, see that other answer.


side channel attacks on AES Say you have a web application that's performing AES encryption. What sorts of side channel attacks should one keep an eye out for?

Timing attacks affect RSA more than symmetric ciphers in-so-far as I know.

Any ideas?

In my limited understanding, cache attacks should be consider the most. In AES encryption, one need to subBytes using S-Box. So, for data that has been used and saved in cache, it will takes less time to subBytes. So, Mallory can learn about the pattern of plaintext.

https://cr.yp.to/2005-590.html


Is it safer to generate your own Diffie-Hellman primes or to use those defined in RFC 3526? I was wondering if the prime numbers defined for use with Diffie-Hellman in RFC 3526 are more trustworthy than generating one's own, especially considering the recent Arjen Lenstra paper (Ron was wrong, Whit is right) which criticized the similarities detected in public keys and prime numbers across the Internet. Am I better off generating my own safe primes, or am I better off using the ones defined in RFC 3526?

Generating your own group for Diffie-Hellman is not a tough issue; but it is somewhat expensive (it depends on the context, but a 25 MHz ARM device would not like to do it often) and it is not really needed: a good point of DH (and DSA) is that the group parameters can be shared between many users, with no ill effect on the confidentiality of their respective private keys.

For plain Diffie-Hellman, what you need is $p$, $q$ and $g$, such that:

$p$ is a big enough prime (2048 bits are more than enough nowadays);
$q$ is smaller, but still big enough (say 256 bits), prime value which divides $p-1$ ;
$g$ is a generator of a subgroup modulo $p$ with an order that is a multiple of $q$.

The DSA standard (FIPS 186-3) includes a rather detailed procedure for generating adequate group parameters (see annex A), which would be fine for DH too.

There is another side to the issue. While randomly chosen $p$, $q$ and $g$ are good for DH with overwhelming probability, it is possible to specially craft $p$, $q$ and $g$ values such that breaking discrete logarithm modulo $p$ (with generator $g$) would be easy (or at least easier). This can be a problem if your application entails producing the DH group parameters and having other people use them for their own key pairs. If you generate the group parameters but do not tell how you generated them (in a verifiable way), then other people could suspect you of having purposely made them weak. For completely usable group parameters which are immune to such suspicions, you need "nothing up my sleeve" numbers. Annex A of FIPS 186-3 describes the generation process in full details precisely so that it can be verified to be random. RFC 3526 uses $\pi$ for the same reasons.

Therefore, reusing published group parameters is a good idea, both for performance (no need to do the generation yourself, you can save on CPU and also code size) and for trust that can be put into the results by other people.


can half of an encrypted photo be decrypted with the key? if we have like some part of the encrypted picture,is it there any way that the picture can be decrypted. is there any specific algorithm that allows this. like can from 60 per cent of the encrypted picture, can we build it up to determone the actual picture
we also has access to the key. we know the algorithm. our purpose is to convert yhe 60 percent of cipher to image  form

OK, for clarity I'll quickly summarize your scenario:

You have the key and know the encryption algorithm.
You have 60% of the cipher text of an image encrypted under above key and algorithm.
You seek to decrypt the cipher text and reconstruct the full image.

There are two possible answers to this:

It's pretty much impossible. If the 60% are highly fragmented and you only got a bit of ciphertext every now and then, you may either suffer from desynchronization (if you don't know how large the gaps are) or you'll lose potentially even more information because you can't decrypt all the bits (highly dependent on the mode of operation in use)
You're lucky and have about 60% of the picture as a continuous block. This means that chances likely are that you can fully decrypt those 60% of the cipher text and start reconstruction of the image. How much of the image you can recover from 60%, I don't know. I suspect it depends on the details of the format and how interrelated the pixels for it are.


Is email an example of public-key cryptography? It seems like email is at least analogous to public-key cryptography, the public portion of the key being your email address, and the private portion of the key being the password to the email account. Is this merely an analogy, or is email in fact an instance of public-key cryptography?

This is a very abstract and wrong analogy and I assume you are talking about encryption. Often for introducing public key encryption one encounters the "box with lock" example: You publish a box and a lock (your public key) and everyone can put something in the box and close the lock and send it to you. You (the only guy that has the key to the lock  - the private key) can unlock the lock and get the stuff that has been put in there, but no one else ( because you are the only guy with the key to the lock) can do so.

But your email example lacks the main desired feature of this analogy (which is called confidentiality), i.e., anyone who runs your email server or listens in the wire can read all the mails intended to you without the need to know your password. Public key encryption relates the public and private key in a mathematical way (by means of some hard to compute function) such that decryption without knowledge of the private key is computationally infeasible, which is obviously not the case in your example.

Interestingly, identity based encryption does something that comes near to what you describe although cryptographically secure. There your email address (or any arbitrary string) can be your public key. But your private key is not an arbitrary independently chosen password, but some secret that is derived from some trusted party based on your email address. Then, anyone can use your email address to encrypt messages for you and only you knowing the corresponding private key can decrypt.


encryption of digest of unkeyed hash function is susceptible to forgery? I have a question in mind.
Suppose we have a collision-resistant unkeyed-hash function $H(·)$ which outputs a 128-bit digest, and a semantic secure symmetric encryption $E(·,·)$ in the
following way, we can design a Message Authentication Code (MAC) in this manner, so given a message $m$ and the secret key $k$, the mac is the encrypted digest,
$t=E(k, H(m))$.

Is it susceptible to forgery if the encryption is in CBC mode or CTR mode? My intuition tells me that it is possible, but I have no idea of constructing the forgery for them. Any suggestion is welcome, thanks!

An attacker can trivial forge the MAC of any message, given one valid MAC of a known message, in either CBC mode or CTR mode.

Let us assume that the attacker knows a message $m$ and its MAC $E(k, H(m)) = IV, E(k, IV, H(m))$; he has a message $m'$ he wants to form the message to.  He computes $\delta = H(m) \oplus H(m')$, then:

For CTR mode, he computes $IV, E(k, IV, H(m)) \oplus \delta$, when this is decrypted, this results in $H(m) \oplus \delta = H(m')$
For CBC mode, we computes $IV \oplus \delta, E(k, IV, H(m))$; because of how CBC mode works, the first block (128 bits for AES) are the first 128 bits of $H(m) \oplus \delta = H(m')$; because $H$ generates only 128 bits, that's the entire message (nit: depending on CBC mode is padded, that may also be an issue; I'm assuming no padding).

Also, there is no such thing as a "collision resistant hash function with 128 bits output"; assuming that the hash function takes an arbitrary bitstring, we can find a collision in $O(2^{64})$ time, and that's generally considered feasible.


Can I change the S-box and P-box in DES? I am a newbie to crypto and just one quick question on the s-box and p-box of DES. I understood that the s-box is where the security comes from and NSA has somehow decided how it should be filled in.

But my question is that, can we really change the content of the s-box or p-box? Would that break the security somehow? Why or why not?

S & P boxes are not random permutations.
Changing them is not easy.
The position of each element of an such a box is chosen following principles such as Strict Avalanche criterion, Bit independence criterion, non linearity, xor table distribution and maximum expected linear probability.

Not following these makes it prone to differential cryptanalysis.

See Biham & Shamir's work on the cryptanalysis of DES S-Boxes.

Also check out "Comparison of random s-box generation methods" by Dragan Lambić for a different perspective.


Is CAST5 still a secure algorithm to use? I just installed GnuPG for Windows. The documentation says the default symmetric cipher is CAST5. In PGP also, default cipher was CAST5.

Is CAST5 secure to use? Any known attacks reported on this algorithm?

CAST5 seems to be a solid 64-bit block cipher with 128-bit key. As far as I can tell after a short literature search, it's definition is sound and unbroken, despite nearly two decades of exposure (more for the round function).

CAST5 is also known as CAST-128, defined in RFC 2144 (1997), and endorsed by ISO/IEC 18033-3:2010 (current). It is a 16-round Feistel cipher, with each round using 4 (among a total of 8) S-boxes with 8-bit input and 32-bit output; and 32-bit operations (XORs, addition/subtraction), and key-dependent rotations.

CAST5 most (but still mildly) serious weakness is its small block size (64-bit) by modern standards (the trend is 128-bit, e.g. AES). This could be an issue when enciphering large amount of data with the same key using some common modes, including CFB used in OpenPGP and GnuPG, because collisions among random blocks occur with increasing odds (about 0.8% for 4GiB, 40% for 32GiB). For example, it can be disproved with some level of credibility a false claim that a dozen of ≈20GiB files known to have been GnuPG-enciphered using CAST5 correspond to all-zero data encrypted as a computer benchmark, simply by checking if there is any file with colliding blocks (the claimed origin of the encrypted files makes it unlikely, when several collisions are expected for "real" data, like video).

Another inherent limitation is the 128-bit key. There are much worst fears to have in a GnuPG context (how can I trust that BIOS? Hard disk firmware? Keyboard?).

CAST5's implementation may be vulnerable to timing attack related to cache or data-dependent operations. That could be a relatively credible attack vector if hostile software was running on the same CPU with only the isolation provided by an OS or VM. It seems to be a relatively low residual risk.

CAST5 does not seem particularly vulnerable (or resistant) to fault attack, or related-key attack. These types of attacks are not much to fear in the context of GnuPG.

Note: the paper by John Kelsey, Bruce Schneier, and David Wagner: Related-Key Cryptanalysis of 3-WAY, Biham-DES, CAST, DES-X, NewDES, RC2, and TEA (ICICS 1997), is for an earlier version of CAST with only 8 rounds. The paper is made available in Postscript by the last author, and may be viewable online here.