UPONUS, CIFF AND CRYPTOLOGICA COMPARISON
An UPONUS report prepared by “certain independent third-party testing, as well as internal
company testing” is based on a completely wrong measurement methodology, which I will describe
in detail below. Let’s start from the first claim:
1.
“Virtually no latency in using SASE (encryption technology without compression) to send
encrypted files or encrypt streaming data for on-the-fly communication.”
Instead of simply measuring actual encryption and decryption time, which can be easily and
accurately performed by adding beginning and end time stamps in SASE encryption and decryption
source code (which they already changed for the measurement), they first transmit data without an
encryption and a decryption between two computers, and then transmit data with an encryption and
a decryption between two computers, claiming that the (averaged) difference between the second
and the first measurements corresponds to time required to perform an encryption and a decryption.
This methodology can be completely wrong in case that software uses buffering and TCP/IP
transmission, as in UPONUS test, thus producing a latency even in case without an encryption and a
decryption, which after a subtraction from the case with an encryption and a decryption gives wrong
result of lower latency encryption and decryption. In other words, with simple programming trick
you can get exactly zero time or even negative time as a result, thus claiming that an encryption and
a decryption actually accelerates the transmission, which is impossible!
To make methodology even worse, “the application was modified to only read one block of
data from a file and used that block multiple times.” This approach provides false sense of an
encryption and a decryption speed, since data are read from and written into the processor cache,
which is not appropriate to real-life scenario.
Therefore, all measurements disclosed in tables 1-1, 1-2 and 1-3 are useless since they do
not correspond to any real performance, which is obvious from NEGATIVE difference numbers in
Table 1-3 showing that encrypted transmission is FASTER than unencrypted transmission!
2.
In next round of tests, they get rid of a transmission latency, since “this test was conducted
on a single laptop using the loopback address “127.0.0.1”...” Windows operating system behavior
significantly affects this type of measurement, because it schedules processes on the same laptop. If
the server process (decrypting data) is called before the client process (encrypting data) on the same
laptop, the latency will be low for any encryption and decryption method, which again does not
correspond to reality.
Therefore, all measurements disclosed in tables 1-4, 1-5 and 1-6 are useless since they do
not correspond to any real transmission due to the loopback address 127.0.0.1, which anybody can
witness using Windows Task Manager, Networking Tab, showing zero Network Utilization under
these conditions.
Furthermore, no block size was given, so we can assume that it is appropriate to the file
length divided by the count, which gives approximately 4KB block size.
Last but not least, the UPONUS report has also completely wrong conclusion that “it is
expected that this (64-bit SASE) version running on a 64-bit processor would be eight times faster
than the 8-bit version.” Computing experts know that speed of 64-bit software does not correspond
to the linear function of a number of bits.
1
3.
“Other third-party SASE speed tests show low resource utilization and speed of up to 25
MB/s using the 3-round variant version, and 15 MB/s with the 11-round variant version of SASE
using a 2.2 GHz processor with 2GB of RAM on a Windows based machine.” “Tested key sizes
were: 32B (256-bit), 64B (512-bit), 512B (4096-bit) and 1,024B (8192-bit).”
For more details about UPONUS algorithms, you can download U.S. patent No.
7,382,878B2 and U.S. patent application No. 2003016820, which disclose a block cipher in a
stream mode combined with a lossless compression:
http://home.etf.rs/~proka/CRYPTO/US7382878B2.pdf
http://home.etf.rs/~proka/CRYPTO/US2003016820A1.pdf
256-bit key AES encryption method in CTR mode, which is much more secure than ECB
and CBC modes mentioned in the UPONUS report, encrypts or decrypts data with a speed of 70
MB/s using a single core of 2.66 GHz processor with 2GB of RAM and Windows operating system.
1920x1080x30fps HD CIFF compression, streaming and decompression with 256-bit key
AES encryption method in GCM-AEAD mode (IP-packet mode with authentication), which is
recommended for top secret government data, has negligible total latency of 1 frame (0.033 s) for
CIFF encoder plus CIFF decoder, while additional latency due to 256-bit AES-GCM-AEAD is
undetectable, i.e. below the measurement error.
This can be easily proven by compressing video file with incremented frame numbers and
displaying these numbers before CIFF compression and 256-bit AES-GCM-AEAD encryption on
the first PC and comparing these numbers with the received numbers displayed after 256-bit AESGCM-AEAD decryption and CIFF decompression on the second PC.
4096-bit key CRYPTO LOGICA encryption technology without any optimization and
without any multithreading support encrypts or decrypts data with a speed between 142 MB/s and
569 MB/s using a single core of 2.66 GHz processor with 2GB of RAM and Windows operating
system, which is several times faster than 256-bit AES and order of magnitude faster than SASE:
http://home.etf.rs/~proka/CRYPTO/CRYPTOLOGICA16MB.ppt
TYPE
B
B
B
B
H
H
S
ENCRYPTION METHOD
KEY LENGTH [bits] BLOCK
[bits]
SHORT
LONG
MIN
MAX
SBC
Short Block Cipher
256
2048
128
LBC
Long Block Cipher
512
4096
256
UBC
Ultimate Block Cipher
384
2048
256
UBE
UBC Extended
768
4096
256
SHC
Short Hybrid Cipher
256
2048
128
HES
Hybrid Encryption Solution
384
2048
256
STE
Stream Extended Cipher
2048
2048
∞
Therefore, the combination of CIFF and CRYPTO LOGICA will provide even better results
than the combination of CIFF and AES-GCM-AEAD, which are already significantly better WAKit,
CleanColor and SASE.
2
T
Y
ALGORITHM OWNER
P
E
B AES (Ref)
PUBLIC
KEY
LENGTH
[bits]
BLOCK
SIZE
[bits]
ENC/DEC
SPEED
[Mbit/s]
ALG SPEED
AES SPEED
256
128
73
1
B
B
B
B
B
B
AES CTR
SASE-11
SASE-3
SBC
LBC
UBC
PUBLIC
UPONUS
UPONUS
CRYPTO LOGICA
CRYPTO LOGICA
CRYPTO LOGICA
256
256..8192
256..8192
2048
4096
2048
128
?
?
128
256
256
70
15
25
178
205
213
0.96
B
H
H
H
S
UBE
SHC
HES 1024
HES 2048
STE
CRYPTO LOGICA
CRYPTO LOGICA
CRYPTO LOGICA
CRYPTO LOGICA
CRYPTO LOGICA
4096
2048
1024
2048
4096
256
128
256
256
4096
142
152
341
179
569
1.95
2.09
4.68
2.45
7.79
0.21
0.34
2.44
2.81
2.92
4.
“Strength of SASE Encryption” was tested using Diehard Randomness Test, while strength
of CRYPTO LOGICA methods was tested using much more comprehensive NIST STS 2.1 tests:
http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html
5.
WAKit - mathematically lossless compression does not make sense for already losslessly or
lossy compressed video (such as .mpg and .wmv files used during measurement), since most of
redundancy was already removed by previous compression process, so there is practically nothing
that can be further compressed.
That’s why the UPONUS report measured only an encryption and not a compression on
already compressed files (page 3). On the other hand, CIFF can further compress already
compressed files in order to decrease their size or decrease necessary bitrate for their transmission
or decrease transmission time.
CIFF can compress very noisy 252MB declassified 9506x9294x24bpp Bae BMP image with
the following compression ratios on a single CPU core:
No.
1
2
3
4
5
Compression type
mathematically lossless
visually lossless
visually lossless
very good quality
good quality
Compression Ratio
2.28:1
11.88:1
27.83:1
62.63:1
143.51:1
3
Compression [s]
10.18
5.76
4.17
2.91
2.09
Decompression [s]
10.87
6.05
4.07
2.84
1.92
CIFF and WinZip WZZIP / WZUNZIP results on various BMP images are:
BMP
image
size
[kB]
Anemone
988
Baboon
769
Bae
258,853
City
74,807
Bike
15,361
Coffee
9,113
Connery
9,217
Dew
6,076
Formula1
704
Happy
15,398
Hats
1,153
Island
1,153
Lena
769
Monarch
1,153
Panorama 59,261
Peppers
769
Sail
1,153
Tulips
1,153
Woman
15,361
BMP
No. image
name
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Compression [s]
Decompression [s]
CIFF
0.04
0.04
10.26
2.92
0.65
0.32
0.39
0.24
0.03
0.59
0.05
0.05
0.04
0.05
2.63
0.03
0.05
0.05
0.63
CIFF WZUNZIP
0.05
0.07
0.04
0.06
10.80
16.92
2.97
4.93
0.69
1.17
0.35
0.53
0.41
0.60
0.26
0.41
0.03
0.04
0.64
0.89
0.05
0.07
0.05
0.07
0.04
0.06
0.05
0.07
2.68
4.03
0.04
0.05
0.05
0.07
0.05
0.07
0.67
0.99
WZZIP
0.08
0.07
18.07
5.12
1.25
0.58
0.61
0.43
0.05
0.95
0.08
0.08
0.07
0.08
4.21
0.07
0.08
0.08
1.05
Relative compressed
file size / BMP image
size
CIFF
ZIP
0.63087
0.91817
0.78013
0.95432
0.43813
0.80285
0.42744
0.54761
0.53760
0.67942
0.31380
0.64995
0.50675
0.80888
0.44583
0.76560
0.35042
0.54325
0.40056
0.62744
0.39451
0.48895
0.40705
0.50162
0.58881
0.93294
0.42076
0.71973
0.57654
0.82620
0.47323
0.86254
0.48129
0.80768
0.45682
0.85180
0.50918
0.73586
NOTICE: Smaller compression and decompression time are better.
Smaller relative compressed file size is better.
CIFF provides SIGNIFICANTLY SMALLER lossless compressed file size than ZIP with
significantly shorter compression and decompression time even without using multiple cores and
multithreading support, since all aforementioned measurements have been done for a single core
and single thread CIFF.
On the other hand, WAKit provides NEGLIGIBLE SMALLER lossless compressed file size
than ZIP with significantly shorter compression time, according to Table 2 in the UPONUS report.
Furthermore, CIFF is faster than WAKit according to the last table in the UPONUS report,
since CIFF can mathematically lossless compress 74MB file in less than 3 s, while WAKit requires
6 s. CIFF can mathematically lossless compress 15MB file in 0.6 s, while WAKit requires 1 s, etc.
6.
CleanColor - visually lossless compression also does not make sense for already lossy
compressed video (such as .mpg and .wmv files used during measurement), since almost all
redundancy was already removed by previous compression process, so there is practically nothing
that can be further compressed.
That’s why the UPONUS report didn’t cover CleanColor compression of already
compressed files.
4
7.
Predictor - the modification of WAKit, which is also not covered by the UPONUS report. I
would not comment on a speculative estimation of performance provided in the UPONUS report,
which is always worse than readily available CIFF performance.
CONCLUSIONS
In a nutshell, as a conclusion, it is obvious that:
a)
SASE provides much slower encryption speed than AES-GCM-AEAD and AES-CTR,
while CRYPTO LOGICA is several times faster than AES in any mode and order of magnitude
faster than SASE, with other advantages emphasized in bold numbers.
No.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Features
Brutal force security
Linear cryptoanalysis security
Differential cryptoanalysis security
Security against computing development
Security against weak keys
Security against zero key
Security against similar keys
Family of customized algorithms
Adjustable parameters in algorithms
Parameter change by the user
Unknown algorithm for unauthorized
Key generator
Latency (cipher + decipher)
Cipher (encrypting) speed
Decipher (decrypting) speed
Processing throughput required
Power consumption
Heat dissipation
Memory size
Memory bandwidth
Weight of supporting hardware
Size of supporting hardware
Cost of supporting hardware
Integer arithmetic
CRYPTO LOGICA
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
LOW
HIGH
HIGH
LOW
LOW
LOW
LOW
LOW
LOW
LOW
LOW
YES
SASE
YES
YES
YES
YES
YES
YES
YES
NO
NO
NO
NO
NO
LOW
LOW
LOW
HIGH
HIGH
HIGH
MEDIUM
HIGH
HIGH
HIGH
HIGH
YES
b)
WAKit provides twice faster mathematically lossless compression with similar compression
ratio (similar compressed file size) in comparison with ZIP method, while CIFF provides twice
faster mathematically lossless compression than WAKit with much better compression ratio
(smaller compressed file size) in comparison with ZIP method, using single core and single thread
during compression and decompression of still images. In case of video, CIFF is proportionally
faster due to the utilization of multiple cores and multithreading.
c)
In addition to mathematically lossless compression, CIFF provides visually lossless (up to
30:1) and lossy compression up to 4,000:1, which is unattainable by WAKit, even with CleanColor
and Predictor modifications, and even with UPONUS speculative estimations.
d)
Furthermore, CIFF has many features described in white papers in detail, which are
completely unattainable by WAKit, even with CleanColor and Predictor modifications:
5
http://home.etf.rs/~proka/CIFF_Overview.pdf
e)
As a conclusion, CIFF is future proof but available today compression and decompression
method which besides quality for a given bitrate provides the complete set of features while
supporting any resolution now and in the future.
No.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Features
Mathematically lossless compression
Visually lossless compression (up to 6:1)
Visually lossless compression (up to 30:1)
Medium lossy compression (up to 400:1)
Very lossy compression (up to 4,000:1)
I-frame codec
IP-frame codec
Maximum I-frame compression ratio
Estimated I-frame compression ratio
Maximum IP-frame compression ratio
Estimated IP-frame compression ratio
Transcoding of already compressed data
Spatial (resolution) scalability
Quality (processing reduction) scalability
Temporal (frame dropping) scalability
Latency (encoder + decoder)
Error resilience
Compression (encoding) speed
Decompression (decoding) speed
Processing throughput required
Power consumption
Heat dissipation
Memory size
Memory bandwidth
Weight of supporting hardware
Size of supporting hardware
Cost of supporting hardware
Integer arithmetic
Multiplication or division
CIFF
YES
YES
YES
YES
YES
YES
YES
150:1
300:1
4,000:1
10,000:1
YES
YES
YES
YES
MINIMAL (1-frame)
HIGH
HIGH
HIGH
LOW
LOW
LOW
LOW
LOW
LOW
LOW
LOW
YES
NO
WAKit
YES
NO
NO
NO
NO
YES
NO
3:1
9:1
N/A
N/A
NO
NO
NO
YES
N/A
N/A
MEDIUM
MEDIUM
MEDIUM
MEDIUM
MEDIUM
MEDIUM
HIGH
MEDIUM
MEDIUM
MEDIUM
YES
?
CleanColor
NO
YES
NO
NO
NO
YES
NO
6:1
18:1
N/A
150:1
NO
NO
NO
YES
N/A
N/A
MEDIUM
MEDIUM
MEDIUM
MEDIUM
MEDIUM
MEDIUM
HIGH
MEDIUM
MEDIUM
MEDIUM
YES
?
In addition to that, CIFF codec can run on existing assets. For example, CIFF supports
UDTV (3840x2160x25fps) compression and decompression on 4-year old Core2Duo notebooks,
which means that existing hardware can be used in years to come by simple software
implementation of CIFF codec, while new devices can additionally benefit from low-power
software implementation or ultra-low power hardware implementation of CIFF codec.
6