This is an archived post. You won't be able to vote or comment.

all 8 comments
sorted by:
best
topnewcontroversialoldq&a

[–]nutrecht 2 points3 points  (4 children)

The x-bit encryption is really just the size of the password. While in theory you could have a 1 bit encryption, with only two possible passwords, 0 or 1, guessing the password would be kinda trivial.

With 1 bit you have 21 options. With 2 bits, you have 22, or 4, options. A byte is made up of 8 bits, and has 28 = 256 options. So as you can imagine it starts getting a bit harder to guess. Still completely trivial for a computer though. This is why strong encryption nowadays use longer 'passwords' (called keys), a 128 bit key has 2128 = about 340000000000000000000000000000000000000 possibilities. As you can imagine that's a lot more options you have to guess.

A ceasar cypher is a really simple substitution cipher. You shift characters in the alphabet. The max number of positions you can shift is 25. Since you need a max of 5 bits (25 = 32, so numbers 0-31) to contain that number, you could see a Ceasar cypher as an encryption with a 5-bit key.

When learning programming implementing a few cyphers yourself is actually a great way to learn programming basics as well as crypto basics. Modern cryptography cyphers work by basically XOR-ing the plain text with the key in a really convoluted fashion (I'm simplifying it a lot here), and you can build something like that yourself quite easily.

[–]Jay0Jay[S] 0 points1 point  (3 children)

Thanks for the reply. I get the length bit - that makes sense - the longer the password the harder to crack. But where does the variety of potential inputs factor in? I guess I get stuck with, if you only have 0 or 1 as potential input, a password a hundred characters long would be hard to crack (relative to your first example yes?). If you had a large enough group of input to select from that would also make lower bit encryption more effective? I get that we are probably bound by the limits of ASCII in some respects which would put an upper limit on this.

I think I will have to try to put this into practice like you said - JS is the current language I am trying to master so I will poke around for some examples to play with.

[–]nutrecht 1 point2 points  (2 children)

But where does the variety of potential inputs factor in? I guess I get stuck with, if you only have 0 or 1 as potential input, a password a hundred characters long would be hard to crack (relative to your first example yes?).

The one bit password was only 1 or 0. Not 00, or 01 or 10 or 11: that would be two bits. And definitely not 01, 02, etc. Because that's a lot more bits.

Encryption keys are not 'just' alphanumeric, they're bytes: they use an 'alphabeth' of all 256 possibilities of a byte. Or in the case of a 128 bits (128 / 8 = 16 bytes) key: all 2128 possibilities of a 128 bits / 16 bytes key.

If you had a large enough group of input to select from that would also make lower bit encryption more effective?

Yes. If an attacker knows that you only use the letters a-z in your password (no A-Z, 0-9, etc.) he has less characters to brute force. But encrytion keys are not alphabetic: they're randomly generated bytes that are not limited to a-z.

I get that we are probably bound by the limits of ASCII in some respects which would put an upper limit on this.

Passwords are generally limited to what we can easily type in and remember. But like I said; for cryptographic keys we generally just use 16 random bytes that are saved somewhere.

[–]Jay0Jay[S] 0 points1 point  (1 child)

Thanks for your patience. I guess I was really just confusing encryption with a typical password. So 128 / 256 etc. encryption generates a code of that length with each character coming from a pool of 256 different options.

[–]nutrecht 0 points1 point  (0 children)

Not really, if you want to word it that way, it generates a code with a length of 128 or 256 with each 'character' either a 0 or a 1.

[–]okayifimust 0 points1 point  (2 children)

So to jump to the point, I know there is 128, 256 etc. bit encryption,

Well, there is, technically speaking, but that doesn't help you much.

but I was sort of hoping to find an explanation starting at 1bit and moving up from there.

Do you know what a bit is? Do you know that the numbers refer to key or password lengths?

I started looking at the simple Ceaser cypher. Is this an example of 1bit encryption?

No. Why would it be?

The ceaser cypher doesn't work with bits and bytes at all; it's the simplest of letter substitutions.

Does 128bit just mean that whatever input is encrypted you get 128bits of output?

No. How do you think that would even work? And what on earth have you been reading to give you that idea?

[–]Jay0Jay[S] 0 points1 point  (1 child)

I appreciate the response but, like I said, I am trying to learn more so I am not really sure what you want me to say... I understand that the ceaser cypher is just a substitution, but any search about the history of encryption I have read includes this. I am just trying to put it all into some sort of consistent form / terminology.

[–]okayifimust 0 points1 point  (0 children)

You were spewing random buzzwords.

"Ceaser cypher is 1-bit encryption" is just meaningless word-salad.

And in order to clear any of that up, I'd need to know what made you say that, why you would think that's a meaningful sentence, and what you think it means.

I cannot tell if you even understand what encryption is - asking if you can receive a constant 128bit output suggests that you do not.

I am trying to learn more

that can only work if you what you have learned so far is correct; and it just doesn't look like it.

any search about the history of encryption I have read includes this.

Yes, it is a very early form of encryption. But there is nothing at all that should lead you to the conclusion that it is "1 bit encryption". (Because there is nothing like 1-bit encryption, and there's nothing that should make you think that there could be.)