Can AES be used with a static key?
I am making an embedded system for a project that uses AES.
As I cannot accommodate key generation (hardware constraints) I am using a static key. I can use another small algorithm to create dynamism and then pass it to the static AES.
I'm concerned about using a static key, is it safe?
encryption aes cryptanalysis
edited yesterday
kelalaka
5,63222040
asked yesterday
kali007
161
New contributor
kali007 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
I am making an embedded system for a project that uses AES.
As I cannot accommodate key generation (hardware constraints) I am using a static key. I can use another small algorithm to create dynamism and then pass it to the static AES.
I'm concerned about using a static key, is it safe?
encryption aes cryptanalysis
edited yesterday
kelalaka
5,63222040
asked yesterday
kali007
161
New contributor
kali007 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
You should write more about yoursmallalgorithm; what is the randomness source. and also, are there any hash algorithm around.
– kelalaka
yesterday
Have you looked on LED cipher? It is AES-like , they use one key with round constants. It might help you
– hardyrama
yesterday
if you don’t use AES, you’ll have a lot more transistors for better security options. a feistel network cipher will serve you well
– b degnan
yesterday
add a comment |
I am making an embedded system for a project that uses AES.
As I cannot accommodate key generation (hardware constraints) I am using a static key. I can use another small algorithm to create dynamism and then pass it to the static AES.
I'm concerned about using a static key, is it safe?
encryption aes cryptanalysis
edited yesterday
kelalaka
5,63222040
asked yesterday
kali007
161
New contributor
kali007 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I am making an embedded system for a project that uses AES.
As I cannot accommodate key generation (hardware constraints) I am using a static key. I can use another small algorithm to create dynamism and then pass it to the static AES.
I'm concerned about using a static key, is it safe?
encryption aes cryptanalysis
encryption aes cryptanalysis
edited yesterday
kelalaka
5,63222040
asked yesterday
kali007
161
New contributor
kali007 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited yesterday
kelalaka
5,63222040
asked yesterday
kali007
161
New contributor
kali007 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited yesterday
kelalaka
5,63222040
edited yesterday
kelalaka
5,63222040
edited yesterday
kelalaka
5,63222040
5,63222040
asked yesterday
kali007
161
New contributor
kali007 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked yesterday
kali007
161
asked yesterday
kali007
161
161
New contributor
kali007 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
kali007 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
kali007 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
You should write more about yoursmallalgorithm; what is the randomness source. and also, are there any hash algorithm around.
– kelalaka
yesterday
Have you looked on LED cipher? It is AES-like , they use one key with round constants. It might help you
– hardyrama
yesterday
if you don’t use AES, you’ll have a lot more transistors for better security options. a feistel network cipher will serve you well
– b degnan
yesterday
add a comment |
You should write more about yoursmallalgorithm; what is the randomness source. and also, are there any hash algorithm around.
– kelalaka
yesterday
Have you looked on LED cipher? It is AES-like , they use one key with round constants. It might help you
– hardyrama
yesterday
if you don’t use AES, you’ll have a lot more transistors for better security options. a feistel network cipher will serve you well
– b degnan
yesterday
You should write more about your
small algorithm; what is the randomness source. and also, are there any hash algorithm around.– kelalaka
yesterday
You should write more about your
small algorithm; what is the randomness source. and also, are there any hash algorithm around.– kelalaka
yesterday
Have you looked on LED cipher? It is AES-like , they use one key with round constants. It might help you
– hardyrama
yesterday
Have you looked on LED cipher? It is AES-like , they use one key with round constants. It might help you
– hardyrama
yesterday
if you don’t use AES, you’ll have a lot more transistors for better security options. a feistel network cipher will serve you well
– b degnan
yesterday
if you don’t use AES, you’ll have a lot more transistors for better security options. a feistel network cipher will serve you well
– b degnan
yesterday
add a comment |
2 Answers
2
active
oldest
votes
AES - the block cipher - can be used to process a large amount of data. In that sense it is possible to keep a single static key. How much data is specified in this answer by Thomas on the Security.SE site: around $2^{64}$ blocks of data or 250 millions of terabytes.
If the use of AES with a static key is secure therefore depends not on the block cipher but how the block cipher is used: in other words, the protocol or protocols in which it is used. It may be insecure because the mode of operation introduces constraints that are voided by your protocol. It may not be secure because replay attacks are possible, oracles exist, the combination of cipher mode and MAC mode are vulnerable to attack, the list goes on...
AES does certainly leak information if the same input block is fed into it twice. If that's an issue depends - again - on the protocol. Your small algorithm could possibly be used to generate nonces so that the input to the AES cipher is always unique.
That using such a scheme can be relatively secure is shown by memory cards such as DESFire (which, funny enough, may also use AES). These cards are generally provided with one or more symmetric keys that are static during the lifetime of the product. Of course all the devices use derived keys that are tied to some unique identity of the card, otherwise extraction of one key would be enough to destroy the functionality of all of the cards.
Still, if the master key (from which the device keys are derived) is lost from which the other keys have been derived such schemes are certain to run into some form of trouble or another. It is very tricky to perform key management on static keys, and such schemes are fraught with danger. This is why asymmetric keys are commonly used with a PKI scheme to ensure validity. For such schemes the controlling device doesn't need to hold a master key.
Sometimes devices are also provided with multiple keys (for multiple master keys) in advance. That way the device may still be used with a new master key if one becomes compromised. Needless to say, invalidating a master key on the devices and moving to the next one is tricky at best (if you can detect compromise in the first place), but you could possibly provide key rollover for your protocol.
Needless to say, using a static key makes it very vulnerable against side channel attacks on the implementation. Compare this for instance with a secure channel which needs to be reestablished using fresh session keys any time the MAC authentication tag is invalid. Those keys are probably invalidated before you can find out anything interesting about them.
answered yesterday
Maarten Bodewes♦
53.2k677192
1
I'm still annoyed about the fact that some agencies require you to proof that an implementation is invulnerable to certain side channel attacks even if you've just made them impossible in your higher level protocol implementation. Of course, yes, tricky stuff as you must invalidate the keys in a timely fashon, but still...
– Maarten Bodewes♦
yesterday
1
The 256 exabytes is the point where you are going to be almost certain to have hit a collision. It isn't safe to get anywhere close to that amount. If you want to keep the probability of a collision to be less than 1 in $2^{64}$ you need to stay at less than 64 GB of data encrypted with the same AES key.
– kasperd
yesterday
Are you sure? We are talking about the block cipher right? Not any mode of operation. Half of 128 is 64 last time I checked.
– Maarten Bodewes♦
yesterday
Which mode of operation is used doesn't make a lot of difference as long as there aren't any vulnerabilities in the mode itself. There are modes where the probability of collisions is about the same as it would be with random inputs. There are modes which never use the same input, but that will cause the output to be distinguishable from random due to the lack of collisions in the output. The birthday limit tells us you'll need about $2^{n/2}$ blocks before the probability of a collision is 50%. But my point is that a 50% probability of a collision is a too high probability.
– kasperd
yesterday
1
I consider 1 in $2^{n/2}$ to be a reasonable probability of a collision to aim for. If you encrypt $m$ random blocks that gives you about $m^2$ pairs of blocks which could potentially collide. Each of those will have a probability of 1 in $2^n$ of colliding. $m^2$ pairs with a collision probability each of 1 in $2^n$ means the overall chance of a collision is about $frac{m^2}{2^n}$ which we want to be no more than $frac{1}{2^{n/2}}$. That means $m leq 2^{n/4}$.
– kasperd
yesterday
|
show 3 more comments
You can fix a public key to AES and use it as a random permutation. Now based on
a random permutation, you can construct an ideal cipher out of it (you might need more than one call to the random permutation). There might be efficiency loss, but it works and no AES-key scheduling is needed.Note that AES key scheduling is very similar to one round of AES encryption. See https://eprint.iacr.org/2015/751.pdf page 10.
answered yesterday
redplum
1976
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
});
});
}, "mathjax-editing");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "281"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
kali007 is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f66259%2fcan-aes-be-used-with-a-static-key%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
AES - the block cipher - can be used to process a large amount of data. In that sense it is possible to keep a single static key. How much data is specified in this answer by Thomas on the Security.SE site: around $2^{64}$ blocks of data or 250 millions of terabytes.
If the use of AES with a static key is secure therefore depends not on the block cipher but how the block cipher is used: in other words, the protocol or protocols in which it is used. It may be insecure because the mode of operation introduces constraints that are voided by your protocol. It may not be secure because replay attacks are possible, oracles exist, the combination of cipher mode and MAC mode are vulnerable to attack, the list goes on...
AES does certainly leak information if the same input block is fed into it twice. If that's an issue depends - again - on the protocol. Your small algorithm could possibly be used to generate nonces so that the input to the AES cipher is always unique.
That using such a scheme can be relatively secure is shown by memory cards such as DESFire (which, funny enough, may also use AES). These cards are generally provided with one or more symmetric keys that are static during the lifetime of the product. Of course all the devices use derived keys that are tied to some unique identity of the card, otherwise extraction of one key would be enough to destroy the functionality of all of the cards.
Still, if the master key (from which the device keys are derived) is lost from which the other keys have been derived such schemes are certain to run into some form of trouble or another. It is very tricky to perform key management on static keys, and such schemes are fraught with danger. This is why asymmetric keys are commonly used with a PKI scheme to ensure validity. For such schemes the controlling device doesn't need to hold a master key.
Sometimes devices are also provided with multiple keys (for multiple master keys) in advance. That way the device may still be used with a new master key if one becomes compromised. Needless to say, invalidating a master key on the devices and moving to the next one is tricky at best (if you can detect compromise in the first place), but you could possibly provide key rollover for your protocol.
Needless to say, using a static key makes it very vulnerable against side channel attacks on the implementation. Compare this for instance with a secure channel which needs to be reestablished using fresh session keys any time the MAC authentication tag is invalid. Those keys are probably invalidated before you can find out anything interesting about them.
answered yesterday
Maarten Bodewes♦
53.2k677192
1
I'm still annoyed about the fact that some agencies require you to proof that an implementation is invulnerable to certain side channel attacks even if you've just made them impossible in your higher level protocol implementation. Of course, yes, tricky stuff as you must invalidate the keys in a timely fashon, but still...
– Maarten Bodewes♦
yesterday
1
The 256 exabytes is the point where you are going to be almost certain to have hit a collision. It isn't safe to get anywhere close to that amount. If you want to keep the probability of a collision to be less than 1 in $2^{64}$ you need to stay at less than 64 GB of data encrypted with the same AES key.
– kasperd
yesterday
Are you sure? We are talking about the block cipher right? Not any mode of operation. Half of 128 is 64 last time I checked.
– Maarten Bodewes♦
yesterday
Which mode of operation is used doesn't make a lot of difference as long as there aren't any vulnerabilities in the mode itself. There are modes where the probability of collisions is about the same as it would be with random inputs. There are modes which never use the same input, but that will cause the output to be distinguishable from random due to the lack of collisions in the output. The birthday limit tells us you'll need about $2^{n/2}$ blocks before the probability of a collision is 50%. But my point is that a 50% probability of a collision is a too high probability.
– kasperd
yesterday
1
I consider 1 in $2^{n/2}$ to be a reasonable probability of a collision to aim for. If you encrypt $m$ random blocks that gives you about $m^2$ pairs of blocks which could potentially collide. Each of those will have a probability of 1 in $2^n$ of colliding. $m^2$ pairs with a collision probability each of 1 in $2^n$ means the overall chance of a collision is about $frac{m^2}{2^n}$ which we want to be no more than $frac{1}{2^{n/2}}$. That means $m leq 2^{n/4}$.
– kasperd
yesterday
|
show 3 more comments
AES - the block cipher - can be used to process a large amount of data. In that sense it is possible to keep a single static key. How much data is specified in this answer by Thomas on the Security.SE site: around $2^{64}$ blocks of data or 250 millions of terabytes.
If the use of AES with a static key is secure therefore depends not on the block cipher but how the block cipher is used: in other words, the protocol or protocols in which it is used. It may be insecure because the mode of operation introduces constraints that are voided by your protocol. It may not be secure because replay attacks are possible, oracles exist, the combination of cipher mode and MAC mode are vulnerable to attack, the list goes on...
AES does certainly leak information if the same input block is fed into it twice. If that's an issue depends - again - on the protocol. Your small algorithm could possibly be used to generate nonces so that the input to the AES cipher is always unique.
That using such a scheme can be relatively secure is shown by memory cards such as DESFire (which, funny enough, may also use AES). These cards are generally provided with one or more symmetric keys that are static during the lifetime of the product. Of course all the devices use derived keys that are tied to some unique identity of the card, otherwise extraction of one key would be enough to destroy the functionality of all of the cards.
Still, if the master key (from which the device keys are derived) is lost from which the other keys have been derived such schemes are certain to run into some form of trouble or another. It is very tricky to perform key management on static keys, and such schemes are fraught with danger. This is why asymmetric keys are commonly used with a PKI scheme to ensure validity. For such schemes the controlling device doesn't need to hold a master key.
Sometimes devices are also provided with multiple keys (for multiple master keys) in advance. That way the device may still be used with a new master key if one becomes compromised. Needless to say, invalidating a master key on the devices and moving to the next one is tricky at best (if you can detect compromise in the first place), but you could possibly provide key rollover for your protocol.
Needless to say, using a static key makes it very vulnerable against side channel attacks on the implementation. Compare this for instance with a secure channel which needs to be reestablished using fresh session keys any time the MAC authentication tag is invalid. Those keys are probably invalidated before you can find out anything interesting about them.
answered yesterday
Maarten Bodewes♦
53.2k677192
1
I'm still annoyed about the fact that some agencies require you to proof that an implementation is invulnerable to certain side channel attacks even if you've just made them impossible in your higher level protocol implementation. Of course, yes, tricky stuff as you must invalidate the keys in a timely fashon, but still...
– Maarten Bodewes♦
yesterday
1
The 256 exabytes is the point where you are going to be almost certain to have hit a collision. It isn't safe to get anywhere close to that amount. If you want to keep the probability of a collision to be less than 1 in $2^{64}$ you need to stay at less than 64 GB of data encrypted with the same AES key.
– kasperd
yesterday
Are you sure? We are talking about the block cipher right? Not any mode of operation. Half of 128 is 64 last time I checked.
– Maarten Bodewes♦
yesterday
Which mode of operation is used doesn't make a lot of difference as long as there aren't any vulnerabilities in the mode itself. There are modes where the probability of collisions is about the same as it would be with random inputs. There are modes which never use the same input, but that will cause the output to be distinguishable from random due to the lack of collisions in the output. The birthday limit tells us you'll need about $2^{n/2}$ blocks before the probability of a collision is 50%. But my point is that a 50% probability of a collision is a too high probability.
– kasperd
yesterday
1
I consider 1 in $2^{n/2}$ to be a reasonable probability of a collision to aim for. If you encrypt $m$ random blocks that gives you about $m^2$ pairs of blocks which could potentially collide. Each of those will have a probability of 1 in $2^n$ of colliding. $m^2$ pairs with a collision probability each of 1 in $2^n$ means the overall chance of a collision is about $frac{m^2}{2^n}$ which we want to be no more than $frac{1}{2^{n/2}}$. That means $m leq 2^{n/4}$.
– kasperd
yesterday
|
show 3 more comments
AES - the block cipher - can be used to process a large amount of data. In that sense it is possible to keep a single static key. How much data is specified in this answer by Thomas on the Security.SE site: around $2^{64}$ blocks of data or 250 millions of terabytes.
If the use of AES with a static key is secure therefore depends not on the block cipher but how the block cipher is used: in other words, the protocol or protocols in which it is used. It may be insecure because the mode of operation introduces constraints that are voided by your protocol. It may not be secure because replay attacks are possible, oracles exist, the combination of cipher mode and MAC mode are vulnerable to attack, the list goes on...
AES does certainly leak information if the same input block is fed into it twice. If that's an issue depends - again - on the protocol. Your small algorithm could possibly be used to generate nonces so that the input to the AES cipher is always unique.
That using such a scheme can be relatively secure is shown by memory cards such as DESFire (which, funny enough, may also use AES). These cards are generally provided with one or more symmetric keys that are static during the lifetime of the product. Of course all the devices use derived keys that are tied to some unique identity of the card, otherwise extraction of one key would be enough to destroy the functionality of all of the cards.
Still, if the master key (from which the device keys are derived) is lost from which the other keys have been derived such schemes are certain to run into some form of trouble or another. It is very tricky to perform key management on static keys, and such schemes are fraught with danger. This is why asymmetric keys are commonly used with a PKI scheme to ensure validity. For such schemes the controlling device doesn't need to hold a master key.
Sometimes devices are also provided with multiple keys (for multiple master keys) in advance. That way the device may still be used with a new master key if one becomes compromised. Needless to say, invalidating a master key on the devices and moving to the next one is tricky at best (if you can detect compromise in the first place), but you could possibly provide key rollover for your protocol.
Needless to say, using a static key makes it very vulnerable against side channel attacks on the implementation. Compare this for instance with a secure channel which needs to be reestablished using fresh session keys any time the MAC authentication tag is invalid. Those keys are probably invalidated before you can find out anything interesting about them.
answered yesterday
Maarten Bodewes♦
53.2k677192
AES - the block cipher - can be used to process a large amount of data. In that sense it is possible to keep a single static key. How much data is specified in this answer by Thomas on the Security.SE site: around $2^{64}$ blocks of data or 250 millions of terabytes.
If the use of AES with a static key is secure therefore depends not on the block cipher but how the block cipher is used: in other words, the protocol or protocols in which it is used. It may be insecure because the mode of operation introduces constraints that are voided by your protocol. It may not be secure because replay attacks are possible, oracles exist, the combination of cipher mode and MAC mode are vulnerable to attack, the list goes on...
AES does certainly leak information if the same input block is fed into it twice. If that's an issue depends - again - on the protocol. Your small algorithm could possibly be used to generate nonces so that the input to the AES cipher is always unique.
That using such a scheme can be relatively secure is shown by memory cards such as DESFire (which, funny enough, may also use AES). These cards are generally provided with one or more symmetric keys that are static during the lifetime of the product. Of course all the devices use derived keys that are tied to some unique identity of the card, otherwise extraction of one key would be enough to destroy the functionality of all of the cards.
Still, if the master key (from which the device keys are derived) is lost from which the other keys have been derived such schemes are certain to run into some form of trouble or another. It is very tricky to perform key management on static keys, and such schemes are fraught with danger. This is why asymmetric keys are commonly used with a PKI scheme to ensure validity. For such schemes the controlling device doesn't need to hold a master key.
Sometimes devices are also provided with multiple keys (for multiple master keys) in advance. That way the device may still be used with a new master key if one becomes compromised. Needless to say, invalidating a master key on the devices and moving to the next one is tricky at best (if you can detect compromise in the first place), but you could possibly provide key rollover for your protocol.
Needless to say, using a static key makes it very vulnerable against side channel attacks on the implementation. Compare this for instance with a secure channel which needs to be reestablished using fresh session keys any time the MAC authentication tag is invalid. Those keys are probably invalidated before you can find out anything interesting about them.
answered yesterday
Maarten Bodewes♦
53.2k677192
edited yesterday
answered yesterday
Maarten Bodewes♦
53.2k677192
answered yesterday
Maarten Bodewes♦
53.2k677192
answered yesterday
Maarten Bodewes♦
53.2k677192
53.2k677192
1
I'm still annoyed about the fact that some agencies require you to proof that an implementation is invulnerable to certain side channel attacks even if you've just made them impossible in your higher level protocol implementation. Of course, yes, tricky stuff as you must invalidate the keys in a timely fashon, but still...
– Maarten Bodewes♦
yesterday
1
The 256 exabytes is the point where you are going to be almost certain to have hit a collision. It isn't safe to get anywhere close to that amount. If you want to keep the probability of a collision to be less than 1 in $2^{64}$ you need to stay at less than 64 GB of data encrypted with the same AES key.
– kasperd
yesterday
Are you sure? We are talking about the block cipher right? Not any mode of operation. Half of 128 is 64 last time I checked.
– Maarten Bodewes♦
yesterday
Which mode of operation is used doesn't make a lot of difference as long as there aren't any vulnerabilities in the mode itself. There are modes where the probability of collisions is about the same as it would be with random inputs. There are modes which never use the same input, but that will cause the output to be distinguishable from random due to the lack of collisions in the output. The birthday limit tells us you'll need about $2^{n/2}$ blocks before the probability of a collision is 50%. But my point is that a 50% probability of a collision is a too high probability.
– kasperd
yesterday
1
I consider 1 in $2^{n/2}$ to be a reasonable probability of a collision to aim for. If you encrypt $m$ random blocks that gives you about $m^2$ pairs of blocks which could potentially collide. Each of those will have a probability of 1 in $2^n$ of colliding. $m^2$ pairs with a collision probability each of 1 in $2^n$ means the overall chance of a collision is about $frac{m^2}{2^n}$ which we want to be no more than $frac{1}{2^{n/2}}$. That means $m leq 2^{n/4}$.
– kasperd
yesterday
|
show 3 more comments
1
I'm still annoyed about the fact that some agencies require you to proof that an implementation is invulnerable to certain side channel attacks even if you've just made them impossible in your higher level protocol implementation. Of course, yes, tricky stuff as you must invalidate the keys in a timely fashon, but still...
– Maarten Bodewes♦
yesterday
1
The 256 exabytes is the point where you are going to be almost certain to have hit a collision. It isn't safe to get anywhere close to that amount. If you want to keep the probability of a collision to be less than 1 in $2^{64}$ you need to stay at less than 64 GB of data encrypted with the same AES key.
– kasperd
yesterday
Are you sure? We are talking about the block cipher right? Not any mode of operation. Half of 128 is 64 last time I checked.
– Maarten Bodewes♦
yesterday
Which mode of operation is used doesn't make a lot of difference as long as there aren't any vulnerabilities in the mode itself. There are modes where the probability of collisions is about the same as it would be with random inputs. There are modes which never use the same input, but that will cause the output to be distinguishable from random due to the lack of collisions in the output. The birthday limit tells us you'll need about $2^{n/2}$ blocks before the probability of a collision is 50%. But my point is that a 50% probability of a collision is a too high probability.
– kasperd
yesterday
1
I consider 1 in $2^{n/2}$ to be a reasonable probability of a collision to aim for. If you encrypt $m$ random blocks that gives you about $m^2$ pairs of blocks which could potentially collide. Each of those will have a probability of 1 in $2^n$ of colliding. $m^2$ pairs with a collision probability each of 1 in $2^n$ means the overall chance of a collision is about $frac{m^2}{2^n}$ which we want to be no more than $frac{1}{2^{n/2}}$. That means $m leq 2^{n/4}$.
– kasperd
yesterday
1
1
I'm still annoyed about the fact that some agencies require you to proof that an implementation is invulnerable to certain side channel attacks even if you've just made them impossible in your higher level protocol implementation. Of course, yes, tricky stuff as you must invalidate the keys in a timely fashon, but still...
– Maarten Bodewes♦
yesterday
I'm still annoyed about the fact that some agencies require you to proof that an implementation is invulnerable to certain side channel attacks even if you've just made them impossible in your higher level protocol implementation. Of course, yes, tricky stuff as you must invalidate the keys in a timely fashon, but still...
– Maarten Bodewes♦
yesterday
1
1
The 256 exabytes is the point where you are going to be almost certain to have hit a collision. It isn't safe to get anywhere close to that amount. If you want to keep the probability of a collision to be less than 1 in $2^{64}$ you need to stay at less than 64 GB of data encrypted with the same AES key.
– kasperd
yesterday
The 256 exabytes is the point where you are going to be almost certain to have hit a collision. It isn't safe to get anywhere close to that amount. If you want to keep the probability of a collision to be less than 1 in $2^{64}$ you need to stay at less than 64 GB of data encrypted with the same AES key.
– kasperd
yesterday
Are you sure? We are talking about the block cipher right? Not any mode of operation. Half of 128 is 64 last time I checked.
– Maarten Bodewes♦
yesterday
Are you sure? We are talking about the block cipher right? Not any mode of operation. Half of 128 is 64 last time I checked.
– Maarten Bodewes♦
yesterday
Which mode of operation is used doesn't make a lot of difference as long as there aren't any vulnerabilities in the mode itself. There are modes where the probability of collisions is about the same as it would be with random inputs. There are modes which never use the same input, but that will cause the output to be distinguishable from random due to the lack of collisions in the output. The birthday limit tells us you'll need about $2^{n/2}$ blocks before the probability of a collision is 50%. But my point is that a 50% probability of a collision is a too high probability.
– kasperd
yesterday
Which mode of operation is used doesn't make a lot of difference as long as there aren't any vulnerabilities in the mode itself. There are modes where the probability of collisions is about the same as it would be with random inputs. There are modes which never use the same input, but that will cause the output to be distinguishable from random due to the lack of collisions in the output. The birthday limit tells us you'll need about $2^{n/2}$ blocks before the probability of a collision is 50%. But my point is that a 50% probability of a collision is a too high probability.
– kasperd
yesterday
1
1
I consider 1 in $2^{n/2}$ to be a reasonable probability of a collision to aim for. If you encrypt $m$ random blocks that gives you about $m^2$ pairs of blocks which could potentially collide. Each of those will have a probability of 1 in $2^n$ of colliding. $m^2$ pairs with a collision probability each of 1 in $2^n$ means the overall chance of a collision is about $frac{m^2}{2^n}$ which we want to be no more than $frac{1}{2^{n/2}}$. That means $m leq 2^{n/4}$.
– kasperd
yesterday
I consider 1 in $2^{n/2}$ to be a reasonable probability of a collision to aim for. If you encrypt $m$ random blocks that gives you about $m^2$ pairs of blocks which could potentially collide. Each of those will have a probability of 1 in $2^n$ of colliding. $m^2$ pairs with a collision probability each of 1 in $2^n$ means the overall chance of a collision is about $frac{m^2}{2^n}$ which we want to be no more than $frac{1}{2^{n/2}}$. That means $m leq 2^{n/4}$.
– kasperd
yesterday
|
show 3 more comments
You can fix a public key to AES and use it as a random permutation. Now based on
a random permutation, you can construct an ideal cipher out of it (you might need more than one call to the random permutation). There might be efficiency loss, but it works and no AES-key scheduling is needed.Note that AES key scheduling is very similar to one round of AES encryption. See https://eprint.iacr.org/2015/751.pdf page 10.
answered yesterday
redplum
1976
add a comment |
You can fix a public key to AES and use it as a random permutation. Now based on
a random permutation, you can construct an ideal cipher out of it (you might need more than one call to the random permutation). There might be efficiency loss, but it works and no AES-key scheduling is needed.Note that AES key scheduling is very similar to one round of AES encryption. See https://eprint.iacr.org/2015/751.pdf page 10.
answered yesterday
redplum
1976
add a comment |
You can fix a public key to AES and use it as a random permutation. Now based on
a random permutation, you can construct an ideal cipher out of it (you might need more than one call to the random permutation). There might be efficiency loss, but it works and no AES-key scheduling is needed.Note that AES key scheduling is very similar to one round of AES encryption. See https://eprint.iacr.org/2015/751.pdf page 10.
answered yesterday
redplum
1976
You can fix a public key to AES and use it as a random permutation. Now based on
a random permutation, you can construct an ideal cipher out of it (you might need more than one call to the random permutation). There might be efficiency loss, but it works and no AES-key scheduling is needed.Note that AES key scheduling is very similar to one round of AES encryption. See https://eprint.iacr.org/2015/751.pdf page 10.
answered yesterday
redplum
1976
answered yesterday
redplum
1976
answered yesterday
redplum
1976
answered yesterday
redplum
1976
1976
add a comment |
add a comment |
kali007 is a new contributor. Be nice, and check out our Code of Conduct.
kali007 is a new contributor. Be nice, and check out our Code of Conduct.
kali007 is a new contributor. Be nice, and check out our Code of Conduct.
kali007 is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Cryptography Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f66259%2fcan-aes-be-used-with-a-static-key%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You should write more about your
smallalgorithm; what is the randomness source. and also, are there any hash algorithm around.– kelalaka
yesterday
Have you looked on LED cipher? It is AES-like , they use one key with round constants. It might help you
– hardyrama
yesterday
if you don’t use AES, you’ll have a lot more transistors for better security options. a feistel network cipher will serve you well
– b degnan
yesterday