OpenCores

OpenCores

Cryptographic hardware

no use

no use

1/1

no use

no use

Cryptographic hardware by Unknown on Dec 22, 2005			Not available!
Hi all, I am working on cryptographic hardware for almost an year now. I have implemented hash algorithms (MD5, SHA) and currently I am almost done implementing unified architectures for block cipher algorithms (DES, AES, Blowfish). I am looking for a challenging research internship, and the programs that I am applying to require me to give a proposal for a 'research idea'. Can anybody please help me out with some hot research ideas, frontiers in cryptographic hardware. Anything to do with security applications using FPGAs. Any pointers are most welcome. Thanks in advance. Abhilash -------------- next part -------------- An HTML attachment was scrubbed... URL: <A HREF="http://www.opencores.org/forums.cgi/cores/attachments/20051222/d9506610/attachment.htm">http://www.opencores.org/forums.cgi/cores/attachments/20051222/d9506610/attachment.htm</A> Hi all, I am working on cryptographic hardware for almost an year now. I have implemented hash algorithms (MD5, SHA) and currently I am almost done implementing unified architectures for block cipher algorithms (DES, AES, Blowfish). I am looking for a challenging research internship, and the programs that I am applying to require me to give a proposal for a 'research idea'. Can anybody please help me out with some hot research ideas, frontiers in cryptographic hardware. Anything to do with security applications using FPGAs. Any pointers are most welcome. Thanks in advance. Abhilash -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20051222/d9506610/attachment.htm

Cryptographic hardware by Unknown on Dec 22, 2005			Not available!
Abhilash Ravishankar schrieb: [q] Can anybody please help me out with some hot research ideas, frontiers in cryptographic hardware. Anything to do with security applications using FPGAs.[/q] A VoIP phone. You might be able to throw together an OpenRISC 1200, some analog stuff, ethernet controller and a crypto core for embedded encrypted telephony. Philipp Abhilash Ravishankar schrieb: Can anybody please help me out with some hot research ideas, frontiers in cryptographic hardware. Anything to do with security applications using FPGAs. A VoIP phone. You might be able to throw together an OpenRISC 1200, some analog stuff, ethernet controller and a crypto core for embedded encrypted telephony. Philipp

Cryptographic hardware by Unknown on Dec 23, 2005			Not available!
Describe a way to study a black box that is supposed to make a good AES (for example) encryption but how to be sure that : 1) the encryption is a good quality (key generation ?) 2) There is no "undocumented" feature Maybe it's impossible to do it. But maybe a kind of design could expose those internal in a certain manner that permit external observer to garantie what the hardware does. You could review software code and compile it. You can't do that with a chip. So for the "trust", some technic must be find. nicO Le jeudi 22 DÃ©cembre 2005 09:03, Abhilash Ravishankar a Ã©crit : [q] Hi all, I am working on cryptographic hardware for almost an year now. I have implemented hash algorithms (MD5, SHA) and currently I am almost done implementing unified architectures for block cipher algorithms (DES, AES, Blowfish). I am looking for a challenging research internship, and the programs that I am applying to require me to give a proposal for a 'research idea'. Can anybody please help me out with some hot research ideas, frontiers in cryptographic hardware. Anything to do with security applications using FPGAs. Any pointers are most welcome. Thanks in advance. Abhilash[/q] Describe a way to study a black box that is supposed to make a good AES (for example) encryption but how to be sure that : 1) the encryption is a good quality (key generation ?) 2) There is no "undocumented" feature Maybe it's impossible to do it. But maybe a kind of design could expose those internal in a certain manner that permit external observer to garantie what the hardware does. You could review software code and compile it. You can't do that with a chip. So for the "trust", some technic must be find. nicO Le jeudi 22 DÃ©cembre 2005 09:03, Abhilash Ravishankar a Ã©crit : Hi all, I am working on cryptographic hardware for almost an year now. I have implemented hash algorithms (MD5, SHA) and currently I am almost done implementing unified architectures for block cipher algorithms (DES, AES, Blowfish). I am looking for a challenging research internship, and the programs that I am applying to require me to give a proposal for a 'research idea'. Can anybody please help me out with some hot research ideas, frontiers in cryptographic hardware. Anything to do with security applications using FPGAs. Any pointers are most welcome. Thanks in advance. Abhilash

Cryptographic hardware by Unknown on Dec 23, 2005			Not available!
Abhilash Ravishankar wrote: [q] Hi all, I am working on cryptographic hardware for almost an year now. I have implemented hash algorithms (MD5, SHA) and currently I am almost done implementing unified architectures for block cipher algorithms (DES, AES, Blowfish). I am looking for a challenging research internship, and the programs that I am applying to require me to give a proposal for a 'research idea'. Can anybody please help me out with some hot research ideas, frontiers in cryptographic hardware. Anything to do with security applications using FPGAs. Any pointers are most welcome. Thanks in advance. Abhilash ------------------------------------------------------------------------ _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores</A> [/q] Not sure how long this research is going to be for. But I would suggest something to do with secure wireless networking if it is going to be a long one. You can encrypt data dynamically with different keys and algorithms based on a pre-defined sequence as well as switch channels used for the transmission dynamically. All the Best. Ranganathan Abhilash Ravishankar wrote: Hi all, I am working on cryptographic hardware for almost an year now. I have implemented hash algorithms (MD5, SHA) and currently I am almost done implementing unified architectures for block cipher algorithms (DES, AES, Blowfish). I am looking for a challenging research internship, and the programs that I am applying to require me to give a proposal for a 'research idea'. Can anybody please help me out with some hot research ideas, frontiers in cryptographic hardware. Anything to do with security applications using FPGAs. Any pointers are most welcome. Thanks in advance. Abhilash ------------------------------------------------------------------------ _______________________________________________ http://www.opencores.org/mailman/listinfo/cores Not sure how long this research is going to be for. But I would suggest something to do with secure wireless networking if it is going to be a long one. You can encrypt data dynamically with different keys and algorithms based on a pre-defined sequence as well as switch channels used for the transmission dynamically. All the Best. Ranganathan

Cryptographic hardware by Unknown on Jan 5, 2006			Not available!
On Friday 23 December 2005 08:16, Nicolas Boulay wrote: [q] Describe a way to study a black box that is supposed to make a good AES (for example) encryption but how to be sure that : 1) the encryption is a good quality (key generation ?) 2) There is no "undocumented" feature Maybe it's impossible to do it. But maybe a kind of design could expose those internal in a certain manner that permit external observer to garantie what the hardware does.[/q] I think this is by definition an impossible task if it's really a "black box". Given a "black box" takes inputs I and gives outputs O, given over time t: 1. There are an infinite number of (I,t) pairs. 2. Every possible sequence of inputs (I,ti) must be tested and compared against all possible outputs (O,to) where to >= ti. 3. It would take infinite time/space to test this. QED For example, what about black box that you suspect stores that last 1024 encryption keys used and spits them out instead of the normal expected encrypted data when a certain sequence of data is input? How can you prove that this is NOT the case? Only by testing every possible input sequence, or by breaking open the black box and checking some other way. If you're even slightly worried about it, it's better to not even think about using a black box. =) -- Wesley J. Landaker <<A HREF="http://www.opencores.org/mailman/listinfo/cores">wjl at icecavern.net</A>> <xmpp:<A HREF="http://www.opencores.org/mailman/listinfo/cores">wjl at icecavern.net</A>> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : <A HREF="http://www.opencores.org/forums.cgi/cores/attachments/20060105/0a5faef3/attachment.pgp">http://www.opencores.org/forums.cgi/cores/attachments/20060105/0a5faef3/attachment.pgp</A> On Friday 23 December 2005 08:16, Nicolas Boulay wrote: Describe a way to study a black box that is supposed to make a good AES (for example) encryption but how to be sure that : 1) the encryption is a good quality (key generation ?) 2) There is no "undocumented" feature Maybe it's impossible to do it. But maybe a kind of design could expose those internal in a certain manner that permit external observer to garantie what the hardware does. I think this is by definition an impossible task if it's really a "black box". Given a "black box" takes inputs I and gives outputs O, given over time t: 1. There are an infinite number of (I,t) pairs. 2. Every possible sequence of inputs (I,ti) must be tested and compared against all possible outputs (O,to) where to >= ti. 3. It would take infinite time/space to test this. QED For example, what about black box that you suspect stores that last 1024 encryption keys used and spits them out instead of the normal expected encrypted data when a certain sequence of data is input? How can you prove that this is NOT the case? Only by testing every possible input sequence, or by breaking open the black box and checking some other way. If you're even slightly worried about it, it's better to not even think about using a black box. =) -- Wesley J. Landaker wjl at icecavern.net> wjl at icecavern.net> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20060105/0a5faef3/attachment.pgp

Cryptographic hardware by thilo on Jan 14, 2006			thilo Posts: 3 Joined: Nov 19, 2009 Last seen: Apr 30, 2011
Wesley J. Landaker wrote: [q]On Friday 23 December 2005 08:16, Nicolas Boulay wrote: [q]Describe a way to study a black box that is supposed to make a good AES [/q] I'm curious what is not good? The only irrational bit there is the key generator, and that needs to come from a random source. So you would either need a good random generator, or an unpredictable pseudo random generator (nowadays called deterministic bit generator). If the key is generated (and confined) inside the black box, how would you be able to verify the output? [q](for example) encryption but how to be sure that : 1) the encryption is a good quality (key generation ?) [/q] -- make the key-generation extern to the black box. [q]2) There is no "undocumented" feature Maybe it's impossible to do it. But maybe a kind of design could expose those internal in a certain manner that permit external observer to garantie what the hardware does. [/q] I think this is by definition an impossible task if it's really a "black box". Given a "black box" takes inputs I and gives outputs O, given over time t: 1. There are an infinite number of (I,t) pairs. [/q] Wrong, i.e. a 256 bit aes (key-size) has exactly 2^256 different inputs and each input maps (by definition) to exactly one output I assume we are talking ecb mode. [q]2. Every possible sequence of inputs (I,ti) must be tested and compared [/q] Maybe, but in reality if the box passes the nist test-vectors, and if it's design is verified by an independant authority (e.g. nist) it can be trusted (gets expensive). [q]against all possible outputs (O,to) where to >= ti. 3. It would take infinite time/space to test this. QED For example, what about black box that you suspect stores that last 1024 encryption keys used and spits them out instead of the normal expected encrypted data when a certain sequence of data is input? How can you prove that this is NOT the case? Only by testing every possible input sequence, or by breaking open the black box and checking some other way. If you're even slightly worried about it, it's better to not even think about using a black box. =) [/q] Is that now theoretical or do we want to be pragmatic? thilo [q]------------------------------------------------------------------------ _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores</A> [/q] Wesley J. Landaker wrote: On Friday 23 December 2005 08:16, Nicolas Boulay wrote: Describe a way to study a black box that is supposed to make a good AES I'm curious what is not good? The only irrational bit there is the key generator, and that needs to come from a random source. So you would either need a good random generator, or an unpredictable pseudo random generator (nowadays called deterministic bit generator). If the key is generated (and confined) inside the black box, how would you be able to verify the output? (for example) encryption but how to be sure that : 1) the encryption is a good quality (key generation ?) -- make the key-generation extern to the black box. 2) There is no "undocumented" feature Maybe it's impossible to do it. But maybe a kind of design could expose those internal in a certain manner that permit external observer to garantie what the hardware does. I think this is by definition an impossible task if it's really a "black box". Given a "black box" takes inputs I and gives outputs O, given over time t: 1. There are an infinite number of (I,t) pairs. Wrong, i.e. a 256 bit aes (key-size) has exactly 2^256 different inputs and each input maps (by definition) to exactly one output I assume we are talking ecb mode. 2. Every possible sequence of inputs (I,ti) must be tested and compared Maybe, but in reality if the box passes the nist test-vectors, and if it's design is verified by an independant authority (e.g. nist) it can be trusted (gets expensive). against all possible outputs (O,to) where to >= ti. 3. It would take infinite time/space to test this. QED For example, what about black box that you suspect stores that last 1024 encryption keys used and spits them out instead of the normal expected encrypted data when a certain sequence of data is input? How can you prove that this is NOT the case? Only by testing every possible input sequence, or by breaking open the black box and checking some other way. If you're even slightly worried about it, it's better to not even think about using a black box. =) Is that now theoretical or do we want to be pragmatic? thilo ------------------------------------------------------------------------ _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

Cryptographic hardware by Unknown on Jan 14, 2006			Not available!
On Friday 13 January 2006 23:25, thilo wrote: [q] Wesley J. Landaker wrote: [q]>1. There are an infinite number of (I,t) pairs.[/q] Wrong, i.e. a 256 bit aes (key-size) has exactly 2^256 different inputs and each input maps (by definition) to exactly one output I assume we are talking ecb mode.[/q] Sure, if it's actually 256-bit AES, with no added features, backdoors, bugs, etc. But we're talking about a black-box. You can't assume anything about a black-box, even if someone says, "oh yeah, it's AES". Now, if you're talking about AES code that you can examine and you just want to test it to make sure it doesn't have BUGS. Then this whole thread is moot, since that's not a black-box. =) Also, if you're talking about a black-box that doesn't do encrpytion, but just generates keys--well, you can always check the output before using it, but then, what's the point of having the black-box? You still couldn't test every possible output to make sure it always generates a good key. [q]>2. Every possible sequence of inputs (I,ti) must be tested and compared[/q] Maybe, but in reality if the box passes the nist test-vectors, and if it's design is verified by an independant authority (e.g. nist) it can be trusted (gets expensive).[/q] Granted, if it's design is verified--so it's no longer a black-box--then sure, you can have trust in it that's as good as the verification. But no amount of verification or testing of a black-box can or will ever give any real confidence in it's future behavior. [q]>For example, what about black box that you suspect stores that last 1024 >encryption keys used and spits them out instead of the normal expected >encrypted data when a certain sequence of data is input? How can you > prove that this is NOT the case? Only by testing every possible input > sequence, or by breaking open the black box and checking some other > way. > >If you're even slightly worried about it, it's better to not even think >about using a black box. =)[/q] Is that now theoretical or do we want to be pragmatic?[/q] No, that's not theoretical, that's a simple backdoor that would be very easy to add to almost any security product; not only that, but this, and much more complecated schemes have been done many times in the past, and will continue to be done in the future by various parties for whatever nefarious purpose. Now, remember, the OP mentioned black-boxes. I'm talking about black-boxes. If you're talking about something ELSE, then my comments obviously don't apply directly. =) -- Wesley J. Landaker <<A HREF="http://www.opencores.org/mailman/listinfo/cores">wjl at icecavern.net</A>> <xmpp:<A HREF="http://www.opencores.org/mailman/listinfo/cores">wjl at icecavern.net</A>> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : <A HREF="http://www.opencores.org/forums.cgi/cores/attachments/20060114/2f2b9945/attachment.pgp">http://www.opencores.org/forums.cgi/cores/attachments/20060114/2f2b9945/attachment.pgp</A> On Friday 13 January 2006 23:25, thilo wrote: Wesley J. Landaker wrote: >1. There are an infinite number of (I,t) pairs. Wrong, i.e. a 256 bit aes (key-size) has exactly 2^256 different inputs and each input maps (by definition) to exactly one output I assume we are talking ecb mode. Sure, if it's actually 256-bit AES, with no added features, backdoors, bugs, etc. But we're talking about a black-box. You can't assume anything about a black-box, even if someone says, "oh yeah, it's AES". Now, if you're talking about AES code that you can examine and you just want to test it to make sure it doesn't have BUGS. Then this whole thread is moot, since that's not a black-box. =) Also, if you're talking about a black-box that doesn't do encrpytion, but just generates keys--well, you can always check the output before using it, but then, what's the point of having the black-box? You still couldn't test every possible output to make sure it always generates a good key. >2. Every possible sequence of inputs (I,ti) must be tested and compared Maybe, but in reality if the box passes the nist test-vectors, and if it's design is verified by an independant authority (e.g. nist) it can be trusted (gets expensive). Granted, if it's design is verified--so it's no longer a black-box--then sure, you can have trust in it that's as good as the verification. But no amount of verification or testing of a black-box can or will ever give any real confidence in it's future behavior. >For example, what about black box that you suspect stores that last 1024 >encryption keys used and spits them out instead of the normal expected >encrypted data when a certain sequence of data is input? How can you > prove that this is NOT the case? Only by testing every possible input > sequence, or by breaking open the black box and checking some other > way. > >If you're even slightly worried about it, it's better to not even think >about using a black box. =) Is that now theoretical or do we want to be pragmatic? No, that's not theoretical, that's a simple backdoor that would be very easy to add to almost any security product; not only that, but this, and much more complecated schemes have been done many times in the past, and will continue to be done in the future by various parties for whatever nefarious purpose. Now, remember, the OP mentioned black-boxes. I'm talking about black-boxes. If you're talking about something ELSE, then my comments obviously don't apply directly. =) -- Wesley J. Landaker wjl at icecavern.net> wjl at icecavern.net> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20060114/2f2b9945/attachment.pgp

no use

no use

1/1

no use

no use

© copyright 1999-2026 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.