There are several implementations of TLS that support DTLS 1.2. Wikipedia has an exhaustive link here.
My reading points to the classic openssl, libressl, boringssl and mbed TLS as viable options. I am only interested in DTLS 1.2 API and nothing more. I have no interest in usage of the API elsewhere.
openssl seems to be bogged down with a lot of old protocol and usage baggage. mbed TLS's implementation approach appears to be good but it rarely figures in any comparison. I wonder why? Is it incomplete in any way?
If anyone has evaluated the above, or any other TSL implementation, purely for DTLS 1.2 API, which one would you suggest?
Mbed TLS is a lightweight configurable TLS library. It was initially designed for the embedded world and is currently used by large amounts of users and companies on all kinds of setups, from constrained devices to large servers.
Mbed TLS was previously known as PolarSSL, you may want to check both names when searching for references online.
You can find more information about Mbed TLS here:
https://tls.mbed.org/kb/generic/projects-using-mbedtls
https://tls.mbed.org/kb/how-to/mbedtls-tutorial
https://tls.mbed.org/kb/how-to/dtls-tutorial
https://tls.mbed.org/kb/compiling-and-building/how-do-i-configure-mbedtls
https://tls.mbed.org/kb/how-to/how-do-i-port-mbed-tls-to-a-new-environment-OS
Related
I am new for FIPS 140-2, our application is using TLS 1.2 for communication with other systems. I am wondering if there is any requirements for TLS 1.2 to comply with FIPS? In other words, in order to be FIPS-compliant, what does our TLS 1.2 application need to do?
FIPS 140-2 is just some set of encryption/decryption algorithms that are used and monitored by the federal agency. TLS1.2 is surely accepted as FIPS-compliant but the underlying key exchange algorithm must be FIPS compliant. For that, you can use some third-party libraries, for instance, BCFIPS.
TL;DR - it depends on your tech a bit, but in general: You need to use a blessed module tested by NIST to calculate crypto routines as well as configuring your OS and TLS libraries to use good ciphers and protocol versions only (read: make it as close to impossible to use unsupported settings as possible).
If it's nginx, you need the exactly right version of openssl running and configured correctly (correct ciphers, TLS version and so on), and your OS needs to be in FIPS mode.
If it's a JVM app, you need the exact right version of Bouncy Castle installed and configured correctly so that it replaces the default Sun TLS routines, as well as your OS in FIPS mode. On it goes for other types of apps. iirc Python uses openssl, so it's more like the nginx story...
Others probably know more than I do...but hopefully this helps start the journey to understanding.
More details:
FIPS 140-2 is a bit slippery to understand at first.
Some folks say that they are doing "FIPS 140-2 compliant/compatible crypto ciphers" that makes it sound like they are meeting the criteria of the specification, but unfortunately that is different than actually using FIPS 140-2 validated cryptographic modules (as well as all the appropriate configuration of ciphers and so on).
If you are supporting FIPS 140-2 validated cryptography for something like NIST 800-53, then you are required to "do more things" than just configure TLS 1.2 correctly.
https://www.gsa.gov/cdnstatic/SSL_TLS_Implementation_%5BCIO_IT_Security_14-69_Rev_6%5D_04-06-2021docx.pdf has a reasonable summary of things to be aware of in section 3.
FIPS 140-2 compliant encryption is achieved when the following conditions are met:
Implement FIPS 140-2 Encryption Modules AND enable the FIPS 140-2 Object Module
Implement Secure Protocols
Implement FIPS-approved Ciphers
One or both sides of the communication session (client and/or server) must be set up in FIPS mode
Further, the thing about using validated cryptographic modules means, the programs or hardware that calculate crypto routines must be on the list of blessed CMVP modules at NIST:
TLS implementation must use FIPS 140-2 validated cryptographic modules in order to achieve FIPS compliance. NIST maintains a list of FIPS 140-2 Cryptographic Modules (https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search). A cryptographic module may either be an embedded component of a product or application, or an individual product in-and-of-itself.
Obligatory wikipedia reference, which makes more sense once you already know about the CMVP: https://en.wikipedia.org/wiki/FIPS_140-2#Compliance
An example of setting up your OS in FIPS mode: https://aws.amazon.com/blogs/publicsector/enabling-fips-mode-amazon-linux-2/
Redhat and others have similar guides. For windows or other OSes... your mileage may vary, but I'm sure someone has been crazy enough to do it.
OpenSSL has some notes on FIPS 140-2 that are somewhat entertaining and informative: https://wiki.openssl.org/index.php/FIPS_mode_and_TLS
I'm fairly new to BLE and am exploring the security of advertising packets. I was hoping to find some recommendations for resources/general advice on how should learn/implement lightweight encryptions for advertising packets. The data I would work with isn't highly sensitive and after looking into it I'm leaning towards using an ECB and two TI Launchpads to develop with.
For your own private project it might be suitable to use symmetric encryption such as AES. You would need one key on all devices to en- and decrypt your messages.
Depending on your choice of language there are small libraries like tiny-AES availible. Larger collection of cryptographic tools like mbedtls or cryptopp exist but might be overkill for your purpose.
Also take a look at the tools provided by TI, there might be some libraries included in your SDK.
I understand that PKCS#11 is std that defines cryptoki API and KMIP is a protocol that defines message format, but how they are connected or are they even interconnected?
How they both hold their individual significance in cryptography?
PKCS#11 can be considered a protocol of a kind too, it's used to communicate with the hardware devices (to be precise, with the driver modules of those devices). However, it's not suitable for network communications. KMIP is the protocol to communicate with remote key storages and similar services and use the remotely stored keys. This is similar to what PKCS#11 offers locally.
In theory, the protocols partially interlap and are to certain extent interchangeable - Oracle has the PKCS#11 driver/gateway, which talks to the remote KMIP server, and the opposite should also be possible. But, of course, each has its own strengths and weaknesses. Interestingly, both KMIP and PKCS#11 standards are developed by the same people in OASIS.
There's also a paragraph in Wikipedia that answers your question.
I am working on a custom dissector for Wireshark in lua.
Certain PDUs in the protocol is encrypted using AES and I would like to decrypt these so that I can show the clear content in Wireshark. Is this possible with a lua dissector and what APIs can I use to make the decryption?
Or do I need to make a c/c++ dissector to make a dissector that decrypts data?
Personally i use lua-crypto but it requires OpenSSL.
You can check lua-wiki.
Recently i create wrapper for this AES implementation called bgcrypto.
It has no external dependencies but i really do not use it yet in real work.
At the moment Wireshark (2.0) does not expose a crypto API to LUA dissectors, so you have to implement it in the Lua dissector.
For a pure Lua solution you can use lua-lockbox (as mentioned on the Lua wiki). This is not recommended if you need performance, but might be useful for prototyping.
Faster AES decryption implementations typically use a native library, for example:
LuaCrypto - uses OpenSSL, though it does not seem maintained
lcrypt - uses libtomcrypt, but there seems to be no development either
Since none of these libraries satisfied my needs, I developed a new one based on Libgcrypt for these reasons:
Wireshark already links to Libgcrypt for things like SSL decryption.
The Libgcrypt library supports sufficiently many ciphers and hashes.
Libgcrypt is widely available and has an active development team.
The Luagcrypt API is simple enough and documented.
The result is luagcrypt which works on the platforms supported by Wireshark (Linux, OS X, Windows). It is used in the KDNET dissector, this commit shows the transformation from lua-lockbox to luagcrypt.
We're all familiar with popular protocols like IMAP and POP, used for email messaging.
I have a plan for a new protocol, but I'm not sure to go about implementing it.
Is the protocol a collection of C source code, for example, that accepts and sends data through ports? Or is a protocol just a thorough description of how data should be sent, which clients then implement?
I'm lost where to start here, and I'm not very familiar with how the protocol system works.
Edit:
Also, if I write a protocol and it isn't made official by the standards group, can people/clients still implement it?
The official way is to write an RFC - a Request for Comments. People will respond to that (that's why it's an RFC) and probably try to implement your protocol.
As soon as two independent implementations exist that completely support the protocol, it's a new standard.
Of course, people aren't going to implement a new protocol for someone just for fun. So you should first find a group who is interested in listening to you. Maybe there already is a protocol which does what you want (or can easily be extended).
But you probably don't want to invent a new standard. Standards are a lot of work and - for some - overrated.
So you should describe how it works and create a library that can read and write the protocol, so developers can use it even though it's not an official standard.
As you are interested in the Replace Email section of the Paul Graham article you linked, then IMHO you will need to both develop a protocol definition, and also provide an example implementation. The protocol definition does not need to be published as an internet protocol standard in order to be useful.
You will need an implementation to so that you can test, refine and improve the ideas. It is extremely unlikely the protocol will be right at the first attempt, and you'll need something to support the initial users.
You don't need a protocol definition to implement an improved email, but you will need one if you expect others to work with you and adopt it, though it very much depends on your 'business model'. I strongly recommend you have a protocol definition from the start, even if only to keep yourself sane when you try to produce the second implementation.
I recommend having a look at some examples of sneaky approaches to protocols and implementation. My favourite is described in the Viewpoints Research 2008 Progress report on a super-compact approach to TCP/IP.
They did not follow the traditional approach to developing the implementation of a protocol (the protocol stack). Instead they wrote code which parsed the human-readable TCP/IP protocol specification, and generated the code of a TCP/IP stack from that protocol document. The usual TCP/IP stack is about 40,000 lines of code, or more. Their program, which read the protocol specification, and generated the code for a TCP/IP stack 'automatically' was only 160 lines of code. They use extremly powerful programming tools.
If you had an approach like that, you could keep the protocol implementation synchronised with the specification, and potentially make it straightforward for others to adopt your protocol.
HTH
You are confusing a protocol standard with the implementation.
These 2 are unrelated.
A protocol is described in a high level but has enough information for someone to undestand how it should be implemented.
The idea is that someone reading the document can understand how/what to implement in any language of preference
To give an example: SIP protocol in the RFC describes the various flows and also has the various messages and how they are supposed to b processed i.e. the semantics well defined.
You can implement a SIP UA or Server in C++ or Java. This is irrelevant to the SIP protocol
For this you don't need to provide any source code (you could though if you think it helps clarify some obscurity of the description).
The most important part is that your protocol is actually reviewed by stakeholders i.e. people that expect it to solve their problems.
This part is the most important not only because it could solve problems in your protocol but because they can actually verify that the concept is solid i.e. can be technically implemented
The only case that one could specify something concrete or imply something is if for example the protocol described something demanding some specific constraints e.g. hard-real time constraint which could serve as "hint" on which implementation/languages to avoid
Also, if I write a protocol and it isn't made official by the
standards group, can people/clients still implement it?
Strange question.What do you mean?How will someone know your protocol exists?
If it is official he can get it from the standards group to implement it.
Otherwise it is obvious that you have some sort of "proprietary" protocol (which is not uncommon e.g. a company can have an internal protocol for its own software) and people have to get the spec from you.