Main Page

From ADCPortal Wiki

Jump to: navigation, search
I
This wiki is a read only resource for unregistered users. Before using any of the content provided please ensure that the intended use follows the terms of the GNU FDL.

Welcome to ADCPortal Wiki

Welcome to our Wiki for ADCPortal and the ADC Protocol development
We have exactly 56 articles and we have 20 Contributers.
ADCPortal wiki has a complete encyclopedia of the software that supports ADC Protocol and the Extensions that are already implemented or drafting. For asking questions about any of the material presented here, please visit ADCPortal and ask them in there.

Featured Article: SUDP

I
This extension is proposed to be included in future versions of ADC, its status is currently drafting.

Synopsis

This extension adds encryption for UDP traffic to ADCS. Currently UDP encryptiuon is not supported by clients so the only way to get a secure ADCS hub is to enforce searches to be passive. This is a proposal to help with this unneeded strain to the hub. While Asymetric encryption may be optimal in sense of security. A symmetric cipher will protect perfectly against outside adversaries given the hub-client connections is also running ADCS. SecureUDP will therefore be a simple and inexpensive way to protect against listening outside attackers.

Secured UDP Specification

Usage of Secure UDP

To signal support for SUDP clients should add "SUDP" in their SU field. (currently while this is adraft "SUD1" is added instead)

If a client signals support for Secure UDP in an ADCS hub. It may extends SCH command with a KY-flag with 16-byte AES-key encoded in Base32. RES messages over UDP to the client may then be encrypted by using: AES/CBC/PKCS5Padding as Cipher/Blockmode/Padding , using 16 zero bytes for the IV. while prepending 16 random bytes (the real IV) in the first Block. So in short : iv = 0 , cbc(16 random bytes || data || pkcs5 padding)

example search: "BSCH AAPG KYN6H7JAOBPO5KSWHEUQUIKW37UM ANtest TO300"

Security Considerations

Keys should never be sent over normal unencrypted ADC connections as this breaks security of all incoming UDP RES messages.

The first 16 encrypted random bytes are sent as a replacement for the IV. i.e. they do the job of an IV preventing known plain text attacks.

AES-128 was choosen for being currently most secure AES cipher (recent attacks show that keylength is exploitable for analysis making AES-256 less secure than the 128 bit variant)

pkcs5 padding is used as its a patent free padding algorithm that is sufficient to allow us to detect if a wrong decryption key was used. (If multiple searches are run in parallel it might happen sometimes that a client has to try multiple keys to decrypt a RES).

ADCPortal Information

ADCPortal wiki was started to document ADC Protocol and history with the help of its developers.

It tries to be as relevant as possible so that everybody has a good picture of how ADC works. The purpose is that users are be able to get in touch with latest software news, development, or to learn the protocol and its extensions, or even how to create their own applications using ADC. For info on how to contribute look below.

Wiki News

Wiki loading slowly

We wanted to acknowledge that we are aware of the wiki loading slow as hell and we are trying to resolve the issue --Toast 19:35, 19 July 2009 (UTC)

We're back

Wiki is back in stable service sporting with a few new extensions for your convenience please see this page for further details -- Crise 23:34, 16 March 2009 (UTC)

More patches

Some bugfix patches have been applied from developement versions, also added some wikipedia style editor mods -- Crise 13:34, 15 March 2009 (UTC)

More…

Articles

Additional Sections

Contribute!

This Wiki is a reg-only based. Accounts may be requested from the forum (see request link).

And for those that do not wish to have an account but still submit articles we have a suggestion thread on the forum (see suggestion link).

Personal tools