 |
|
| Science Forum Index » Cryptography Forum » Looking for encryption algorithm... |
|
Page 1 of 1 |
|
| Author |
Message |
| Anonymous... |
 Posted: Mon Oct 19, 2009 8:26 pm |
|
|
|
Guest
|
Hi,
I am new to encryption. I am looking for an encryption algorithm that has the following characteristics:
1. the resulting encrypted data can be reversed (i.e. can be decrypted)
2. the encrypted string conforms to some length maximum equal to the original string.
3. preferably does not need to keep a large lookup table between applications
Is this even possible?
Thanks. |
|
|
| Back to top |
|
|
|
| Paul Rubin... |
| Posted: Tue Oct 20, 2009 12:39 am |
|
|
|
Guest
|
Anonymous <cripto at (no spam) ecn.org> writes:
[quote]1. the resulting encrypted data can be reversed (i.e. can be
decrypted)
[/quote]
Not a problem.
[quote]2. the encrypted string conforms to some length maximum equal to the
original string.
[/quote]
Problem. This is generally considered a security failure because it
tells the attacker when you have encrypted the same string twice,
which is an information leak. While some applications may be able to
tolerate that, a newbie like yourself shouldn't attempt to make such a
judgement, which is easy to get wrong. Use an encryption plus
authentication mode, which in simplest form means the ciphertext will
be a few dozen bytes longer than the plaintext. If that's
unacceptable, describe the application in more detail and we may be
able to do something about it.
[quote]3. preferably does not need to keep a large lookup table between
applications
[/quote]
Not a problem. |
|
|
| Back to top |
|
|
|
| rossum... |
| Posted: Tue Oct 20, 2009 3:23 am |
|
|
|
Guest
|
On Tue, 20 Oct 2009 08:26:39 +0200 (CEST), Anonymous <cripto at (no spam) ecn.org>
wrote:
[quote]Hi,
I am new to encryption. I am looking for an encryption algorithm that has the following characteristics:
1. the resulting encrypted data can be reversed (i.e. can be decrypted)
If you can't decrypt then it is not an encryption but a hash.[/quote]
[quote]2. the encrypted string conforms to some length maximum equal to the original string.
Use a stream cypher or a block cypher in CTR mode. For very large[/quote]
plaintexts, compress them before encryption.
As Paul pointed out, having exactly the same length will leak
information to an attacker. What you might want to do is to pick a
fixed length, at least as long as the longest message, and pad all
messages to that length. That would allow you the option to use a
block cypher in CBC mode.
Paul's point about authentication is also very relevant. You do not
want an attacker altering the message in transit.
[quote]3. preferably does not need to keep a large lookup table between applications
You will need to keep keys, IVs, nonces etc. but they are not "large".[/quote]
[quote]
Is this even possible?
Yes.[/quote]
It would help us if we know a little more about your application, what
you are trying to protect and who you are trying to protect in from.
rossum
[quote]
Thanks.[/quote] |
|
|
| Back to top |
|
|
|
| qman qman... |
| Posted: Tue Oct 20, 2009 6:51 am |
|
|
|
Guest
|
On Oct 20, 2:23 am, rossum <rossu... at (no spam) coldmail.com> wrote:
[quote]
Use a stream cypher or a block cypher in CTR mode. For very large
plaintexts, compress them before encryption.
As Paul pointed out, having exactly the same length will leak
information to an attacker. What you might want to do is to pick a
fixed length, at least as long as the longest message, and pad all
messages to that length. That would allow you the option to use a
block cypher in CBC mode.
Paul's point about authentication is also very relevant. You do not
want an attacker altering the message in transit.
3. preferably does not need to keep a large lookup table between applications
You will need to keep keys, IVs, nonces etc. but they are not "large".
Is this even possible?
Yes.
It would help us if we know a little more about your application, what
you are trying to protect and who you are trying to protect in from.
rossum
[/quote]
Thanks for your answers. A little more about what I am looking for:
I need to encrypt strings but they don't have to be the same length.
They just need to conform to the same length restrictions as the
original. e.g. If the original can only be up to 32 bytes the
encrypted string should also be up to 32 bytes, Once encrypted, I need
to be able to decrypt it at a later time given the same keys, etc. I
can keep a few key values around but not long lookup tables, etc.
I hope this provides the necessary info.
Thanks again. |
|
|
| Back to top |
|
|
|
| qman qman... |
| Posted: Tue Oct 20, 2009 8:09 am |
|
|
|
Guest
|
On Oct 20, 10:37 am, Unruh <unruh-s... at (no spam) physics.ubc.ca> wrote:
[quote]qman qman <newbq... at (no spam) gmail.com> writes:
On Oct 20, 2:23=A0am, rossum <rossu... at (no spam) coldmail.com> wrote:
Use a stream cypher or a block cypher in CTR mode. =A0For very large
plaintexts, compress them before encryption.
As Paul pointed out, having exactly the same length will leak
information to an attacker. =A0What you might want to do is to pick a
fixed length, at least as long as the longest message, and pad all
messages to that length. =A0That would allow you the option to use a
block cypher in CBC mode.
Paul's point about authentication is also very relevant. =A0You do not
want an attacker altering the message in transit.
3. preferably does not need to keep a large lookup table between applica> >tions
You will need to keep keys, IVs, nonces etc. but they are not "large".
Is this even possible?
Yes.
It would help us if we know a little more about your application, what
you are trying to protect and who you are trying to protect in from.
rossum
Thanks for your answers. A little more about what I am looking for:
I need to encrypt strings but they don't have to be the same length.
They just need to conform to the same length restrictions as the
original. e.g. If the original can only be up to 32 bytes the
encrypted string should also be up to 32 bytes, Once encrypted, I need
to be able to decrypt it at a later time given the same keys, etc. I
can keep a few key values around but not long lookup tables, etc.
AES.
A block cypher like AES encrypts things a block at a time, that block being 128
bits (16 bytes) long. Thus as long as your "longest string" is a multiple of 16
bytes, AES will satisfy that. All you need to save is the key in order to decrypt
it.
[/quote]
Thanks so much! One last question: Is the result repeatable? i.e. the
same input results in the same encrypted string every time? |
|
|
| Back to top |
|
|
|
| mike clark... |
| Posted: Tue Oct 20, 2009 8:15 am |
|
|
|
Guest
|
On Oct 20, 12:09 pm, qman qman <newbq... at (no spam) gmail.com> wrote:
[quote]On Oct 20, 10:37 am, Unruh <unruh-s... at (no spam) physics.ubc.ca> wrote:
qman qman <newbq... at (no spam) gmail.com> writes:
On Oct 20, 2:23=A0am, rossum <rossu... at (no spam) coldmail.com> wrote:
Use a stream cypher or a block cypher in CTR mode. =A0For very large
plaintexts, compress them before encryption.
As Paul pointed out, having exactly the same length will leak
information to an attacker. =A0What you might want to do is to pick a
fixed length, at least as long as the longest message, and pad all
messages to that length. =A0That would allow you the option to use a
block cypher in CBC mode.
Paul's point about authentication is also very relevant. =A0You do not
want an attacker altering the message in transit.
3. preferably does not need to keep a large lookup table between applica> > >tions
You will need to keep keys, IVs, nonces etc. but they are not "large".
Is this even possible?
Yes.
It would help us if we know a little more about your application, what
you are trying to protect and who you are trying to protect in from.
rossum
Thanks for your answers. A little more about what I am looking for:
I need to encrypt strings but they don't have to be the same length.
They just need to conform to the same length restrictions as the
original. e.g. If the original can only be up to 32 bytes the
encrypted string should also be up to 32 bytes, Once encrypted, I need
to be able to decrypt it at a later time given the same keys, etc. I
can keep a few key values around but not long lookup tables, etc.
AES.
A block cypher like AES encrypts things a block at a time, that block being 128
bits (16 bytes) long. Thus as long as your "longest string" is a multiple of 16
bytes, AES will satisfy that. All you need to save is the key in order to decrypt
it.
Thanks so much! One last question: Is the result repeatable? i.e. the
same input results in the same encrypted string every time?
[/quote]
As long as you use the same key and IV (if needed), encrypting the
same string should always result in the same cipher text. There are
serious security implications that go along with this that you should
understand before deploying a real system, however. |
|
|
| Back to top |
|
|
|
| qman qman... |
| Posted: Tue Oct 20, 2009 9:09 am |
|
|
|
Guest
|
On Oct 20, 11:36 am, Paul Rubin <http://phr... at (no spam) NOSPAM.invalid> wrote:
[quote]qman qman <newbq... at (no spam) gmail.com> writes:
Thanks so much! One last question: Is the result repeatable? i.e. the
same input results in the same encrypted string every time?
It's not clear whether you understand that "repeatability", the same
input resulting in the same encrypted string every time, is a bug and
not a feature. It tells the attacker when two of your ciphertexts
have came from the same plaintext.
[/quote]
Thanks. Both the you and mike point out very legitimate security
concerns.
The application for which I am considering this is for the purposes of
dealing with
a relatively small volume of data and used not within the daily
production flow but
as a standalone tool during testing and development phases.
If I use AES to encrypt certain keys (alphanumeric), I would want for
all occurrences
of the said key to result in the same string thereby be de-identified
but equal after
the encryption is applied.
Other schemes such as hashing algorithms could be used for this BUT
they would
preclude reversal. There may be other alternatives unknown to me. I
would rather
stay away from schemes that require me to have a lookup table in order
to do
decryption.
This is a data scenario I am looking for. Let's say I have 3 records
StudentID [max 32 bytes] City State
-------------------------------------- -----------
----------------
12345 New York New York
X987653 Cleveland Ohio
12345 New York New York
StudentID is a key which links the first and third rows. I would want
them to result in the same encrypted text. I would also like a
privileged user who has access to the key to be able to decrypt it to
get the original value. The assumption here is that the encryption key
is safe.
Thanks. |
|
|
| Back to top |
|
|
|
| Paul Rubin... |
| Posted: Tue Oct 20, 2009 11:07 am |
|
|
|
Guest
|
qman qman <newbqman at (no spam) gmail.com> writes:
[quote]I need to encrypt strings but they don't have to be the same length.
They just need to conform to the same length restrictions as the
original. e.g. If the original can only be up to 32 bytes the
encrypted string should also be up to 32 bytes,
[/quote]
This is no good in general. The ciphertext has to be LONGER than the
plaintext, by some amount. You're in good shape if that amount can be
32 bytes, and it can be smaller (like 16 bytes) without too much loss.
If you want it much smaller than 16 bytes you have to start giving
up security. |
|
|
| Back to top |
|
|
|
| Unruh... |
| Posted: Tue Oct 20, 2009 11:37 am |
|
|
|
Guest
|
qman qman <newbqman at (no spam) gmail.com> writes:
[quote]On Oct 20, 2:23=A0am, rossum <rossu... at (no spam) coldmail.com> wrote:
Use a stream cypher or a block cypher in CTR mode. =A0For very large
plaintexts, compress them before encryption.
As Paul pointed out, having exactly the same length will leak
information to an attacker. =A0What you might want to do is to pick a
fixed length, at least as long as the longest message, and pad all
messages to that length. =A0That would allow you the option to use a
block cypher in CBC mode.
Paul's point about authentication is also very relevant. =A0You do not
want an attacker altering the message in transit.
3. preferably does not need to keep a large lookup table between applica=
tions
You will need to keep keys, IVs, nonces etc. but they are not "large".
Is this even possible?
Yes.
It would help us if we know a little more about your application, what
you are trying to protect and who you are trying to protect in from.
rossum
Thanks for your answers. A little more about what I am looking for:
I need to encrypt strings but they don't have to be the same length.
They just need to conform to the same length restrictions as the
original. e.g. If the original can only be up to 32 bytes the
encrypted string should also be up to 32 bytes, Once encrypted, I need
to be able to decrypt it at a later time given the same keys, etc. I
can keep a few key values around but not long lookup tables, etc.
[/quote]
AES.
A block cypher like AES encrypts things a block at a time, that block being 128
bits (16 bytes) long. Thus as long as your "longest string" is a multiple of 16
bytes, AES will satisfy that. All you need to save is the key in order to decrypt
it.
[quote]I hope this provides the necessary info.
Thanks again.[/quote] |
|
|
| Back to top |
|
|
|
| Paul Rubin... |
| Posted: Tue Oct 20, 2009 12:36 pm |
|
|
|
Guest
|
qman qman <newbqman at (no spam) gmail.com> writes:
[quote]Thanks so much! One last question: Is the result repeatable? i.e. the
same input results in the same encrypted string every time?
[/quote]
It's not clear whether you understand that "repeatability", the same
input resulting in the same encrypted string every time, is a bug and
not a feature. It tells the attacker when two of your ciphertexts
have came from the same plaintext. |
|
|
| Back to top |
|
|
|
| Paul Rubin... |
| Posted: Tue Oct 20, 2009 2:22 pm |
|
|
|
Guest
|
qman qman <newbqman at (no spam) gmail.com> writes:
[quote]Thanks. Both the you and mike point out very legitimate security
concerns. The application for which I am considering this is for
the purposes of dealing with a relatively small volume of data and
used not within the daily production flow but as a standalone tool
during testing and development phases.
[/quote]
You're saying you want to encrypt the test data but leave the
production data in the clear? I can't think of many applications
where that makes sense.
[quote]If I use AES to encrypt certain keys (alphanumeric), I would want
for all occurrences of the said key to result in the same string
thereby be de-identified but equal after the encryption is applied.
[/quote]
Why do you want that?
[quote]This is a data scenario I am looking for. Let's say I have 3 records
StudentID [max 32 bytes] City State
-------------------------------------- -----------
----------------
12345 New York New York
X987653 Cleveland Ohio
12345 New York New York
StudentID is a key which links the first and third rows. I would want
them to result in the same encrypted text.
[/quote]
OK, this starts to sound like you are trying to anonymize some student
data while allowing analysis on it by people who aren't supposed to be
able to identify individual students. That is a very tricky problem
that has been screwed up a lot of times. See the Wikipedia article
section
http://en.wikipedia.org/wiki/Differential_privacy#Motivation
for how both Netflix and the Massachusetts Group Insurance Commission
screwed it up, releasing "anonymized" data that it turned out could be
inferentially linked back to individuals. There is similarly a big
controversy right now in Oklahoma because the state legislature wants
to release certain "anonymized" medical data online, which will
contain enough info (e.g. patient's history and zip code) to be able
to identify the person in some cases (maybe intentionally on the
legislature's part).
If you're doing something like this with serious amounts of data about
real people, you REALLY have to get some security specialists involved,
or else with your present state of knowledge you're getting perilously
close to do-it-yourself brain surgery.
The purely technical part of your question is pretty simple, but it's
very often the case when someone starts asking technical cryptography
questions, that the questions they're asking aren't really the
appropriate ones for what they are trying to do. So it's important to
get the larger picture sorted out. If you are at a university you
might ask someone in the computer science department to refer you to
someone who can help you more closely. |
|
|
| Back to top |
|
|
|
| rossum... |
| Posted: Tue Oct 20, 2009 2:55 pm |
|
|
|
Guest
|
On Tue, 20 Oct 2009 17:37:26 GMT, Unruh <unruh-spam at (no spam) physics.ubc.ca>
wrote:
[quote]AES.
A block cypher like AES encrypts things a block at a time, that block being 128
bits (16 bytes) long. Thus as long as your "longest string" is a multiple of 16
bytes, AES will satisfy that. All you need to save is the key in order to decrypt
it.
Using AES is an excellent suggestion. Using AES in CTR mode gets[/quote]
round the size restriction on cyphertext; you can easily encrypt a
part block at the end of a plaintext.
Depending on the mode used with AES you may need an IV (CBC mode) or a
nonce (CTR mode) as well as the key.
rossum |
|
|
| Back to top |
|
|
|
| Unruh... |
| Posted: Tue Oct 20, 2009 5:05 pm |
|
|
|
Guest
|
qman qman <newbqman at (no spam) gmail.com> writes:
[quote]On Oct 20, 10:37=A0am, Unruh <unruh-s... at (no spam) physics.ubc.ca> wrote:
qman qman <newbq... at (no spam) gmail.com> writes:
On Oct 20, 2:23=3DA0am, rossum <rossu... at (no spam) coldmail.com> wrote:
Use a stream cypher or a block cypher in CTR mode. =3DA0For very large
plaintexts, compress them before encryption.
As Paul pointed out, having exactly the same length will leak
information to an attacker. =3DA0What you might want to do is to pick =
a
fixed length, at least as long as the longest message, and pad all
messages to that length. =3DA0That would allow you the option to use a
block cypher in CBC mode.
Paul's point about authentication is also very relevant. =3DA0You do n=
ot
want an attacker altering the message in transit.
3. preferably does not need to keep a large lookup table between appl=
ica=3D
tions
You will need to keep keys, IVs, nonces etc. but they are not "large".
Is this even possible?
Yes.
It would help us if we know a little more about your application, what
you are trying to protect and who you are trying to protect in from.
rossum
Thanks for your answers. A little more about what I am looking for:
I need to encrypt strings but they don't have to be the same length.
They just need to conform to the same length restrictions as the
original. e.g. If the original can only be up to 32 bytes the
encrypted string should also be up to 32 bytes, Once encrypted, I need
to be able to decrypt it at a later time given the same keys, etc. I
can keep a few key values around but not long lookup tables, etc.
AES.
A block cypher like AES encrypts things a block at a time, that block bei=
ng 128
bits (16 bytes) long. Thus as long as your "longest string" is a multiple=
of 16
bytes, AES will satisfy that. All you need to save is the key in order to=
decrypt
it.
Thanks so much! One last question: Is the result repeatable? i.e. the
same input results in the same encrypted string every time?
[/quote]
Depends on what mode you use. In cypher block mode, yes. In some of the other
modes, no. For those you usually have an intitial piece of random text ( say 16
bytes long) and that changes the output. |
|
|
| Back to top |
|
|
|
|
|
All times are GMT - 5 Hours
The time now is Wed Mar 10, 2010 8:12 am
|
|