<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title><![CDATA[Форум Guardant &mdash; Определение начального запуска функции, ключи Code и другие вопросы]]></title>
		<link>https://forum.guardant.ru/topic/187/</link>
		<atom:link href="https://forum.guardant.ru/feed/rss/topic/187/" rel="self" type="application/rss+xml" />
		<description><![CDATA[Недавние сообщения в теме «Определение начального запуска функции, ключи Code и другие вопросы».]]></description>
		<lastBuildDate>Mon, 18 Jun 2012 13:35:58 +0000</lastBuildDate>
		<generator>PunBB</generator>
		<item>
			<title><![CDATA[Re: Определение начального запуска функции, ключи Code и другие вопросы]]></title>
			<link>https://forum.guardant.ru/post/938/#p938</link>
			<description><![CDATA[<div class="quotebox"><cite>Neekeetos пишет:</cite><blockquote><p>Добрый день, </p><p>Подскажите пожалуйста, <br />существует ли легальная возможность для исполняемого внутри ключа кода узнать выполняется ли он первый раз после включения ключа или же это повторные запуски?</p><p>Также очень хочется отключить все что связано с шифрованием обмена между ключом и драйвером, поскольку эта штука очень сильно затормаживает работу программы, в частности я реализовал протокол обмена SSL между хранимым кодом и программой, и нету никакой необходимости чтото шифровать повторно. <br />Кроме того, я проверил скорость обмена данными с ключом, получается порядка 20килобайт в секунду (это код который ничего не делает, просто пустая функция)! Учитывая что алгоритм AES внутри ключа - исполняемого кода работает со скоростью больше мегабайта в секунду, непонятно куда уходит вся производительность. Так что если есть возможность ускорить все это , прошу указать на примерах как именно, примутся даже варианты не гарантирующие стабильной работы и/или не проверенные разработчиками.</p><p>Еще один вопрос связан с генератором случайных чисел встроенным в апи ключа, что является источником случайности в ключе?&nbsp; Грубо говоря это реализация накапливающая энтропию или просто генератор бесконечной псевдослучайной последовательности? Какая вероятность того, что после сброса ключа этот генератор выдаст ту же последовательность&nbsp; &nbsp;что и в прошлый раз?</p><p>И еще маленький вопрос -&nbsp; сам ключ при сбросе как то инициализирует ОЗУ память кода пользователя? Тоесть, можно ли рассчитывать что память алгоритма будет забита при сбросе нулями например?</p><br /><p>PS вот картинка иллюстрирующая тормоза : <a href="http://neekeetos.embedders.org/transfer.jpg">http://neekeetos.embedders.org/transfer.jpg</a>,<br />вертикальная шкала это задержка отклика( в милисекундах) брелка с пустой функцией, горизонтальная - размер буфера приема в байтах, в названии линий цифра возле W означает размер буфера передачи. Это картинка с ноутбука с процессором Core2duo 1,6Ghz, чуть быстрее работает на рабочем компьютере, примерно пропорционально частоте процессора, те в ~2 раза. На ноутбуке если пересчитать скорость передачи выходит 12кб/с максимум, на компьютере порядка 25кб/с</p></blockquote></div><br /><p>Спасибо Вам за столь интересные замечания и вопросы. Могу лишь порадоваться, что среди наших клиентов есть столь продвинутые и интересующиеся специалисты. Попробую ответить на ваши вопросы:</p><p>1. Легальная возможность отслеживания запусков исполняемого кода это NO_INIT переменные. По умолчанию RAM обнуляется при перевтыкании ключа и между вызовами загружаемого кода. Если вы объявите переменную как NO_INIT то она будет изменяться только при перевтыкании ключа (в остальное время ее контролируете Вы), соответственно это можно будет отслеживать.</p><p>2. Мы рассматриваем такую возможность. При этом функционал ключа будет сведен к нешированным вызовам GrdCodeRun.</p><p>Пока что ускорить нельзя. Ограничение в минимальные 20 мс на операцию действительно есть, и шифрование трафика вкупе с хитрым протоколом обмена не позволяет ПОКА достичь большей производительности. При этом наш продукт все же быстрее всех известных нам конкурентов.</p><p>3. Генератор случайных чисел в ключ является криптостойким, накапливает энтропию и обладает очень и очень достойными характеристиками. В нашей компании работает ряд специалистов по криптографии, плюс мы сотрудничаем в этом вопросе с весьма известными &quot;звездами&quot; да и простые тестировщики у нас зачастую имеют техническое образование в области криптографии. Источников случайности в ключе несколько, в том числе генератор частоты микропроцессора тикающий с момента подачи питания с частотой больше 100 Мгц. Получить ту же последовательность после сброса ключа практически нереально.</p><p>4. На нули в ОЗУ вашего кода рассчитывать не стоит. Если например используется NO_INIT переменная для отслеживание подключений ключа и первых вызовов лучше там использовать осмысленное значение и проверять его не на обнуление а в принципе на изменение.</p><p>Касательно производительности: не только на стороне ключа могуть быть узкие места, но и на стороне защищенного псевдокодом Guardant API. На практике именно комбинация факторов влияют на скорость обмена. В текущем поколении ключей нужно приспособиться к имеющейся скорости.</p>]]></description>
			<author><![CDATA[null@example.com (AndreyStepin)]]></author>
			<pubDate>Mon, 18 Jun 2012 13:35:58 +0000</pubDate>
			<guid>https://forum.guardant.ru/post/938/#p938</guid>
		</item>
		<item>
			<title><![CDATA[Определение начального запуска функции, ключи Code и другие вопросы]]></title>
			<link>https://forum.guardant.ru/post/923/#p923</link>
			<description><![CDATA[<p>Добрый день, </p><p>Подскажите пожалуйста, <br />существует ли легальная возможность для исполняемого внутри ключа кода узнать выполняется ли он первый раз после включения ключа или же это повторные запуски?</p><p>Также очень хочется отключить все что связано с шифрованием обмена между ключом и драйвером, поскольку эта штука очень сильно затормаживает работу программы, в частности я реализовал протокол обмена SSL между хранимым кодом и программой, и нету никакой необходимости чтото шифровать повторно. <br />Кроме того, я проверил скорость обмена данными с ключом, получается порядка 20килобайт в секунду (это код который ничего не делает, просто пустая функция)! Учитывая что алгоритм AES внутри ключа - исполняемого кода работает со скоростью больше мегабайта в секунду, непонятно куда уходит вся производительность. Так что если есть возможность ускорить все это , прошу указать на примерах как именно, примутся даже варианты не гарантирующие стабильной работы и/или не проверенные разработчиками.</p><p>Еще один вопрос связан с генератором случайных чисел встроенным в апи ключа, что является источником случайности в ключе?&nbsp; Грубо говоря это реализация накапливающая энтропию или просто генератор бесконечной псевдослучайной последовательности? Какая вероятность того, что после сброса ключа этот генератор выдаст ту же последовательность&nbsp; &nbsp;что и в прошлый раз?</p><p>И еще маленький вопрос -&nbsp; сам ключ при сбросе как то инициализирует ОЗУ память кода пользователя? Тоесть, можно ли рассчитывать что память алгоритма будет забита при сбросе нулями например?</p><br /><p>PS вот картинка иллюстрирующая тормоза : <a href="http://neekeetos.embedders.org/transfer.jpg">http://neekeetos.embedders.org/transfer.jpg</a>,<br />вертикальная шкала это задержка отклика( в милисекундах) брелка с пустой функцией, горизонтальная - размер буфера приема в байтах, в названии линий цифра возле W означает размер буфера передачи. Это картинка с ноутбука с процессором Core2duo 1,6Ghz, чуть быстрее работает на рабочем компьютере, примерно пропорционально частоте процессора, те в ~2 раза. На ноутбуке если пересчитать скорость передачи выходит 12кб/с максимум, на компьютере порядка 25кб/с</p>]]></description>
			<author><![CDATA[null@example.com (Neekeetos)]]></author>
			<pubDate>Wed, 13 Jun 2012 13:25:51 +0000</pubDate>
			<guid>https://forum.guardant.ru/post/923/#p923</guid>
		</item>
	</channel>
</rss>
