9

It seems like what you are actually describing is a way to encode data with Lego bricks, rather than encrypting with them. But, maybe the way that you encode data is hard to invert without knowing a secret key, for example. I don't think the lego adds security to this encoding, though. Suppose you design a method $f$ to encode your message space $\mathcal{M}$...


6

$\underset{\mathcal{K}}{\text{Pr}}[\text{Enc}(K, m_0) = c]$ (and similarly $\underset{\mathcal{K}}{\text{Pr}}[\text{Enc}(K, m_1) = c]$) means the probability that $\text{Enc}(k, m_0) = c$, where you choose the key $k\in \mathcal{K}$ at random. Notice that, here, the values $m_0$ and $c$ are fixed, so what we want to know is, for these fixed $m_0$ and $c$, ...


4

It is possible to build something reminiscent of mechanical cipher machines using Lego Technic gears and less complicated parts: "Poly-Alphabetic Cipher Machine" "Paper Enigma" (encrypts, but is made of cardboard tubes, paper, and sticky tape) "LEGO replica of an Enigma Machine" (Entirely Legos, but alas, this implementation ...


4

You need some kind of authentication of the source. One solution can be to use pre-shared secret. To exchange the secret you need some reliable channel. Only you know if you have such a channel or not. Another approach can be to use TESLA. A brief explanation see here. Also other approaches can be used.


3

The NIST specification of CCM (in full: "Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality"): has an explicit remark about this in section 5.3: The payload may also be empty, in which case the specification degenerates to an authentication mode on the associated data. So yeah, it is safe and ...


3

I guess most asymmetric schemes fall into this. 300 bits is quite a large chunk. Most schemes randomize, if possibly in a specific domain. For instance, removing 300 bits from a randomized RSA ciphertext would mean that the modular exponentiation would return the incorrect response - if it would execute at all (RSA explicitly requires a ciphertext that is ...


3

As you may have found out it depends on the specific system where this can be applied. If AES-256 is supported then the algorithmic overhead is usually limited; it would possibly only be a problem when it comes to embedded devices. As also mentioned, key management is probably the biggest hurdle. Re-establishing keys can be really hard. It can also be very ...


2

I didn't fully understand the plan, but: In CBC, each ciphertext block plays the role of IV for the next block. So, the bruteforce attacker can attack the next block, since the ciphertext block will be send in clear. Are you really afraid that someone will bruteforce a 256-bit key? This is impossible. Also, please consider using authenticated encryption to ...


1

The design rationale for the S-box is given in section 4.3 of the paper. I'll try and expand on the reasoning. The worst sort of S-box would be a linear function i.e. one where every bit of output is just the XOR of certain bits of input. As the rest of the PRESENT round function just involves moving bits around and the XORing of round key a linear S-box ...


1

A long plaintext doesn't mean it can not be guessed. If the hash of the plaintext is available to an attacker such an attacker can efficently verify any guess he may have as to the plain text. In many real world scenarios we encrypt plain text with limited entropy, the text may be large but still have little information not known to the attacker. And with a ...


1

As others indicated, this would not be a scheme that would conform to best practice. Considering that you are asking this question I would strongly suggest to use your code for practice only. In principle you can hash data and then encrypt it. As the hash remains confidential until the key is found, this is considered when it comes to protecting the hash and ...


1

If there is no limit on the cost of interactions,proxy re-encryption works for you. Proxy re-encryption (PRE) is a type of public-key encryption (PKE) that allows a proxy entity to transform or re-encrypt data from one public key to another, without having access to the underlying plaintext or private keys.


1

I am trying to choose a mode of operation for encryption which does has the lowest malleability Well, Format Preserving Encryption modes of operation gives ideal malleability resistance (for modes that never give an 'authentication failure' output); any arbitrary change in the ciphertext (be it a single bit flip of the last bit in the ciphertext, reordering ...


1

You are describing the problem of broadcast encryption. This problem was first studied by Fiat and Naor in the aptly named "Broadcast Encryption" paper where they came up with a scheme resilient against $k$ colluding users with roughly $k$ bandwidth cost. A more efficient scheme using pairing-based cryptography was introduced by Boneh and Gentry in ...


1

One obvious issue with your 'degenerate case TLS' is that, as TLS is deployed, the client cannot be assumed to have apriori knowledge of the server's public key; that needs to be transferred (and authenticated) somehow. However, your question was: Or how could this be defeated? Well, one obvious issue is that it is quite vulnerable to client-side replay ...


Only top voted, non community-wiki answers of a minimum length are eligible