Protokół IDBP to protokół GKA oparty na parowaniu bilinearnym i problemie logarytmu dyskretnego. Każdy uczestnik ma jeden długoterminowy i jeden krótkoterminowy, a są tylko dwie rundy obliczeń. Istnieją dwa sposoby ujawnienia tajności klucza sesyjnego – wiedza penetratora o dowolnych dwóch kluczach długoterminowych lub kluczu długoterminowym i odpowiadającym mu kluczu krótkoterminowym. W pierwszym przypadku, ponieważ istnieje n kluczy długoterminowych, a dowolne dwa ujawniłyby klucz sesji, prawdopodobieństwo kompromitacji klucza sesyjnego wyniesie 1 – (1 – p)n – np (1 – p)n-1. In w drugim przypadku, ponieważ istnieje n długookresowych i odpowiadających im krótkoterminowych par kluczy, prawdopodobieństwo kompromitacji klucza sesyjnego wyniesie 1– (1- p2)n. Jednak złamanie jednego długoterminowego klucza nie skutkuje kompromitacją klucza sesyjnego, a zatem protokół spełnia częściową poufność przekazywania. W tym protokole 0 jest niskie, ponieważ są tylko dwie rundy obliczeń. Siła zaufania jest niska, ponieważ nawet jeśli jeden członek ma niski poziom ITS, GTS byłby mniejszy niż 1. W przypadku subskrybowanego czasopisma zależność od kluczy jednego członka nie jest pożądana. Co więcej, utrata dwóch kluczy długoterminowych jest bardziej prawdopodobna, jeśli istnieje dwóch lub więcej mniej zaufanych członków. Dlatego protokół nie jest zalecany dla subskrybowanych czasopism. W przypadku tablicy interaktywnej jest to zalecany protokół, ponieważ wartości zaufania poszczególnych osób są prawdopodobnie wyższe, a utrata długoterminowych kluczy jest zdarzeniem bardzo mniej prawdopodobnym, a niskie p jest pożądane w kontekście ponownego obliczania klucza. W przypadku spotkań zarządu jest to słabo zalecany protokół, ponieważ p jest mały, ale niski wynik zaufania jednego członka może obniżyć GTS. Tabela poniższa zawiera podsumowanie naszej dyskusji na temat stosowalności protokołów w zestawie protokołów do aplikacji.
Skróty R, NR i WR oznaczają zalecane, niezalecane i słabo zalecane, odpowiednio. Powyższa analiza zapewnia pewien wgląd w wymagania aplikacji i charakterystyki protokołów. Ważną obserwacją jest to, że przydatność protokołu dla aplikacji nie zależy od użytych prymitywów kryptograficznych, gdy czas obliczeniowy jest liczony przez ziarnistość liczby rund. Protokoły z tą samą bazą kryptograficzną zachowują się inaczej pod względem zaufania grupowego i siły zaufania dla różnych aplikacji i scenariuszy aplikacji. Najtrudniejsze do spełnienia są aplikacje o ograniczonej dynamice, ale dużej wrażliwości na uczestników o niskim zaufaniu, a także z wysokim prawdopodobieństwem uczestnika o niskim poziomie zaufania, takich jak spotkania zarządu. Rzeczywista aplikacja tego rodzaju musiałaby prawdopodobnie korzystać z kosztownego protokołu wymagającego dużej mocy obliczeniowej, takiego jak STW, aby spełnić wymagania dotyczące poufności i zachować GTS.
Aplikacje z możliwie dużą liczbą uczestników, takie jak czasopismo prenumerowane, z których wiele prawdopodobnie mogłoby uzyskać spadek w wynikach zaufania, również jest trudne do spełnienia. Duża liczba uczestników zmniejsza siłę zaufania. Protokoły, w których jeden członek o niskim poziomie zaufania może znacząco obniżyć GTS, nie byłyby odpowiednie do takich zastosowań. Można jednak używać protokołów z wyższymi GTS, a złożoność kluczowych obliczeń nie jest decydującym czynnikiem. Aplikacje z niskim prawdopodobieństwem członków o niskim poziomie zaufania, takie jak tablice interaktywne, są łatwiejsze do spełnienia, mimo że wymagają ponownego przeliczenia kluczy. Można również stosować protokoły o niskim poziomie zaufania, ponieważ prawdopodobieństwo pozyskania członków o niskim poziomie zaufania jest niskie. Analiza ta wysuwa na pierwszy plan, że przy projektowaniu aplikacji kryterium wyboru protokołów GKA do wykorzystania w aplikacji nie powinna być technika kryptograficzna, ani też złożoność obliczeniowa kluczy czy sama liczba rund. Wybór powinien wynikać z systemowej oceny wymagań aplikacji i scenariusza oraz obliczenia siły zaufania. ITS potencjalnych użytkowników powinny być używane, w połączeniu z różnymi protokołami GKA dostępnymi w literaturze, do obliczania DPFS i GTS przy użyciu każdego protokołu. Algorytm zaproponowany w tej strukturze w połączeniu z narzędziami takimi jak Athena mógłby zostać użyty do tego celu. Obliczona siła zaufania wskazywałaby odpowiedni protokół dla scenariusza. Wybrany protokół powinien spełniać wymagania obliczeniowe i ograniczenia zasobów wynikające z domeny aplikacji i ograniczeń zasobów. Procedura obliczania ITS i statystyczne podejście do przybliżania ITS w czasie projektowania aplikacji to tematy do dalszych badań.