www.buslab.orgPB173 1/29
PB173 - Tématický vývoj aplikací v
C/C++ (podzim 2012)
Skupina: Aplikovaná kryptografie a bezpečné
programování
https://minotaur.fi.muni.cz:8443/pb173_crypto
Petr Švenda, svenda@fi.muni.cz
Konzultace: B420, Pondělí 13-13:50
www.buslab.orgPB173 2/29
Last assignment – status?
www.buslab.orgPB173 3/29
Practical assignment
Download OpenSSL and PolarSSL library
● and check signature (gpg --verify)
Write small project
● read, encrypt and hash supplied file, write into out file
● read, verify hash and decrypt file
● use AES-128 in CBC mode and HMAC with SHA2-512
● use PKCS#7 padding method for encryption (RFC
3852)
Start with New Project+PolarSSL+AES
www.buslab.orgPB173 4/29
Portability and memory restrictions
www.buslab.orgPB173 5/29
Memory restrictions
Size of the code vs. runtime memory requirements
Depends on the target platform
● usually of little concern (RAM is big enough)
● sometimes critical factor for algorithms selection
● embedded devices, e.g., sensor nodes
Algorithms usually provides possibility for optimization
● precomputed tables – speed vs. memory
● key schedule vs. on-the-fly key schedule
● optimizations may increase risk for side channel attacks
Write correct code first, then optimize
● especially true in security
www.buslab.orgPB173 6/29
Portability – different operating systems
Usually no problems with algorithms
● plain C code
Problems with additional functionality
● read file, directory listing, user input, GUI
● often cannot be solved by standardized functions or POSIX
● abstract and separate platform-dependent functions
● move them into distinct modules
● easy to replace/extend for target platform later
Data generated by your application should be portable
● ASN.1 encoding
● TLV encoding
● binary vs. text formats
● Base64 encoding
www.buslab.orgPB173 7/29
Portability – different hardware platforms
Little vs. big endian architecture
● usually problem with bit-based operations
● e.g., bit rotation
● problem with interpretation of binary formats
Highly optimized implementations
● e.g., Gladman
● may use architecture specific operations and behaviour
● multiple byte operations in single tick
● special representation of memory data
● may use macros heavily
www.buslab.orgPB173 8/29
Reference vs. optimized version
Double meaning of “reference” word
● reference implementation from algorithm designers
(Rijndael)
● reference == code you should use
Reference implementation (e.g., Rijndael)
● usually simple and understandable API
● lower performance
● may not protect against implementation attacks
● typical usage is as supplementary material to algorithm
description document
● is used to create test vectors
www.buslab.orgPB173 9/29
Reference vs. optimized version (2)
Optimized version of algorithm
● same results as reference implementation
● portability usually impacted
Techniques used
● pre-computed tables often
● may use whole size of the architecture registers
● e.g., AES is byte oriented, but x64 can perform eight xor of
single byte per tick
● may use special instruction of particular CPU
● may use specifics of target architecture (e.g., cache size)
Typically for the production environment
www.buslab.orgPB173 10/29
Choosing the right length
www.buslab.orgPB173 11/29
Length of keys/block/hashes
Choose length with some reserve
● many things can go wrong
Choose algorithms with corresponding lengths
● key derivation by MD5 of keys for AES256?
Do not protect keys distribution by keys with lower
entropy
● AES key encrypted by simple DES key
Asymmetric keys length needs to be much longer
● space of possible values is not continuous
www.buslab.orgPB173 12/29
Comparable strengths of cryptosystems
Source:
NIST SP800
www.buslab.orgPB173 13/29
Recommended key sizes
Source:
NIST SP800
www.buslab.orgPB173 14/29
Symmetric key cryptography
Key length for symmetric cryptography
● 80 bits not secure enough against brute-force
● always good to have some reserve for algorithm flaws
● flaw => key can be found faster then by brute-force
● AES-128 is still OK
● AES-256 do not have 256 bits of security
Take your application needs into account!
www.buslab.orgPB173 15/29
Making the keys
From what are you making the keys?
● password must have entropy equivalent to derived key
● e.g., AES-128 key derived from “hello” will not have
128 bits security
What if you create two keys from one with 128
bits of entropy?
Do you really have perfect random generator?
● 128 generated bits will not have 128 bits of entropy
● generate more bits and use hash function to condense
into 128 bits
www.buslab.orgPB173 16/29
Asymmetric cryptography
RSA is still gold standard
● use (at least) 2048 bits keys
● 768 bits broken by brute-force
● special number with 1024 bits broken by brute-force
● 1024 bits not broken yet, but…
Elliptic courve cryptography (ECC) seems cool
● But do you really need shorter keys?
● If really yes, then use it!
● Otherwise you will face harder portability, more coding
problems, lower level of code testiness etc.
www.buslab.orgPB173 17/29
Practical assignment
www.buslab.orgPB173 18/29
Practical assignment (1)
Modify existing project
● user specifies input and output file
● use functions from OpenSSL library as DLL calls
● (static linking, dynamic linking)
● http://en.wikipedia.org/wiki/Dynamic-link_library
● http://en.wikipedia.org/wiki/Dynamic-
link_library#C_and_C.2B.2B_.28Microsoft_Visual_Dialect.29
● user specifies if OpenSSL DLL or build-in PolarSSL
methods will be used
www.buslab.orgPB173 19/29
Practical assignment (2)
Write following simple unit tests (CxxTest)
● http://morison.biz/technotes/articles/23
● file not exists or cannot be read/written into
● encrypted blob was corrupted
● wrong decryption key was used
● test vectors for encryption and hashing
Code will be used later in architecture
● will be used again and extended, so write it well
Best practices
● http://blog.stevensanderson.com/2009/08/24/writing-great-unit-
tests-best-and-worst-practises/
● MinUnit http://www.jera.com/techinfo/jtns/jtn002.html
www.buslab.orgPB173 20/29
Questions?