 |
|
| Science Forum Index » Cryptography Forum » Need for speedy cryptography... |
|
Page 1 of 1 |
|
| Author |
Message |
| Rob Blank... |
 Posted: Sun Oct 18, 2009 5:33 am |
|
|
|
Guest
|
Hi all,
I am just about to hack some text together for my MSc thesis. I am just
trying to motivate the need for "high"-performance implementations of
cryptographic systems. Obviously, one good point to mention here is the
impatient user: No one is happy when they have to wait for 15 seconds
until a RSA decryption has been computed on their mobiles.
However, I assume there is also a technical motivation for this problem.
I could image, for instance, that in networks routers need a certain
throughput; that means, if the packets are encrypted, we need fast
decryption routines in order to meet throughput. Maybe there are other
examples in audio or video applications that need high-speed crypto
engines to meet performance targets.
I will google for more information about this, but maybe someone knows
a good articel or source that could be helpful to start my research in
this direction.
Thanks,
Rob |
|
|
| Back to top |
|
|
|
| Le Chaud Lapin... |
| Posted: Sun Oct 18, 2009 6:17 am |
|
|
|
Guest
|
On Oct 18, 9:05 am, n... at (no spam) dont-mail-me.com (Robert Scott) wrote:
[quote:52caf7f6e2]On Sun, 18 Oct 2009 12:33:30 +0100, Rob Blank <Rob.Bl... at (no spam) gmx.de> wrote:
Hi all,
However, I assume there is also a technical motivation for this problem.
I could image, for instance, that in networks routers need a certain
throughput; that means, if the packets are encrypted, we need fast
decryption routines in order to meet throughput. Maybe there are other
examples in audio or video applications that need high-speed crypto
engines to meet performance targets.
[/quote:52caf7f6e2]
As I understand it, if the end-to-end model is to persist, then there
is no need for routers, or at least the routing feature of routers, to
encrypt/decrypt packets in transit.
[quote:52caf7f6e2]I will google for more information about this, but maybe someone knows
a good articel or source that could be helpful to start my research in
this direction.
First you need to make the distinction between symmetric and public key
technologies. The public key systems (like the RSA you mentioned) do take
considerably longer to compute. However they are used in contexts where
throughput speed is not that important. Symmetric algorithms are usually used
for bulk encryption. I think any discussion of encryption speed must take
applications into account from the very beginning.
[/quote:52caf7f6e2]
One might imagine a steady-state, semi-terminal model for computer
networking, where a PDA moves at 100km/hr, acting as a DNS server for
mobile cameras that are 10,000km away, while also receiving secure
multicast video streams as one of 1,000,000 multicast target devices,
all dispersed across the planet, each maintaining topologically
optimal paths most of the time, with new connections established and
broken with these mobile devices by other devices, anywhere, including
stationary and mobile devices, over unsecure links whenever and
wherever they become available, using generic hardware purchased from
local electronics store, with easy access control throughout entire
system, managed by computer neophytes.
IMHO, there are four fundamental problems that prevent us from
realizing this model:
1. ***
2. ***
3. ***
4. Fast forward stateless signing of individual packets.
#4 stipulates that the only information allowed by target is the
public key of source, at instant where very first packet arrives from
source. Each packet signing must be independent of preceeding packet
signings.
This idependence of signing, IMO, is ideal, but obviously a
performance nightmare, so one has to wonder what remains unexplored in
realm of fast modular reduction.
Performance notwithstanding, I think network researchers are still
trying to discover the model to make this feasible, but when they do,
I think they will discover that #4 is a necessity, not a luxury.
In the meantime, we are left more or less with what we have now:
Heavy-handed management of one-sided public/private key-pair with
hardware-assisted encryption/decryption and no secure mobility or
large-scale secure multicast.
-Le Chaud Lapin- |
|
|
| Back to top |
|
|
|
| Robert Scott... |
| Posted: Sun Oct 18, 2009 8:05 am |
|
|
|
Guest
|
On Sun, 18 Oct 2009 12:33:30 +0100, Rob Blank <Rob.Blank at (no spam) gmx.de> wrote:
[quote:ce3ecb991b]Hi all,
I am just about to hack some text together for my MSc thesis. I am just
trying to motivate the need for "high"-performance implementations of
cryptographic systems. Obviously, one good point to mention here is the
impatient user: No one is happy when they have to wait for 15 seconds
until a RSA decryption has been computed on their mobiles.
However, I assume there is also a technical motivation for this problem.
I could image, for instance, that in networks routers need a certain
throughput; that means, if the packets are encrypted, we need fast
decryption routines in order to meet throughput. Maybe there are other
examples in audio or video applications that need high-speed crypto
engines to meet performance targets.
I will google for more information about this, but maybe someone knows
a good articel or source that could be helpful to start my research in
this direction.
[/quote:ce3ecb991b]
First you need to make the distinction between symmetric and public key
technologies. The public key systems (like the RSA you mentioned) do take
considerably longer to compute. However they are used in contexts where
throughput speed is not that important. Symmetric algorithms are usually used
for bulk encryption. I think any discussion of encryption speed must take
applications into account from the very beginning.
Bob Scott, Michigan |
|
|
| Back to top |
|
|
|
| Paul Rubin... |
| Posted: Sun Oct 18, 2009 10:39 am |
|
|
|
Guest
|
Rob Blank <Rob.Blank at (no spam) gmx.de> writes:
[quote:f5b7d136f7]I am just about to hack some text together for my MSc thesis. I am
just trying to motivate the need for "high"-performance
implementations of cryptographic systems. Obviously, one good point
to mention here is the impatient user: No one is happy when they
have to wait for 15 seconds until a RSA decryption has been computed
on their mobiles.
[/quote:f5b7d136f7]
http://cr.yp.to/highspeed.html |
|
|
| Back to top |
|
|
|
| Unruh... |
| Posted: Sun Oct 18, 2009 11:03 am |
|
|
|
Guest
|
Rob Blank <Rob.Blank at (no spam) gmx.de> writes:
[quote:4f15d9bc3c]Hi all,
I am just about to hack some text together for my MSc thesis. I am just
[/quote:4f15d9bc3c]
Before you hack together some text, perhaps you should do some research ( more
than just asking a question on a newsgroup).
[quote:4f15d9bc3c]trying to motivate the need for "high"-performance implementations of
cryptographic systems. Obviously, one good point to mention here is the
impatient user: No one is happy when they have to wait for 15 seconds
until a RSA decryption has been computed on their mobiles.
[/quote:4f15d9bc3c]
Whic is why noone uses rsa for anything but the exchange of keys for some regular,
fast private key encryption system.
[quote:4f15d9bc3c]However, I assume there is also a technical motivation for this problem.
I could image, for instance, that in networks routers need a certain
throughput; that means, if the packets are encrypted, we need fast
decryption routines in order to meet throughput. Maybe there are other
[/quote:4f15d9bc3c]
Why would the router decrypt the packet?
[quote:4f15d9bc3c]examples in audio or video applications that need high-speed crypto
engines to meet performance targets.
I will google for more information about this, but maybe someone knows
a good articel or source that could be helpful to start my research in
this direction.
Thanks,
Rob[/quote:4f15d9bc3c] |
|
|
| Back to top |
|
|
|
| Joseph Ashwood... |
| Posted: Sun Oct 18, 2009 12:36 pm |
|
|
|
Guest
|
"Rob Blank" <Rob.Blank at (no spam) gmx.de> wrote in message
news:hbeudi$7c2$1 at (no spam) aioe.org...
[quote:deae447061]I am just about to hack some text together for my MSc thesis. I am just
trying to motivate the need for "high"-performance implementations of
cryptographic systems.
[/quote:deae447061]
The best short reason is monetary. An algorithm that is k time faster is k
times less expensive to run. When dealing with large scale implementations
the savings are significant.
Joe |
|
|
| Back to top |
|
|
|
| Anne & Lynn Wheeler... |
| Posted: Sun Oct 18, 2009 1:29 pm |
|
|
|
Guest
|
Rob Blank <Rob.Blank at (no spam) gmx.de> writes:
[quote:bf4b2104c8]I am just about to hack some text together for my MSc thesis. I am
just trying to motivate the need for "high"-performance
implementations of cryptographic systems. Obviously, one good point to
mention here is the impatient user: No one is happy when they have to
wait for 15 seconds until a RSA decryption has been computed on their
mobiles.
[/quote:bf4b2104c8]
in the mid-90s, the x9a10 financial standard working group had been
given the requirement to preserve the integrity of the financial
infrastructure for all retail payments (aka *ALL*, debit, credit,
stored-value, ACH, point-of-sale, attended, unattended, high-value,
low-value, internet, transit turnstyle, i.e. *ALL*). Things started to
converge on ECDSA.
one of the issues in mid-90s were that transit turnstyle have extremely
tight power and elapsed time requirements for contactless card operation
(small fraction of second, RF power being near the reader).
RSA solutions for chipcard operation had added large number of circuits
(for crypto accelerator) to cut the elapsed time of the operation to few
seconds (still way too long for transit application) ... but the huge
increase in circuits also greatly increased the power draw for those few
seconds ... resulting in a contact requirement. ECDSA could be done w/o
the power, extra circuits, and/or elapsed time penalty of RSA.
the standard solution also did a public key paradigm w/o digital
certificates. some of the other public key payment specification efforts
from the period were looking at taking the standard digital certificate
approach (with RSA). The issue with those approaches was that the
digital certificate paradigm added a factor of approx. one hundred times
payload bloat to typical payment transaction message (RSA plus digital
certificate paradigm resulted in 100 times processing bloat and 100
times payload bloat to typical payment transaction).
some part of the standards group looked at coming up with a standard for
"compressed" digital certificates (looking to help with the humongous
100 times payment transaction payload bloat problem) ... trying to get
it down to only an enormous 10 times payment transaction payload bloat
problem. I was able to show with their techniques it was possible to
compress a digital certificate to zero bytes ... putting the appended
digital certificate paradigm on level playing field with certificateless
paradigm.
possibly part of the motivation for RSA on chipcards in the late 80s and
early 90s was the DSA requirement for a trusted secret random number
source ... but that changed starting in the mid-90s ... being able to
get high integrity random number in low-power, extremely fast (at least
if talking about ECC) and very inexpensive chips.
one of the issues regarding chip cost (even security chips ... say
infineon from the dresdon fab) is that in quanitity, it approaches fixed
cost per wafer. cost per chip then becomes number of chips per wafer.
Holding the number of circuits constant ... the transition from 200mm to
300mm wafers and declining circuit size resulted in enormous increase in
chips/wafer. for awhile, this was stalled (for smaller chips) with the
technology used to cut chips from wafers (cut swath area starting to
exceed aggregate chip area in wafer). Somewhat the market forces related
to EPC RFID chips (i.e. inexpensive chips targeted at replacing barcodes
for grocery items) developed new wafer cutting technology that
drastically reduced the cut swath area. An inexpensive, contactless,
fast, low-power semi-custom design, security chip was done in a few
hundred thousand circuits (well under a dollar given chips/wafer
.... compare that with typical current generation of processor chips with
three orders of magnitude more circuits ... or more). A rough design at
a fully custom chip, reduced the circuits/chip by a factor of ten times
(roughly increasing the chips/wafer by another factor of ten).
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970 |
|
|
| Back to top |
|
|
|
| Scott Contini... |
| Posted: Sun Oct 18, 2009 1:41 pm |
|
|
|
Guest
|
On Oct 18, 10:33 pm, Rob Blank <Rob.Bl... at (no spam) gmx.de> wrote:
[quote:1b1fe32b73]Hi all,
I am just about to hack some text together for my MSc thesis. I am just
trying to motivate the need for "high"-performance implementations of
cryptographic systems. Obviously, one good point to mention here is the
impatient user: No one is happy when they have to wait for 15 seconds
until a RSA decryption has been computed on their mobiles.
However, I assume there is also a technical motivation for this problem.
I could image, for instance, that in networks routers need a certain
throughput; that means, if the packets are encrypted, we need fast
decryption routines in order to meet throughput. Maybe there are other
examples in audio or video applications that need high-speed crypto
engines to meet performance targets.
[/quote:1b1fe32b73]
Constrained environments one important motivation.
NTRU specializes in providing crypto for such
environments, see:
http://www.ntru.com/cryptolab/pdf/ntruches2001.pdf
(and other places on the NTRU website). You might
search Certicom's website as well.
Scott |
|
|
| Back to top |
|
|
|
| CatId... |
| Posted: Sun Oct 18, 2009 5:45 pm |
|
|
|
Guest
|
For a network server you don't want to be spending all of your time
handling new connections. The server is supposed to be doing actual
work! =)
Low power devices as you mention is another good reason...
The faster your implementation is, the more secure you can make it
without aggravating your users! So instead of just doing the industry
concentual bare minimum you can build in more protection.
Also, efficient code tends to be shared and re-used more.
http://catid.org
--
--------------------------------- --- -- -
Posted with NewsLeecher v3.95 Beta 3
Web at (no spam) http://www.newsleecher.com/?usenet
------------------- ----- ---- -- - |
|
|
| Back to top |
|
|
|
| Nelson Bolyard... |
| Posted: Mon Oct 19, 2009 10:23 pm |
|
|
|
Guest
|
On 2009-10-18 04:33 PDT, Rob Blank wrote:
[quote]Hi all,
I am just about to hack some text together for my MSc thesis. I am just
trying to motivate the need for "high"-performance implementations of
cryptographic systems.
[/quote]
Google for HDCP |
|
|
| Back to top |
|
|
|
| amzoti... |
| Posted: Thu Oct 22, 2009 5:17 am |
|
|
|
Guest
|
On Oct 18, 4:33 am, Rob Blank <Rob.Bl... at (no spam) gmx.de> wrote:
[quote]Hi all,
I am just about to hack some text together for my MSc thesis. I am just
trying to motivate the need for "high"-performance implementations of
cryptographic systems. Obviously, one good point to mention here is the
impatient user: No one is happy when they have to wait for 15 seconds
until a RSA decryption has been computed on their mobiles.
However, I assume there is also a technical motivation for this problem.
I could image, for instance, that in networks routers need a certain
throughput; that means, if the packets are encrypted, we need fast
decryption routines in order to meet throughput. Maybe there are other
examples in audio or video applications that need high-speed crypto
engines to meet performance targets.
I will google for more information about this, but maybe someone knows
a good articel or source that could be helpful to start my research in
this direction.
Thanks,
Rob
[/quote]
Look up VoIP and how it is impacted by too much delay.
Also look up the protocol TCP (versus UDP - but TCP is the king of the
internet) and how it is impacted on satellite links with the need of a
Performance Enhancing Proxy (PEP).
With smaller devices, look up SWap (size-weight-and-power) - you only
got so much horsepower and need to use it wisely. |
|
|
| Back to top |
|
|
|
|
|
All times are GMT - 5 Hours
The time now is Mon Dec 14, 2009 8:23 pm
|
|